Wednesday Oct 31 '07 (by Qasim)Custom site-wide and user profile tracker views

One of the coolest stock features of Drupal is that it can display tables of node editing/adding activity to general site users - both for all activity on the site as well as per user (on their profiles).

Some of you may be familiar with this functionality from social networking sites like Facebook (the Wall on user profiles), and thus know that sometimes all information shouldn't show by default in these listings.  For example, you may not want to display every edit an admin makes to somewhat-static page content. 

Guess what?  Drupal's so cool - it not only shows you tracker info, but also lets you customize the display of it!  All you need is to firstly activate the tracker module, then install Views and activate the stock-packaged tracker view.

As with any other View on a site, you can customise your new tracker but be sure to keep its location and name unchanged; that ensures it'll over-right Drupal's default tracker.

Now, if you want to also customise the tabs labelled 'Track' on user profiles, you'll need to clone the view you just activated.  This new clone you can call whatever you wish - such as 'usertracker.'  The usertracker can be again customised in terms of fields and filters etc...  Note: do not change its location - make sure it is 'user/$arg/track' so that Drupal sees this new view and loads it instead of the default.  Save the view et voila; it should show up on user's Track tabs; this affords you tons of flexibility to show/hide node types, add header text and stylesheet calls (in the view header) and much more! :)

Remember, you can re-write the URLs leading to your user trackers to sync em up with how you've setup your general user profile aliasing; just be sure to write the appropriate rule in the user-tracker settings of the Pathauto module (e.g. 'community/[user]/track').

Sunday Oct 28 '07 (by Qasim)The pathauto module and bulk node url updates

Drupal's native URL-rewriting functionality is pretty groovy; with a stock install of Drupal you can simply write the custom, semantic/human-readable URL for any node when creating/editing it!

However, things can get a little messy if you plan on writing URLs each time you add new nodes to your site; its makes sense to apply rules to how the URLs are written; such as making all blog entries follow a pattern like 'site.com/blog/[date]/[nodetitle]' - in case you're not familiar with it, there's a module which can do this really simply; its called Pathauto.

I use the Pathauto module on every site that we build in Drupal at Design Guru, but and in keeping up with the latest releases have noticed a change in workflow with the module I'd like to share with you - up until recently you could change the URL role for, say, a node type, and then simply click a 'bulk update' checkmark at '/admin/settings/pathauto' and that would over-write any existing URL aliases you've created on your site.  Great feature eh?  Well, supposedly there were some hiccups with large sites so the module developers have removed this check...

If you're using the newest verison of Pathauto and want to rewrite a rule for a node type etc, you'll either have to edit your database tables to delete the appropriate URLs, then change the rule and update node paths for non-existing aliases (the only option now available in the module) or delete all aliases (easily done at 'admin/build/path') on your site and then chage the appropriate rules, and create new aliases for all nodes using the Pathauto module settings.

Tuesday Oct 23 '07 (by Qasim)Input formats and wysiwyg editors

I'll be posting something later today about what options you have when considering wysiwyg editors for Drupal websites but firstly want to make note that its very important to pay a visit to your input format options to make sure things are setup properly per project you work on.

You can typically access the input formats at 'admin/settings/filters' - a lot of people simply use the default Drupal inputs, which are great but when you use a wysiwyg editor some customisation may be required.

Specifically - with a wysiwyg (like FCK or TinyMCE), you may not want to let anyone but admins use the editor; if you're not adding new roles on your site for admins because just one person logs in as the site-wide general admin, there's nothing to worry about but if you have other people doing administrative tasks you may want to create admin roles and then assign the 'full HTML' input type to just a couple of them.

Once you've made sure that the right roles are configured to use the full HTML input type, remember that wysiwyg editors will auto-format line breaks, so to void premature line-breaks and funky formatting in general, be sure to turn off the line-break feature of the full HTML input type...

Wednesday Oct 17 '07 (by Qasim)Making drupal site administration easier

With the advent of Drupal 5.x administrative features moved to the '/admin' URL (with clean URLs on of course), which is really nice because you can see, at a glance, pretty much all of the things you can do to administer your site.

However, until you become super familiar with how drupal's admin is laid out (Site Configuration vs. Site Building etc...), it can still be quite time consuming to look through the admin page... in comes a couple of 3rd party modules that can not only save you time but also make site administration more intuitive and fun!

First up - the Drupal Administration Menu (aptly titled eh?!); its a great little module that throws a drop-down menu atop your site that's powered by the navigation menu itself; which means you don't need to move any menu items into a new menu or anything.  Oh, and it works with most themes pretty seamlessly; the module's menu is completely CSS - so no javascript code to mess with other scripts!

Secondly - Instead of creating a new place on your site to administrate the site, why not make the standard Navigation menu admin options easier to use?  I suggest installing the DHMTL menu module; which automatically makes duplicates of your menu blocks which use a simple javascripted/dhtml approach to facilitating collapsible menus! That's right folks; now you don't have soooo many page loads when working through hierarchical menus. :)

Personally, I like using dhtml menus because it gives site administrators the same UI that all site users have.

Monday Oct 15 '07 (by Qasim)open your mind - understanding Drupal core concepts and terminology

Like any new software, if you've never used Drupal then you'll have to suffer a learning curve... though, if you're excited about doing amazing things with it that will change the world, then this won't be an issue :) 

I highly recommend not jumping into the deep when when you're a newbie; that means - don't feel pressured to learn everything about Drupal because you have a project deadline!  Its much better to have the peace of mind going into a paid project - knowing both your limitations as well as those of the software you're using.

First step: read up; there's a wealth of knowledge over in the Drupal Handbooks and they read pretty easily.  Get cracking with Drupal terminology and try to think about examples in your life where you relate things with conceptual taxonomies, for example.  It may sound geeky to philosophize about software but once your brain understands how Drupal works, working with it will feel much more natural. :)

If you've got the time to think about working with Drupal, do it until you can't wait to play around and then its time to setup a dev server - something I'll be posting about soon!