Drupal 6: Redirecting the User Destination After Registration

Scenario: An unregistered user visits a page that only logged in users can visit. Say it’s this page:

http://www.your-site.com/protected/page

Drupal throws up the login form, but the URL above remains the same – good as we’re going to use that. If they login, they are brought right back to this page, no problem. But what if they have to register? Assuming you have your User Settings set so that new users are logged in right away (no email confirmation, etc.), you’d of course like to redirect them back to the page they wanted originally. Instead, they just go to their new user account page, and that kinda sucks.

Figuring out a solution to this kinda sucked. After exploring numerous attempts at redirecting the form and using hook_user() – I finally just set a cookie, and blamo, it works. This needs to go into a custom module of yours:

// Implementaion of hook_user
function yourModule_user($op, &$edit, &$account, $category = NULL) {
    $refer = rtrim($_SERVER['HTTP_REFERER'], '/'); // removes any trailing slash
    $refer_array = explode('/', $refer); 
    $len = count($refer_array);
    if ($refer_array[$len - 1] == 'protected' && $refer_array[$len - 2] == 'page') {
        setcookie("YourDrupalDest", 'protected/page/', time()+200);  /* expire in 7.5 minutes */
    }
    switch ($op) {
        case 'insert':
            if ($_COOKIE["YourDrupalDest"]) {
                $_REQUEST['destination'] = 'protected/page/';
            }
            break;

        default:
            # code...
            break;
    }
}

Anyways, hope that helps point someone in the right, erm, destination.

Tweaking Drupal Date-Popup Format in an Exposed View

* Note this entry only pertains to the Date-Popup boxes when used in a Views filter, not a regular node-based form.

views-filter-calToday I needed to change the format of the date-popup box on an exposed views filter. It normally defaults to YYYY-MM-DD as shown to the left there. Most us ‘merican folks don’t like that much. Unfortunately, it only seems to be changeable via creating your own module.

Once you know how to create a Drupal module, just add this to it. With the below code, I reformat the date to the more familiar MM/DD/YYYY format for both the “from date” (min) and “to date” (max) values:

/**
* This will change the date format on all views-exposed forms
*/
function YOUR_MOD_NAME_form_views_exposed_form_alter(&$form, $form_state) {
  $form['date_filter']['min']['#date_format'] = 'm/d/Y';
  $form['date_filter']['max']['#date_format'] = 'm/d/Y';
}

As the comment says, this will change the date formatting for any view that uses these date boxes across the site, which I’m fine with. Whereas with hook_form_alter() we can target a form by incorporating the form id value into a specialized function name, all view IDs are views_exposed_form and that’s just that. If you need to get more specific, you can var_dump($form) the form from within the function and glean some unique info that would allow you to target that particular form using some conditionals, again within the function.

Hope that helps someone else out! Took me a bit to figure that out – cheers.

Trouble Installing PECL’s uploadprogress On OS X – MAMP?

Note – this assumes you are running MAMP on a Mac. For this I’m using Leopard 10.5.8.

All you want to do is get this installed so you can have fancy upload bars in your Drupal 7 installation. So you follow the instructions and only get a bunch of errors. Maybe you see stuff like this:

make: *** [uploadprogress.lo] Error 1

And toward the top of your “make” you see stuff like this:

error: php.h: No such file or directory

I was seriously stumped. I knew this was probably related to having both the default version of PHP that comes with OS X enabled, as well as the MAMP version – but it’s the same stuff, right? Nope – MAMP does not come with everything needed to compile a PECL installation, at least not with my setup (MAMP version 1.7.2 running PHP 5.2.x).

So what you have to whip out the command line and specifically setup your installation environment by explicitly declaring which PHP environment to use. So fire up your Terminal!

OK – MAMP does come with the phpize command, but it’ll setup the wrong environment for our needs. So head into the uploadprogress directory that your downloaded and untarred, and run:

/usr/bin/phpize
./configure --with-php-config=/usr/bin/php-config

Next up:

make
sudo make install

If all went well, you should have no errors, and you’ll have some output telling you the extension directory it placed uploadprogress.so in.

