Why are there everyblog.module, and everyblog.standard.module in the project? What does the last one do?

Comments

ntroutman’s picture

For version 1.x of EveryBlog I've been trying to maintain a backport that is Drupal 5.x compatible. Unfortunately Drupal 6.x isn't complete backwards compatible with 5.x, but larger portions are. So, everblog.standard.module in Everyblog 5.x-1.x and 6.x-1.x are the same, as it contains the code that works with both Drupal 5.x and 6.x. The regular everyblog.module contains the code that is specific to each version of Drupal. The idea was to keep bug fixes in both versions and to make code maintance easier, other wise there were two huge everyblog.module files that were largely the same and they had to be maintained separately, this is how some bugs got fixed in the 5.x branch but still showed up in the 6.x and vice-versa. Since Everyblog 6.x-2.x is an update of 1.x line it shares much of the same directory layout. I don't know if I will backport the 2.x version to Drupal 5.x or not as its been kinda annoying maintaining two versions, but people have asked for it, so I might keep doing it. I hope this answers your question.

Thanks for the help,
NTroutman

avpaderno’s picture

That is a little confusing.
When you deploy a module for Drupal, you deploy the release specific for a Drupal version.
You will never find somebody who puts in the same archive the versions for two different Drupal versions. That is also because:

  • It could be confusing for the end user;
  • it is a waste of space on the Drupal server;
  • it is a problem for the end-user which would have to delete the release for the Drupal version he is not using;
  • it is not the way to do in Drupal; if it would be so, why would we have a different archive for every Drupal version?
ntroutman’s picture

I think you misunderstood me. The everyblog.standard.module is a convience for me. The end user, when they download a release archive, gets a tar.gz file which when they decompress it creates a folder with the working module. It currently has a structure something like:

everyblog
|-everyblog.info
|-everyblog.install
|-everyblog.module
|-everyblog.standard.module
|-translations
|    |- everyblog.pot
.
.
.

That structure is the same for both the 5.x release and the 6.x release. So the end-user never needs to mess with anything in the directory, just like normal.

From the coding perspective, everyblog.module includes (a PHP include) everyblog.standard.module (which I could rename to everyblog.core.module). And on my own development computer I have three separate drupal installs, one 5.9 for developing the 5.x compatible version of Everyblog and two 6.3 installs, one for developing 6.x-1.x and one for 6.x-2.x. And both of the 1.x branches (the 5.x and 6.x compatible versions) share the file everyblog.standard.module, which contains code that works on both of them. That way I only have two small everyblog.module files to maintain with the differences between Drupal 5 and 6.

So none of the structure affects end user, its just a convenience for me since I'm maintaining 3 separate branches of Everyblog, two of which share a lot of code. And I'm all for code-reuse because copy-n-paste is evil, lol.

I hope that is a bit clearer. Thanks for all the comments you've made, I really appreciate the help and second pair of eyes looking at my work.

Regards,
NTroutman

avpaderno’s picture

I understand better, now.
You put there code which will never change, so it's easier for you to maintain the code that is specific to a Drupal version.

What you call everyblog.default.module is not a module at all. It should be better to rename it, and give it an extension like .inc, as other modules already do.

ntroutman’s picture

Thanks you are right, giving it an .inc extension would make more sense, I'll make that change.

Thanks for the help,
NTroutman

avpaderno’s picture

Status: Active » Fixed

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.