Programatically working with Panels in Drupal is a bit of a nightmare. Trying to figure out how to obtain the right panel display and discover the right load and save tasks can be an utter disaster as you try trace code through ctools, page manager and panels itself while trying to understand what a ctools task or handler is or how to load them.
If you're reading this blog post then you probably know by now that caching Drupal pages with varnish is pretty easy with Drupal 7. So long as the pages are anonymous. As soon as you're logged in however, the game changes. Infact as soon as you obtain a session with PHP, the game changes and you instead rely on block level caching and views and panels caching. For some sites that will be acceptable. But when you start to scale the amount of users hitting your site, PHP just can't keep up and you'll either start to run out of connections or max out your memory.
A while ago I blogged about one of the awesome powers of Drupal 7 - the ability to be database agnostic. The ability to migrate from one database server to another. A shift from one software product to another. Now while that isn't all that newer feature. Till now its been incredibily difficult to do. Till Drupal 7. Last week, I recieved an email asking me about how to migrate a SQLite database to MySQL. While i did try help remotely, I realised it would be much easier to write an open source script to do all the work. And considering the amount of conversation this particular conversation got at Drupalcon Chicago, I decided it was worth even making it into a module with a drush backend ability.
Drupal 7 is Officially released. After 2.5 years of community work, the much perfected Drupal 7 has been released in all its glory. Its features include a test driven code base with a built in test suite, a sparkling new object orientated database layer that supports not just MySQL and PostgreSQL but SQLite also, improved caching and theming layer, file streamers, a major overhaul of the user interface to make Drupal more intuitive for end users.
A friend of mine came around the other night, he just got himself a new iPhone. I'm not really a fan, but good on him. He asked me to let him connect to my wireless router then in a matter of minutes hew had control of my iTunes on a windows laptop of mine. Rather impressive.
After a long while with no blog entries or reviews, I'm back with a new look gearing PostgreSQL support for Drupal up for the upcoming release of the long awaited Drupal 7.
Drupal 7 is almost stable. You maybe tempted to download it now and install it. By all means do! its great! But if you're installing Drupal on a PostgreSQL database, you'll run into a message like this:
Wellington, New Zealand had its first Drupal Meet-up last night since DrupalSouth, New Zealand's Drupal conference, in January this year. We had a good number of people turn out from all over Wellington to share and talk about what they're doing with Drupal. Myself and Mike Haworth both gave presentations on Drupal, mine was on packaging and deployment with Drupal - in particular, where features and drush have their part to play in the process. Attached are my slides for people to look over and/or use (CC license, Attribution required).
IMO, features has been the missing component to Drupal for a long time. Ever since Drupal stored configuration, specific to your project in the database. That makes moving a change in you project from development to staging and to production rather complex and time consuming. While modules like Views and CCK implemented there own exporting techniques, really, the entire Drupal community needed to implement an exportable facet to the modules they offer. Features is quickly providing that facet. With features, out of the box, you can export custom views, content types, imagecache presets, permissions, panels and with strongarm and ctools, variables from the variables table. Here is a how to guide to using features as a Drupal site developer.
One of the most exciting new features about Drupal 7 is the object orientated database layer, or Database: The Next Generation (DBTNG) as it was code named. For the first time in Drupal's history, you can now connect to several different databases of different server types at the same time. All using Drupal's database framework.