Web Development

menu_link_save doesn't like aliases (drupal)


A quick tip.. while working on an install profile in Drupal I discovered that the menu_link_save() function requires an internal URL, e.g. "node/123" instead of "my-cool-page". Once I tracked down the issue I was able to very easily create lots of menu items as needed, but it wasn't entirely obvious this was needed. I was using install_profile_api to create the menu items and figured it was going to make things easier for the end user, but alas no, so I threw together a quick patch to save others the headache, and wasted hours of development time.

Downgrading svn repositories from 1.5 to 1.4


It's an odd situation, but occasionally you need to convert your data to run on an older version of an application rather than the typical upgrade to newer versions. One such situation arose for me recently. I was starting a new project and was beginning to add/change code while working from home after-hours, with obviously no server admins around to IM a request for a new subversion repository. Being the agile developer I am, I figured I'd just create a local repository and upload it when I was next at the office.

As you may know, practice rarely follows theory. The theory was that I'd just do an svnadmin dump to create a data dump of my local repository and then svnadmin load to get it onto the main svn server at work. As it turned out, I forgot to check something. You see, the svn server uses v1.4 while I've been running v1.5 for about eight months, since shortly after it was first released - as a result, after several days of development my fresh 1.5 data dump wouldn't work with the server's v1.4. Bummer. I submitted a request for the IT department to upgrade the servers to 1.5 - there are several good reasons to do the upgrade - but it isn't something that's going to happen too quickly due to the need to then have all of the other users upgrade their clients.

Thinking I was going to be stuck for a while keeping my repository locally, I kept working locally and figured I'd be able to just wait the few weeks until the central upgrade. Again, life never works quite like you think it will, and I suddenly immediately needed to be able to upload my work to a staging server. Within an hour of dealing with SFTPing files to the server, trying to ensure two different instances of the servers were kept up-to-date and concurrent, the horrors of Life Before Revision Management came flooding back to me and in a mad panic I set out to get my code into a repository one way or another.

This is where my current web hosting provider, Dreamhost, saved my sanity. I had previously set up a repository on my account for some personal code development so figured I'd repeat my success there with the new project, as it would at least be accessible remotely. A couple of quick minutes had an svn dump of the repository waiting on the server for me to import into a new repository. Except it didn't want to work, it turned out that even Dreamhost was using the older v1.4. Argh! It seemed I was doomed to fail!

It was around now I thought "why don't I RTFM?" A quick look at "svnadmin help dump" didn't turn up anything, ditto for "svnadmin help load". Then I tried "svnadmin help create" and saw the previously unknown (to me) option "--pre-1.5-compatible" which is described as "use format compatible with Subversion versions earlier than 1.5" - a step in the right direction! This option would allow me to create a local repository in my local v1.5 setup which would then be compatible with v1.4. I guessed that it might then also create a dump file compatible with v1.4, which could then be cleanly imported into a new v1.4 repository... and sure enough it worked!

So, the exact steps I took were:

  • Created a dump of the v1.5 repository named myproject_1_5.dump using the command "svnadmin dump myproject > myproject_1_5.dump".
  • Created a new repository that was compatible with v1.4 using the command "svnadmin create --pre-1.5-compatible myproject2".
  • Imported the v1.5 dump file into the new myproject2 with the command "svnadmin load myproject2 < myproject_1_5.dump"
  • Created a dump of the v1.4 repository named myproject_1_4.dump using the command "svnadmin dump > myproject_1_4.dump".
  • Uploaded project_1_4.dump to the hosting account.
  • Created a new repository: svnadmin create myproject
  • Loaded the new data dump: svnadmin load myproject < myproject_1_4.dump".

Then, after a few quick moments (it was only up to rev 103 at this point) I was finally able to get back to development using a centrally accessible repository for a few days until I'm back at the office again and can get it back onto company territory.

NOTE: Yes, I know that git would probably have worked better in this situation, but the company is not currently ready for that move..

Searching Drupal - my presentation from FLDrupalCamp


Today at the first annual FLDrupalCamp I presented a talk on searching Drupal, covering some gotchas, tips and how to best set up your site for both internal searching (searching when on your site) and external searching (someone searching via e.g. Google). This was knowledge built over my career as a web developer, but primarily during the past eight months working on SkiNet.com. The beginning of the talk covers some unexpected issues discovered during development of the site and builds from the knowledge I've gained since then. Enjoy.

Being only the third talk I've ever given at a user group meeting, and definitely being one I was most anxious over due to it having ~70 people in attendance (though I was in the smaller room which had maybe 25), I was quite pleased with how it went. There were some minor tidbits I missed, but I do plan on turning it into a more detailed series of articles (time permitting). One thing I was extremely pleased with was that the lead developer of Drupal 6's internal search engine, Doug Green, happened to attend and at the end during the Q&A he gave some further insight into the engine - thanks Doug!

I hope everyone enjoyed it, and if you happened to attend please leave some feedback so I can hope to improve the talk.

Update 6/25/09: I fixed the problem that was stopping this from being viewable, so enjoy.

Come to DrupalCamp Florida on Feb 7th, 2009


Anyone who has February 7th (2009) available, and who isn't already going to the excellent Acts_as_Conference, should take a trip to Altamonte Springs for DrupalCamp Florida! This new event promises a day's worth of free presentations on all things Drupal from some of Florida's best consultants and advanced users, including the exceedingly talented Ryan Price. I've proposed a few talks myself, and the unconference-style of the weekend will mean almost anyone with a bit of experience should feel comfortable taking a few minutes to share something with the rest of the group. At the time of writing there are about 50 people signed up, so there's plenty more space available. I strongly recommend anyone interested in content management, or even just PHP, take at least some time out of their day on the 7th to come along for a look-see.

In addition to the presentations on the 7th there's an effort to have a workshop / group help-like setup for the 8th, and hopefully we'll get to put some of our skills to good use helping others and learning more.

Be there!

Building a Drupal site - pick a theme


When building a new site in Drupal, unless you've got a large team of developers, one of the first things you're going to want to do is pick a new theme, i.e. a site template. Thanks to the efforts of hundreds of developers from around the world, there are over 170 themes for you to investigate for Drupal 6 (even more if you're stuck with Drupal 5), each one with its own set of traits. For example some use a table-based layout while others use a pure CSS layout, some are single-column designs though most are multi-column, some that have literally tons of slots for you to add content blocks, some with multiple color options, and some that act as just a bare starting point for you to build your own.

Here are a few things to look for when choosing a theme:

Tableless Design

When you design a page layout you have two options for positioning the various components - tables or CSS. Tables are the old way of doing the design and are very inflexible, not to mention difficult to manage, so CSS has become the defacto standard since the millennium.

An important benefit of a CSS design is that you can add an alternative CSS file to make your page instantly printable. It's both horrible from a user friendliness standpoint to require people click to a separate page for it to be printable, but I honestly also find it really dumb to require people do some special trick just to print your content rather than just clicking the browser's Print button. It also gives you, as the site developer (or the person hiring the developer) a much easier time to make global changes, e.g. if you want to make your site all green & red for the holidays or if maybe you decide to tweak the layout a small bit every few months to add some variety, it'll be much easier when there's one master CSS file.

While some of the table-based themes might look good, long-term you and your site will be better off with a CSS-based theme.

Multiple Collapsible Block Regions

Drupal allows you to place portions of content / functionality around your page using things it calls "blocks". Many plugins also can add even more blocks available for you to use, e.g. Tagadelic adds a block showing a tag cloud for your site's keywords, and as a developer you can really easily create your own. Blocks are positioned on your site into spaces called "regions", with most themes having a few standard regions - heading, left sidebar, top sidebar and footer.

While some have taken this flexibility and have gone completely nuts, e.g. AD Blueprint which as 44 regions, I tend to look for one with about eight regions - the usual header, footer and two sidebars, then also one above and below the page content body, plus maybe an additional one between the header and body for e.g. highlighting the week's most important content

Valid Code

In today's technologically competent world there's no excuse for sites to not be present valid code. Using the World Wide Web Consortium's HTML validator and CSS validator, every developer needs to ensure their code is tested and compliant with XHTML 1.0 Transitional ("Strict" is better) and has valid CSS code. Further, themes need to be tested to ensure approximately 99% browser compatibility, which means IE6 & IE7, Firefox and Safari 3. Thankfully most theme developers have done their best to stick with this, so your visitors should have a pleasant experience.

Hopefully the above will help you on your way to build the site of your dreams, with the CMS of your dreams :)


Subscribe to Web Development