Drupal social publishing software

Having recently upgraded to PHP 5.2 on one of the servers I run I needed to throw a new Drupal site together this evening. All was well until you tried to navigate to any page after logging in. Access Denied was the response on every page. It turns out this is a known issue and is fixed in the latest development release of Drupal 4.7. If you're running PHP 5.2 make sure you download 4.7-dev instead of Drupal 4.7.4.

SEOMoz points to an interesting study on form design. The study suggests that the convention of labels on the left with the entry box on the right is not as effective as a non-bolded label on the line above the input field. Many Drupal themes already do this pretty well but it is good to keep in mind. Many hours have gone into trying to get it "right" when we were chasing the wrong answer.

I'm working with a complex network of Drupal sites and trying to find the best way to do federated users. The Drupal Module approach is a little too shotgun for this case. I need fine control, roles, taxonomy access etc. for each site but would like to have a common username and password. In the best of all possible worlds single-sign-on.

One approach uses MySQL views to accomplish this. So far this seems a good approach but it is not as simple to administer as I'd like. The Open Journal Systems approach is very much what I'd like to implement. An administrator goes to the main site and can see all the users and can assign users to various sites. It would be possible to do this with the roles in Drupal but one would quickly end up with a huge number of roles in managing just a few sites.

Authenticating all sites to LDAP would be another option worthy of consideration.

A discovery in this process has been that to share the sequences table most effectively using MySQL's ability to handle symbolic links for tables seems to be the best way. This solves two problems. One is modules that don't work well with table prefixing. The other problem it avoids is one of table locking when trying to use a MySQL view in place of a table. The drawback is you need an up-to-date version of MySQL and it may not work with other databases.

One blog is accumulating Google code searches that reveal information they shouldn't. For example this search produces a list of some Drupal database usernames and passwords. Most are for distributions but a few folks have unwisely put backups of their configuration files in .tar files inside their web accessible directories.

Simply put, no file containing sensitive data should ever be stored in a web accessible directory unless it has the proper extension to prevent random browsing. Files like Drupal's settings.php are OK because they must go through the PHP processor. Putting settings.php.txt or a .tar file with a settings.php in a web directory is a bad idea.