Closed (fixed)
Project:
EveryBlog
Version:
6.x-2.0-dev0001
Component:
Code
Priority:
Normal
Category:
Support request
Assigned:
Unassigned
Reporter:
Created:
12 Aug 2008 at 16:49 UTC
Updated:
4 Jan 2009 at 14:20 UTC
Why are there everyblog.module, and everyblog.standard.module in the project? What does the last one do?
Comments
Comment #1
ntroutman commentedFor 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.modulein 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 regulareveryblog.modulecontains 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 hugeeveryblog.modulefiles 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
Comment #2
avpadernoThat 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:
Comment #3
ntroutman commentedI 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:
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
Comment #4
avpadernoI 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.moduleis not a module at all. It should be better to rename it, and give it an extension like.inc, as other modules already do.Comment #5
ntroutman commentedThanks you are right, giving it an
.incextension would make more sense, I'll make that change.Thanks for the help,
NTroutman
Comment #6
avpaderno