Drupal 6

On most projects we have node types created which we have no reason for full page views. Typically these are support node types. If we mix this with the concept that NO page that a user should be able to see should ever have a url like node/456 then it is simple to simply implement the following logic:

If a node page does not have a url alias defined; let's not allow access (unless admin).

This small access override does this:

Quick discovery I made last night.. might save some hair pulling:

In the past I have added tabs using panels (or views) to std node tabs or user tabs… I simply would set their path's to something like node/%node/tab1 or user/$user/tab1

I figured I could do this with completely custom pages as well as long as paths were simliar:

custom/tab1, custom/tab2, etc

It seemed like it should work but it wasn't.

Turns out it sort of was working but there is template.php code required to "enable" tabs for non node/user custom panel pages:

The University of PEI (subcontracted from Dave Kisly) required a complex multipaged user registration form for their CAUBO project. There are a few posts around on creating multipage forms, but most are incorrect, don't apply well to the user registration process or are simply too complex to map to your specific requirements.

We did an initial version of this registration module based on one of these recipe guides but with numerous changes from the client it eventually became a very messy piece of code that was too complex to continue with all the changes required.

Just a quick note to those followers of our blog - as of around August 13, 2010 the Dev release of Views 2.x now supports cloning a display. Very cool feature and huge time saver so thought i would mention it.

You can read more about it here: http://drupal.org/node/348975 .

I seem to vaguely recall the days of D5 when altering fields seemed much simpler.. hmmm.

Anyway, needed to alter a simple label of a field today and took far longer than it should have; so thought I would post here.

Example Case:

Site development regularly extends beyond the launch of the site and beyond the point where the live site has real user accounts set up. To test issues that may be occuring on the site it is usually easier to simply grab a copy of the live site's database to use in your local development environment. Herein lies our issue: How do you test the site on your local development environment with a database that has real email addresses?

I was debugging a Views block the other day and couldn't figure out why it wasn't hitting my block tpl. Pretty scary why it wasn't..