Archive for the ‘Drupal’ Category

Speeding up Drupal cache flushing

April 21st, 2015 No comments

Are your cache clears slow?

Do you use features? It's great, but can become quite the beast when you run a "drush cc all" or a "drush fra" - and today we figured out why the "drush cc all" is an issue. Because when hook_flush_caches() runs, if you don't explicitly define this as FALSE, it will run the "fra" for you inside of your cache clear!

Add this to your settings.php:

$conf['features_rebuild_on_flush'] = FALSE;

Since we run our fra separately, we've disabled this, and noticed quite a reduction in time to "flush caches" (which was not only flushing caches but also reverting features, apparently!)

It's that unknown-to-us-before-today variable in the snippet below...

 * Implements hook_flush_caches().
function features_flush_caches() {
  if (variable_get('features_rebuild_on_flush', TRUE)) {
    // Don't flush the modules cache during installation, for performance reasons.
    if (variable_get('install_task') == 'done') {
      features_get_modules(NULL, TRUE);
  return array();
Categories: Drupal

Poor man's Global Redirect for Drupal 6.x

March 22nd, 2011 No comments

I was moving a customer's site from an old HTML and individual PHP page site to a friendly URL site managed by Drupal, and I only cared about intercepting URLs with those file extensions. I installed Global Redirect on a Drupal 6.x site, and the entire site started going into an infinite redirect, before I even had time to configure it. I had to use Drush to disable the module, and immediately uninstalled Global Redirect since I didn't have time to debug what was going on, and hacked this up.

I didn't really need this to do much. The code is simple and there is no UI to manage it, but it works, and even gives you cute little X-Redirect headers to let you know if it was executed and if it found a match. It would be easy enough to take that if() out and have it check any URL (just be sure to remove the fallback :))

function foo_init() {
    if(stristr($_SERVER['REQUEST_URI'], '.php') || stristr($_SERVER['REQUEST_URI'], '.htm')) {
        $old = parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH);
        $new = db_result(db_query("SELECT new_url FROM custom_redirect WHERE old_url = '%s'", $old));
        if($new) {
            watchdog('foo', $old.' found in the custom_redirect table', NULL, WATCHDOG_INFO);
            header('X-Redirect: Found');
            drupal_goto('http://'.$_SERVER['HTTP_HOST'].$new, '', '', 301);
        } else {
            watchdog('foo', $old.' NOT found in the custom_redirect table', NULL, WATCHDOG_ERROR);
            header('X-Redirect: Not Found');
            drupal_goto('http://'.$_SERVER['HTTP_HOST'].'/', '', '', 302);

The table?

CREATE TABLE custom_redirect (
  old_url varchar(150) NOT NULL,
  new_url varchar(150) NOT NULL,
  PRIMARY KEY (old_url)

Enjoy. Totally could have Drupal'ed that up and made a hook_install() for the schema too, right? :p

Categories: Drupal, PHP

Drupal is NOT a CMS.

October 9th, 2010 No comments

Contrary to what you may call it, and even what they say it is - a "Content Management Platform" - I consider it to be an extensible core framework that "happens to ship with many content related features by default."

Stripping it down to bare bones would reveal a flexible and fairly well designed framework that can be used for anything really.

That's my major beef with Drupal - that it ships with so much content-specific functionality in place. For instance a node is something everyone universally agrees is a "great concept" - a basic item that is extended by custom options (CCK is the model of how easy this is) - but nodes still have a "Title" and a "Body" and publishing options and other fields that shouldn't be there in a truly generic system. The idea of one central basic element though is spot-on in my mind. With all that in mind, I begin my thoughts...

When it comes down to it, almost everything can be considered some form of a "content" item. For example, I designed something to track transactions. At first I cheated and used CCK and just made some custom fields. I also made a version using Drupal's schema API that just made a normal database table, to skip any CCK overhead and node "addons" Drupal glues on by default. However, the overhead aside, I was able to use this system and with not a lot of code, make a fully functional transaction tracking system based off of node concepts. I used CCK as a "schema designing" frontend, and could use Views to get the information back out in a variety of ways.

Is a transaction "content" in the common sense of the word? Not at all. It's a reference to someone purchasing something, in this case a user purchased another type of node - so really it was just a user reference and a node reference. I didn't care about the "Publishing options" or any of the other Drupal-related built-in node specifics, and anything else that may attach itself to nodes - Pathauto, Fivestar, etc.

I [ab]used the node-based system and CCK's UI to make myself a flexible schema to track transactions. I was also able to use pure API to create a database table and manually track the information, and skip any of the hooks related to node processing (Pathauto, Fivestar, publishing options, etc.) - which one was better? Well, I'm still deciding that. By using the node method I can easily expose it in a view. I am not sure I can using custom schema (I think someone told me I could but I haven't tried yet) - I'd really like to use Views for it, and be lazy on the delivery side of it. By going custom, I track only what I want in the database and save probably many levels of pre- and post-processing on the result set.

Getting back to my original statement - Drupal's foundation is pretty solid. It enables anything to be accomplished, it's just that damn middle layer that I wish would be more decoupled and moved into modules that can be enabled or disabled. For the most part, people who use Drupal seem to use it mainly for it's CMS/"Content Management Platform" capabilities just fine. Some of my sites require custom work though, and that is where I enjoy the framework/platform's underlying capabilities.

Typically when developing a site, there are common elements such as user login/registration/roles and management, form processing, XSS/CSRF/other attack vector protection, output encoding, data and request normalization, etc. I've built my own little library of functions and even a bit of a stub framework to use them which do a lot of this. Drupal however has already generalized most of this and provides it to you for no cost.

Frameworks in the typical definitinion such as RoR, Symfony, and half a million others give you the basics, but don't give you that much. It's still up to you to create everything else. While I may whine about Drupal's content-heavy core packaging, it does provide some built-ins that I do find useful to be included. So I guess that can be chalked up to some personal opinion - I would rather the it push the content stuff out to modules (and strip nodes down to even simpler basic structure) yet keep the user registration, login, role and capabilities and form processing available.

All in all, I am having fun looking through the directories of modules out there, and trying to approach things with a more Drupal-eqsue model in mind, understanding that I will sacrifice some performance and add some overhead, but also save myself the headache of all those tedious user submission and form processing screens and such. That's usually where typical self-coded projects seem to start trailing off for me, is winding up getting into the user interaction piece of it. Database design, delivery - that's easy. Form processing and user experience? Annoying as hell 🙂

Categories: Drupal