Drupal social publishing software

Drupal is a powerful content management system and framework that makes building powerful websites possible for mere mortals. Some of the posts here will be syndicated to Drupal planet.

Drupal login problem with PHP 5.2

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.

Updating old content

Readers subscribed to the RSS version of this site have seen several articles from before 1998 appear in the feed this morning. While doing a routine (if not frequent enough) check using Google's Webmaster tools, I discovered that there was some old content that had never been migrated into the content management system. A few minutes later and they were all imported. If you want a trip down memory lane check out the notes section from the old site. It was fun to see some of this old content and remember just how far we've come.

It does bring up a feature request for Drupal, however. It would be nice to have a way to add blog posts and selectively not have them appear in the RSS feed. This way when older updates are made they don't plaster readers' feed readers with tips on how to work with ten year old software.

Rethinking Web Forms

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.

The race to Drupal 5

So I've been working with Drupal 5 which recently came out in beta. There are still a number of key modules to be converted and a world of testing but I can say oh my this is going to be a fantastic release.

Federated users in Drupal

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.

Dreamhost earns mixed reviews

Back in July I looked at moving web hosts to Dreamhost as they got high marks on several Drupal related boards. Indeed they have a lot of great ideas. Ultimately two problems caused me to invoke the 97-day money-back guarantee.

The first problem reared it's head as I started to transition domains to Dreamhost. If one has a "fully hosted" domain with Dreamhost they presume that you will have your "www." name pointed to their www server. Therefore it's not possible to have their DNS setup without having www.example.com pointed at their server. This makes for tough going when one wants to test and transition.

Fatally, however, the email system for IMAP was terribly unreliable. Time after time it would ask for my password when it had just been given. Perhaps it's a client issue or a conflict between the client and server but whatever the root cause it proved fatal for their hosting. It does seem that POP clients worked reasonably well.

Dreamhost's MySQL, PHP and therefore Drupal support earn high marks. It would be great if they'd add it as a goodie to install in their hosting control but it works pretty well otherwise.

Never store tar backups in web accessible directory

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.

Time for a new look

It is time for a new look. Looking through the Drupal Theme Gallery there are several nice new additions. We'll try this one for at least a few days and see how it works. So far so good. Onward!

Sharing Space

First a minor clarification. While this serise has been titled a redesign, we're really talking here about first doing a re-implementation in order to enable a re-design.

.htaccess

Once a site is in produciton it's best to do away with .htaccess for performance. This is simple enough as the directives in .htaccess can be put in the Apache configuration file. For these early stages, though, it is great to have a .htaccess file so you can make changes without having to restart. Drupal ships with a .htaccess file that works for re-writing URLs so one can do "clean" URLs.

The problem with the site at hand, however, is it needs to still access the old site while the new Drupal site is going up around it. Drupal's .htaccess file contains the following directives that we are concerned with:

  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]

This tells the webserver that if a client requests a file and there is no file by that name and no directory by that name to send /index.php instead and to take the requested "page" and send it as an argument. Thus /node/3 becomes index.php?q=node/3. This works fine if the user requests a regular file. However it breaks down if they request a directory. If a user requests /oldsite/ Apache doesn't know that the "if the file doesn't exist" part applies to /oldsite/index.html until it is too late. Apache merrily serves up index.php.

To solve this problem (and a couple of variations) we add the following three lines before the three above in the .htaccess file:

Category: 

Pages

Subscribe to Joshua Brauer: All Drupal items Subscribe to Joshua Brauer: Drupal Planet only