You’ll need to open up MAMP’s php.ini file and make some changes now. For me, this is in MAMP/conf/php5

Around line 428 – you’ll need to put something like this in:

extension_dir = "(insert the outputted extension directory from after you ran the make install command)"

(If you’re like me and already had this setup from installing xdebug, then you’ll need to just move the uploadprogress.so file into the defined directory.)

Now we need to tell php to load this extension. Around line 540 or so, add this:

extension=uploadprogress.so

Now restart MAMP, and you should be all loaded up! If you head over to your Drupal status report, you should see PECL is now installed (image below, my frickin’ badge of honor). Boy, hopefully this is easier on the production server!

pecl-success1

Later that day…

So looks like now that this is up and running, I’ve discovered that Drupal 7.0 has a bug that prevents the progress bar from showing. Hopefully we’ll get this fixed in 7.1.

Later later that day…

This was actually much easier on my Red Hat production server, the commands were pretty much the same. Here it is working with Drupal 6.20:
Uploading... graphic

Put Your 404 Page to Work with URL Splitting

If you launch a new version of a site and the URL structure changes – you can certainly handle most of that with an htaccess file and a 301 Redirect command. But sometimes, as I’ve found at least, this isn’t always the best solution because if some of the URLs have similar parts, your redirect rules can get confused and not behave as expected. Or perhaps your crappy web host doesn’t allow such things.

So instead of pulling your hair out, you can shift some of the burden off onto your 404 File Not Found page. You can make this a php page, and put something like this in your .htaccess file (assumes Apache 2 – I think Apache 1 is different):

ErrorDocument 404 /missing.php

Now, all our missing files and pages will be handled by missing.php – cool. So we can work some PHP magic to help people get where they need to go.

I use this following PHP code quite a bit. It takes the url and splits it into an array, w/o the domain:

$url = explode("/", $_SERVER['REQUEST_URI']);
if ($url[count($url)-1] == '') {
  array_pop($url);
}
if (substr($url[count($url)-1], 0, 9) == 'index.php') {
  array_pop($url);
}

array_shift($url);

Now we have our URL in an array called $url. So a URL like this:

http://www.something.com/products/category/item

Will create an array like this:

array
  0 => 'products'
  1 => 'category'
  2 =>'item'

So now, let’s say we changed the above url structure so that category part is no longer there, rather it’s this:

http://www.something.com/products/item

You can now do something like this in missing.php when someone hits the old, no longer valid url:

if ($url[1] == 'category') {
  header( "HTTP/1.1 301 Moved Permanently" );
  header( "Location: /$url[0]/$url[3]" );
}

What you’re doing here is sending the same kind of 301 redirect that .htaccess can, which lets search engines know this is the permanent new home for this page/file – and then shoots the engine/person over to that page. If the pattern doesn’t match, you should just have some html at the bottom of the page giving the visitor some sort of friendly message, and perhaps providing a link to the home page if you’re really courteous.

Cheers!

How to Fix Minify Error: !FAIL: environment : PHP/server does not auto-HTTP-encode content

So you’ve setup PHP Minify and think you’re a good citizen for making your site zippier. You run the tests in min_unit_tests and all pass, except for the last one:

!FAIL: environment : PHP/server does not auto-HTTP-encode content (1 of 72 tests run so far have failed)

Well isn’t that a pickle? What this means is that your server, likely of the linux variety and likely using mod_deflate, is already compressing everything and it’s getting in the way of how Minify likes to compress the files itself. So you certainly do not want to turn off all that regular compressed goodness across the site, you just want to turn it off in a couple directories and let Minify take over compression duties.

So here’s what you do. In the “min” directory there’s already an .htaccess file. Add this to the end of it:

SetEnvIfNoCase Request_URI .* no-gzip dont-vary

Then you also need to create an .htaccess file within the min_unit_tests directory, and add the above line to that file too, otherwise your unit tests will continue to fail ;)

Still having trouble? Please post or search the Minify Google group, as I’m not sure if I can help much more on this one!