Monitoring 5.x upgrade process.
Modules (12 modules need to be resolved)
This is a list of all eglug.org contrib modules and the availability of their 5.x versions:
-
Article. -
Bidi. -
Code Filter. -
Comment RSS. -
HTML Corrector. -
Image. -
Image Filter. -
Private Messages. -
Subscriptions. -
User Points. -
Diff. - Admin Block. No 5.x port, but Views with a bit of themeing can replace it. (HEAD works fine with drupal 5)
- Event. HEAD works, release pending a bug fix.
- Flexinode. No 5.x port, and seems like it's not gonna be out any time soon. We should really move to CCK.
- Glossary.
- Hall of Fame. (can be replaced by views??)
- Mail. No 5.x port, but seems to be on its way
- Syndication. (not very useful anway)
- Workspace. (doubt anyone uses that)
- Lincount. (is linux counter still relevant?)
- Members. (is this still needed?)
- Rankvote. (sucks anyways, should be replaced by something that integrates with decision module or a voting api based module, Advanced Vote is way better)
- Wiki (all filter modules work as is under drupal5, we should consider replacing this with the pear based text_wiki module).
PHP Snippets
Nodes:
- BidiModule (these are only used to share the code, can be replaced by a link to some cvs repository)
- LinCountModule
- RankingVoteModule
- list of people who voted for italian food (these should be replaced by something in the module itself instead of this ugly hack)
- top 10 contributors (not needed anymore HOF can do that)
- list of people who voted in moderators elections
- List of people who voted in Administrators elections
- list of people who voted on the admin elections poll
- Welcome to my Blog (that must be mostafa abusing his admin privilege)
- DiffModule
- top 10 commented nodes
- List of people who voted in 2nd Administrators elections (2006)
- List of people who voted in Administrators elections (2006)
- List of people who voted in 2nd Moderators elections (2006)
Blocks:
- Icons Bar block (this block of icons on the left).
Themes
We have only one theme
- EGLUG theme.
This upgrading procedure is one of the eglug.org administrators team tasks. But of course everyone is more than welcome to volunteer in many ways, like porting remaining modules, correcting/updating this page (as for example, some of modules above my be updated later with a 5.x port by Drupal community).
The PHP Snippets may not need any effort at all, the above list is actually the result of a search in the database for all nodes with inline PHP code. Also, not everyone may be able to edit these nodes, but let's keep it here for now to make this document a complete list.
Note
If you would volunteer in porting any code, it's recommended that you update this page to indicate this. That is to avoid having multiple volunteers working on the same thing without coordinating with each other.
I'm maintaining article
I'm maintaining article (Officially)
bidi (unofficially)
CCK is part of drupal 5.0 Probably we need this: http://drupal.org/project/flexiconvert
lincount has been developed for eglug. I can make it a drupal project and maintain it also if needed.
WWW: The place for organized randoms!
which modules are you
which modules are you talking about?
can't see those non trivial unsupported modules in the list
cheers,
Alaa
husband of the Grand Waragi Master
Well.. I agree we have
Well.. I agree we have poorly maintained (or completely unmaintained) modules like lincount, rankvote and HoF. Flexinode while being fairly maintained, I think its authors are only keeping it for not breaking people installations and they advice moving to CCK. A big +1 for replacing wiki by text_wiki, but does it support our old syntax?
Sounds like things we should get done before moving to 5.x, so:
- Rankvote being the most important we should test alternatives and write a script or so to migrate old data to the new chosen module. Any volunteers ?
- Flexinode, we use it for Reviews and Icons. There is also a mysterious 'event' flexinode type which exists with 'Event' module that also provides 'event' type. I don't really understand how it's possible they exist together.
- HoF, all it provides are some statistics so I don't think it needs regular maintenance. Only between upgrades to adapt DB changes. So I suggest we continue using it.
- Lincount, basic functionality and can't be replaced by something else I guess. I will give it some love anyway :d.
- Workspace, I also don't think anyone uses it.
- Wiki, would be nice to move to text_wiki but any thoughts on compatibility with our old syntax?
I think it would be really great if we could get a new theme along with the move to 5.x, any one up for it ;-) ?
IIRC, the event module
IIRC, the event module hooks into another content type (Which is the event flexinode type.
WWW: The place for organized randoms!
we are not using any
we are not using any poorly maintained scripts. it's just that trivial modules don't require much maintenance specially ones that rely on parts of the api that didn't change much.
flexinode is not being replaced by CCK per se, the developer is still working on it, he is just not interested in releasing a 5 release soon.
still even though flexinode is a well maintained project and will eventually get a 5 release it's a good idea to move to cck since cck is getting more support and interest among the drupal community and integrates better with stuff like the views module.
what event module does is add a calender view over an existing node type, allowing you to choose whichever types you want, in the not so distant past event did not provide a node type at all you had to create one with flexinode, then they made the simple_event module which provides the simplest event node type, our flexinode type has an extra field (location) so we continued using it.
when we upgrade to 5 I expect we'll use cck to implement the event location field.
just because a module doesn't have a 5 release now doesn't mean it is unmaintained, maintainers take a variable amount of time to cope with API changes.
now one thing we could do if we want to speed up the upgrade process (I actually don't know why we'll want that, most major 5 modules are still under heavy development and require more testing, most are not yet in a state where they benefit from new 5 features, arabic translation for 5 is not ready yet. and while 5 has some pretty cool features I can't think of ones that are so compelling for EGLUG at the moment, )
if I where in your place I'd stick to 4.7 for a while,
cheers,
Alaa
husband of the Grand Waragi Master


The problem as I see it
Our problem is not that we have modules which need non-trivial intervention to upgrade drupal. It is that we are relying to a non-trivial extent on unsupported code.
-- Panem et *burp* circenses