Where we are with Drupal.org modules vs. Drupal 6?

Events happening in the community are now at Drupal community events on www.drupal.org.
gábor hojtsy's picture

While the drupal.org redesign is about so much more then drupal.org itself, we certainly need to clean up and improve on our act on the main drupal.org site before moving on to elsewhere IMHO. So I took a look at the modules enabled on the drupal.org website (via good old "system table where status = 1" queries), which I've attached as http://groups.drupal.org/files/DrupalOrgModules_0.pdf. Some notes:

  • Drupal module was ported as site_network to Drupal 6, so drupal.org can keep offering that for backwards compatibility after and until the OpenID server is set up (waiting for that sounds like a never ending story)
  • There are some interesting items on drupal.org, like dblog module enabled but without a file; also urlfilter contrib module enabled, while it is a built in drupal 5 feature.
  • There are certainly items which we are not going to carry forward. The bluebeach theme is among these things, but feature module seems like a safe bet as well. It is a horrible way to present Drupal features, and should go away as soon as possible.
  • Two of the drupal.org custom modules are not hosted under drupalorg module and are therefore not open source. This makes it harder to port them forward and get the community going on reviewing and helping with them. These are the ircnick module used to search by irc nickname and the update_status 1.x XML-RPC compatibility module.
  • Quite a few of the modules have 6.x releases but not yet stable. In cases like image module, where even Acquia Drupal ships with them, it is a good question, whether we should believe they are stable or not. Independent verification always helps. Also, our criteria is more strict, we need to keep some existing features going forward, unless of course we can do something better.
  • There are obviously 5.x modules not done for 6.x yet, but the list goes way over just the project module family. So there is lots of ground for work beyond upgrading project module.
  • As far as project modules go, my last information is that dww/hunmonk/aclight look for new stable releases of the module suite for 5.x hopefully sooner then later (http://groups.drupal.org/node/10865 and http://groups.drupal.org/node/16069 for details), and then Drupal 6 patch committing will start.

I think there is plenty of work opportunity here to distribute. So let's get started!

AttachmentSize
DrupalOrgModules.pdf35.38 KB

Comments

submitted two issues

gábor hojtsy's picture

Also noticed that quite some drupalorg submodules are not actually committed to CVS. Not good. Submitted http://drupal.org/node/327031 for the drupalorg module issues.

The feature page is a disaster, and there is nobody to argue on that. I've submitted http://drupal.org/node/327034 with a damn easy migration path from that module to handbook pages, so that the docs team can take matters in their hands. One less module to worry about in the upgrade.

got control of custom modules today

gábor hojtsy's picture

Once the last item is completed, all the drupal.org custom code is in drupalorg module and submodules. Other modules on the site are contributed modules actually used elsewhere as well. This should make it much simpler to handle tasks, maintain the custom code on drupal.org and so on.

I've also looked at this dblog module and removed its system table entry, since it was nowhere to be found on the file system (and the module list), except its item in the system table. Also removed entry for urlfilter module which was again a remnant of pre-Drupal 5 days (contrary to what I said above, it was not on the file system at all).

So the updated drupal.org module overview is much cleaner (attached) and shows the following requirements for current drupal.org upgrade:

  • project* family
  • cvslog module (sort of project family member)
  • comment_upload
  • image module and submodules
  • simplenews
  • tracker2
  • xapian
  • paranoia
  • all the custom modules and code in drupalorg

This is not an overly long list, especially that image is in alpha, simplenews in beta, and comment_upload has dev for Drupal 6.

merging ircnick.module into drupalorg.module

christefano's picture

I don't remember where I got it from but I merged ircnick.module with drupalorg.module and posted the patch in the issue queue.

superb

gábor hojtsy's picture

Thanks, looks good, identical to the currently running ircnick module. Reviewed, compared and marked RTBC.

Not paranoia

dmitrig01's picture

We don't need this now that we have php module in drupal 6 which can be removed.
The only featuer we'd lose is disablind editing of user 1. is that ok?

not sure about paranoia not being required

gábor hojtsy's picture

We are going to have Views, which has PHP options which need to be blocked out for security and maintainability I assume. Paranoia for Drupal 5 does the following (according to project page):

  • Disable granting of the "use PHP for block visibility" permission. Save the permissions form once to remove all previous grants.
  • Disable creation of input formats that use the PHP filter.
  • Disable editing the user #1 account.
  • Disable disabling this module. Yes, that's right you need to go to the database to get rid of it again.

The PHP for block visibility is still an option in Drupal 6 even without the PHP module. Also a Drupal 6 version of paranoia would disable enabling the PHP module I guess. This last point might be worked around by simply deleting the PHP module on drupal.org, but the other two PHP input options still stand.

Also

dmitrig01's picture

Could you describe all the custom modules in the drupalorg family?

Here they are

kbahey's picture

http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/drupalorg/

role_activity is not live yet on d.o.

lists is the mailing lists module (was its own module before).

blocks and nodes is the old PHP in nodes/blocks that got converted to modules.

drupal.org.module is everything else.

Drupal performance tuning, development, customization and consulting: 2bits.com, Inc..
Personal blog: Baheyeldin.com.

Drupal performance tuning, development, customization and consulting: 2bits.com, Inc..
Personal blog: Baheyeldin.com.

Many thanks your cleanup

moshe weitzman's picture

Many thanks your cleanup work here, Gabor.

There are certainly items

minesotaa's picture

There are certainly items which we are not going to carry forward. The bluebeach theme is among these things

I am not preaching to keep the old :) but unfortunately/sadly the current themes/page layouts that are being presented in iteration are nowhere as unique as the bluebeach. Not to speak about the simplicity and yet functionability, and ease of use of the bluebeach. I wonder if I am just alone who thinks this and no one else is really noticing how 'mimicking' or 'mundane' new layouts are looking compared to the present drupal org layout which is still so fresh and relevant, and above all unique in the crowd.
( Perhaps a bad analogy, but see google never changed themes over the years but added to or enhanced the existing )

Please raise this in the

christefano's picture

Please raise this in the other redesign group where the iterations are being discussed. I'm not sure if this is obvious, but this is the redesign infrastructure group.

Drupal.org Improvements

Group categories

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: