After six months of development Drupal 4.1.0 is now ready for some final testing. Drupal is currently in a feature freeze, and has been for quite some time, to make sure nothing breaks before the final 4.1.0 release.

If you have a Drupal site and you want to help testing, consider upgrading now. Anyone who doesn't have an old site and wants to help out can of course setup a Drupal site from scratch. All feedback is appreciated, good or bad.

The source code is available at:

http://www.drupal.org/drupal/drupal-4.1.0-rc.tgz

Installation guidelines are available in the Drupal handbook. For bug reports use the project page, the mailing lists, the support forums or add a comment below. The release candidate is repackaged twice a day so make sure to download a fresh copy every now and then to get the latest fixes.

Happy testing.

Comments

moshe weitzman’s picture

- initially, story and page modules are active but blog is not. not sure what should be active, but that seems like a pretty arbitrary initial set.
- i suggest moving rating.module from the distro into Contrib. it is rarely used, and has a bug where it assumes the _user() hook means something specific to ratings, which it no longer does (i.e. weight of a jabber, weight of a drupal, etc.)
- none of the system.module admin pages page except 'content filters' give a status message after submitting
- when viewing my own profile, i see signature='n/a' and jabber id = empty. i think these should be omitted. please see patches in the 'privateProfile' dir of my sandbox which fix these. Would be lovely if they are applied soon, before they rot
- the large logo in the upper left of goofy theme should be hyperlinked to Home
- reminder: I have a patch in the pager dir of my sandbox which adds paging to Watchdog. Also see the profile dir for a patch which improves form descriptions

dries’s picture

- i suggest moving rating.module from the distro into Contrib. it is rarely used, and has a bug where it assumes the _user() hook means something specific to ratings, which it no longer does (i.e. weight of a jabber, weight of a drupal, etc.)

Done.

- when viewing my own profile, i see signature='n/a' and jabber id = empty. i think these should be omitted. please see patches in the 'privateProfile' dir of my sandbox which fix these. Would be lovely if they are applied soon, before they rot.

Applied and committed. Thanks.

- none of the system.module admin pages page except 'content filters' give a status message after submitting.

Unless someone contributes a clean patch for this, I'll add it to my TODO list for the next release (which will focus on usability).

- the large logo in the upper left of goofy theme should be hyperlinked to Home.

Theme UnConeD does not link the logo to the main page either. If it is considered good practice, I don't mind fixing them both.

Thanks Moshe.

ax’s picture

>> i suggest moving rating.module from the distro into Contrib [...]
> Done.
great finally i can close the bug i filed about this (that never got any attention ...)

when browsing the installation instructions that are refered to from the INSTALL file, i noticed that the System requirements aren't up to date (php_value magic_quotes_gpc 0, which not setting causes chinese characters, was missing). i updated the page, including all the required settings from .htaccess and hyperlinking them to the php manual (among some other things - check the log). please check and promote that change.

also, i think that the System requirements should be linked from the Installation process chapter, 9. ("edit the .htaccess file")

another issue with php settings and .htaccess: if you run php as cgi, the .htaccess settings won't be considered because of the <IfModule mod_php4.c> (see CVS DB, .htaccess weirdness). and drupal won't work ... guess the solution is to remove the <IfModule mod_php4.c> - there will only appear some notices in the error.log, won't there? the alternative - do all the settings with ini_set() - won't work because some settings (register_globals, ...) can only be set PHP_INI_PERDIR|PHP_INI_SYSTEM.

more .htaccess / php-settings issue: is php_value session.cache_expire 200000 really meant to be 200000 minutes, ie. 138 days? the default is 180 minutes ...

and: php.ini says track_vars is ALWAYS enabled as of PHP 4.0.3 - so it can actually be removed from .htaccess, can't it?

and: why must short_open_tag 1 be in there? we require our code to work with short_open_tag 0, ie. this setting doesnt matter - can't it be removed, too? same with allow_call_time_pass_reference.

ax’s picture

another issue with php settings and .htaccess: if you run php as cgi, the .htaccess settings won't be considered because of the <IfModule mod_php4.c> (see CVS DB, .htaccess weirdness). and drupal won't work ... guess the solution is to remove the <IfModule mod_php4.c> - there will only appear some notices in the error.log, won't there? the alternative - do all the settings with ini_set() - won't work because some settings (register_globals, ...) can only be set PHP_INI_PERDIR|PHP_INI_SYSTEM.

well - just checked this; unfortunately, removing the <IfModule mod_php4.c> does not work, because php_value only works when using PHP as an Apache module, i learnt. so those running php as cgi have to change their php.ini. guess this should be mentioned somewhere.

Chris-1’s picture

I initially grabbed version 4.0 and installed it. This has to be the nicest CMS I have used yet. I love the extremely modular approach. I wanted a minimal site with a few users posting stories, but I didn't want comments enabled even for logged in users.

- I found that the comments module was not completely disabled in node.module. So I grabbed the cvs version tagged at 4.1.0 which fixed this problem.

- I found an issue when queue is enabled but comments are disabled. In queue.module, comment_render($node) is called even if comment.module is disabled. I filed a bug report on this and included a patch, but it was quickly closed and not fixed. The bug is very similar to the one above. Should I submit the patch to the drupal-devel list?

- I also discovered a bug when queue.module is not enabled. When a user submits a story, despite what is stated to be the default for a node in node.module, the story is not promoted to the frontpage. I was able to modify story.module and set promote to 1 if queue is not enabled, but I'm not sure that the story.module is the place to start since all nodes are supposed to be promoted by default if the queue is disabled. It seems that upon preview, the initial promte value of 1 that is set in node.module in node_add is removed.

Other than that, I believe that this release addresses the problems that I was having in 4.0.0

I am new to drupal so I am sorry if I didn't send the patch to the right place.

Thanks

dries’s picture

- I found an issue when queue is enabled but comments are disabled. In queue.module, comment_render($node) is called even if comment.module is disabled. I filed a bug report on this and included a patch, but it was quickly closed and not fixed. The bug is very similar to the one above. Should I submit the patch to the drupal-devel list?

I read your bugreport, committed a modified version of your patch to CVS and closed the bugreport. Try downloading a fresh Drupal 4.1.0-rc tarball and see if the problem persists. It should be fixed and the change should have propagated to the tarball by now.

Thanks for testing, Chris.

Chris-1’s picture

Thank you for the quick reply. The patch does indeed work and is more elegant than my quick patch as well.

Thanks Again,

Chris

bertboerland’s picture

good job, dries and all,

however, i think most users of drupal would like to see some kind of a roadmap, even raw data (like q1 2003) will be fine enough. this way users can see what (when?) to expect and will have a better feeling about *the project*.

if one is not subscribed to one the various mailing list, you would see all the work that is being done and might even suspect that the project is dead. [talk=manager]communicating about progress is half the progress[/talk=manager]

--
groets
bert boerland

polaar@www.drop.org’s picture

And maybe someone can post a quick summary of what's new?

ax’s picture

try the CHANGELOG from cvs.

carl ditzler’s picture

Just curious, is Drupal.org on the release candidate?

dries’s picture

Currently, yes. Why?

moshe weitzman’s picture

drupal.org is a good example of new forum module and new themeing possibilities, but a poor example of the new comment module. specifically, the comment rating/moderation system is disabled here. if you have used Kuro5hin or Slashdot, you probably are familiar with the new comment rating functionality.

Also, if you don't have admin privs you can't see some of the high flying features in the statistics module.

Anonymous’s picture

Installed latestest release. Installed blogmail module. When try to configure get ...

user error: Table 'drupal.blogmail' doesn't exist
query: SELECT * FROM blogmail ORDER BY mail in D:drupal-4.1.0includesdatabase.mysql.inc on line 69,

moshe weitzman’s picture

mailhandler.module is what you need ... remember to create the necessary tables using the .mysql file

dries’s picture

If it is deprecated, why don't we remove it from CVS?

moshe weitzman’s picture

When I do a checkout, I don't get this module. But the directory is still visible via the CVS web pages. Once you get there, you have to go through the attic to get at the files.

I'm probably not removing modules using the right commands.

taybin@piratesvsninjas.com’s picture

You can't remove a file in CVS. It'll always be in the history. Similarly, you can't remove a directory. That's why, when updating, you need to use "-Pd", which will prune emtpy directories in your local tree.

Gaco-1’s picture

Hello,

Currently I have a site using version 4.0, since it's the 'stable' release, but seeing that 4.1 release has been under "release candidate" for so long, I'm wondering a few things:

  1. Will 4.1 be released any time soon? How safe is it for me to upgrade at this time?
  2. How different are the 4.1 release to the CVS version? I'm thinking on re-writing the events module, but I won't have time to actively maintain it too long after I'm done. So, should I write against CVS?
  3. How pain(ful/less) are upgrades? Does the upgrade take care of upgrading the added modules? their data in the DB? The translations?

Thanks for your replies.