PHP

Searching Drupal - my presentation from FLDrupalCamp

Submitted by on

Tags: 

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

Submitted by on

Tags: 

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

Submitted by on

Tags: 

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 :)

URL aliases tip for migrating from Wordpress to Drupal

Submitted by on

Tags: 

I recently re-launched a site of mine, breastfeedingfordads.com, which I migrated from Wordpress to Drupal. It took a bit of work to get the basics the way I wanted, and replicate the functionality of the plugins I was using, but it seems to work well.

There was a bit of a problem, however. Out of the box, all of the old articles that were converted to the "blog" content type (as created using the converter mentioned before) had the arcane default URL structure of "content/[title-raw]". An obvious problem was that this didn't match the Wordpress default nor my custom format of "[yyyy]/[mm]/[title-raw]". This was leaving me with lots of unnecessary 404 errors and disgruntled visitors, so it needed to be fixed.

Here's how I fixed it:

First off I had to update the existing settings so that Global Redirect wouldn't keep re-building the wrong ones..

  • I went to the "Automated Alias Settings" page (Site Building -> URL Aliases -> Automated Alias Settings).
  • Under the "General Settings" section I removed everything from the "Strings to Remove" text box so all words would be retained.
  • Under the "General Settings" section I also enabled the "Reduce strings to letters and numbers from ASCII-96"
  • Under the "Node Path Settings" section I updated "Blog entry paths" to "[yyyy]/[mm]/[title-raw]".
  • Under the
  • After that I hit "Save Configuration".

Next off I had to purge the old aliases:

  • I went to the "Delete Aliases" page (Site Building -> URL Aliases -> Delete Aliases).
  • Once there I selected "content" and clicked "Delete Aliases Now".
  • After a moment all of the page aliases had been removed.

Lastly, I wanted to create the correct aliases ahead of time - I could have left it Global Redirect to do, but best to take care of this now:

  • Again, back to the "Automated Alias Settings" page.
  • Under the "Node Path Settings" section I opened the "Replacement Patterns" section and clicked on "Bulk generate aliases".
  • I think clicked "Save Configuration" to have all of the URLs updated, and because there were more than 50 nodes to update I had to run it twice.

Note that the last step could have been done in one step by updating the "Maximum number f objects to alias in a bulk operation" to a higher number, but on very large sites you should be careful to not set it too high or the page will time out.

Anyway, after a few quick moments all of the old URLs were no longer generating 404 errors.

Tips for Google CSE plugin for Drupal

Submitted by on

Tags: 

If you've decided to use the Google Custom Search Engine (CSE) plugin for Drupal, there are a few things you can do to make life easier for your visitors:

  • Add some rewrite rules (to the .htaccess file) to redirect requests for the old search engine to the new one. This can help visitors who know how Drupal works and were typing their search manually, etc.
    • RewriteRule ^search$ /search/google [R=301,NC,L]
    • RewriteRule ^search/node$ /search/google [R=301,NC,L]
    • RewriteRule ^search/node/(.*)$ /search/google?query=$1 [R=301,NC,L]
    • RewriteRule ^search/taxonomy_search$ /search/google [R=301,NC,L]
    • RewriteRule ^search/taxonomy_search/(.*)$ /search/google?query=$1 [R=301,NC,L]
  • Disable the built-in search engine module to reduce memory overhead and speed up page requests.
  • Use some CSS to hide the google.com background image added to the search boxes:
    • input.form-text {
    • background-image: none !important;
    • }
  • If you have custom search boxes replace them with code that calls the Google CSE engine, i.e.:
    • <?php print drupal_get_form('google_cse_searchbox_form');?>

Put together this can make the GoogleCSE almost(*) completely transparent to your visitors.

* Note: I'm not sure if it's a feature or a bug, but I'm going to go with the latter - all search result pages for GoogleCSE append a great deal of information to the URL instead of just submitting these fields transparently via the API call. This is obviously not very user friendly for advanced users who can normally just go to e.g. /search/node/doodlebutt to search for "doodlebutt", or for occasions when you're doing tricks on the search engine, instead when visitors do this they're just putting their search term into the search box and will have to click the Search box to see any results.

Pages

Subscribe to PHP