Make a Drupal Field available in the Page Template

Sometimes there's a need to render a Drupal field's value outside the scope of a node template. I used to achieve this with either Display Suite or CCK Blocks. As I'm about to change my workflow towards putting more theming stuff back to code (where it belongs) instead of clicking around slow and clumsy web interfaces I needed another solution.

1. Implement template_preprocess_page() in your theme's template.php

Of course you'll need to replace MYTHEME with the name of your theme, $stage_images with an arbitrary name of your choice and field_stage_images with the name of the field you want to render.

Customizing the Drupal Search Form to make use of Gumby's UI Kit

Yesterday I had a hard time modifying the output of the Search Form of Drupal 7. I needed to modify its HTML, adding wrappers, changing the input to a <button> tag, adding classes and additional markup to insert a font based icon into the button. I'm using the awesome Gumbyframework and took code from travisc's sandbox project, which itself seems to be heavily based on the Bootstrap theme for Drupal.

However, I like to start my themes from scratch with minimal overhead, so here's the stuff I extracted from above mentioned projects and changed a bit to make it work with my current setup (using Gumby 2.6.3).

Everything is inside the template.php of my theme (MYTHEME), so change that to your theme name.

Wie der 1&1 Support funktioniert

  1. Plötzliches Problem mit Website auf 1&1 Managed Server, nur noch die Startseite erreichbar (ohne jegliche Änderungen an CMS/Server/sonstwas)
  2. Ursache suchen, feststellen, dass die .htaccess Datei in einen Urzustand zurückgesetzt wird und somit sämtliche RewriteRules sowie sicherheitsrelevante Einstellungen einfach ins Nirwana geschickt wurden
  3. Eine gestern noch funktionierende .htaccess aus einem Backup einspielen, damit dann alles noch schlimmer machen, nichtmal die Startseite funktioniert
  4. Es verdichtet sich der Verdacht, dass PHP 5.3 einfach plötzlich nicht mehr angeboten wird, denn im Control Center lässt sich nur noch 5.4, 5.5 und dev auswählen.. und in der .htaccess, die fleißig automatisiert (?) überschrieben wird, steht steht der MimeType-Handler auf PHP 5.4 für die entsprechenden Dateiendungen

Faster Import of InnoDB Tables in MySQL

After waiting for more than an hour to import a MySQL dump of ~270 MB I started looking for the bottleneck. My database was mixed with InnoDB and MyISAM tables and it turned out the InnoDB tables took ages to import. I fixed it by wrapping my SQL statements for the InnoDB tables with the following statement:

SET autocommit=0;
# table definitions for the InnoDB table 

If I understood it correctly this reduces the disk input massively. Don't forget the COMMIT statement at the end, as the MySQL reference says:

After disabling autocommit mode by setting the autocommit variable to zero, changes to transaction-safe tables (such as those for InnoDB, BDB, or NDBCLUSTER) are not made permanent immediately. You must use COMMIT to store your changes to disk or ROLLBACK to ignore the changes.


Easier than expected: A Month without Social Media

Yesterday my 30 Days Without Social Media Challenge came to an end. Here are my experiences and the conclusions I made.

1. I didn’t miss Facebook and Twitter half as much as I would have thought

While in the first week I caught myself quite often trying to open the app or website of either Facebook or Twitter it quickly slipped out of my mind in the second week. Instead of just browsing around, looking what everybody is doing and posting general stuff I started reaching out more to people directly via email, text, IM or phone, which is way more satisfying than just posting something and waiting for interaction. That’s definitely a habit worth keeping.

2. Twitter is more important to me than Facebook

As I know most of my Facebook friends in real life I usually have other and better ways of reaching out to them. That is, at least for the ones I care about most.

Less RAM for Drupal 7 with PHP 5.5

There seems to be a significant performance gain with Drupal running on PHP 5.5. The average memory usage on memory-hungry Views went down ~50% on a site I switched to PHP's latest version. Seems the newly introduced OPcache works really well. If you're not afraid of some warnings about the usage of (now) deprecated functions - go ahead and try it.

If your hosting company doesn't offer PHP 5.5 it's time to reconsider: give Uberspace a shot, they have 5.5 as default (and they also have an easy way to change to other versions, of course). Actually, even if your host does offer PHP 5.5, you should consider switching ;)

Don't call me Custom

Just a quick one: Save yourself some trouble and don't ever name your Drupal module anything that ends on _custom, it'll save you some headaches. For example getting unexplainable errors like Warning: Illegal offset type in isset or empty in drupal_theme_access () (line 53 in includes / despite being quite sure you did everything right.

This will happen as soon as your module implements hook_theme.

I found this out thanks to Spiderneo blogging (en francais!) about it. Merci beaucoup :)