The motivation for writing this article came from my feeble attempts at trying to discuss a module I'm actively working on (to be covered in a future article) with several very intelligent Drupal developers. Due to the inherently abstract nature of the issues, and for lack of a common language, the end result was that in every case each person just ended up scratching their heads at me without really comprehending what I was really trying to get at.
Technically speaking, Drupal offers a dynamic framework right out of the box, right, so what is meant by "hyper-dynamic"?
Hyper-dynamic, for lack of a better description, refers to sites/sections-of-a-site for which pages do not exist as individual nodes, AND which (for example) are more complex than a single static view/panel. A panel/view which takes arguments, particularly multiple arguments, is an example of hyper-dynamic content delivery.
Getting down to business...
How is this idea of hyper-dynamic content useful and/or or what are the use cases?
As a 'simple' example, let's say we have a multi-regional travel site which caters to people looking for info/deals on casinos. For each region, we'd like to have a separate homepage, AND separate landing pages for each casino within the region. Finally, let's throw in a "Deals" subpage for every region/casino.
So the site hierarchy would look like this:
Name that tune
The challenge is to figure out the fewest parts we can make this architecture, while still maintaining flexibility/maintainability/upgradability.
In this case, we can accomplish our proposed site hierarchy, for an unlimited number of regions/casinos, with as little as 3 views, 3 panels, 2 content-types, and a handful or arguments:
1. "Node listing" - provides node-listing for each region/casino determined by arguments. This view is placed in the "Landing panel" (see below).
2. "Deals listing" - provides deals node-listing for each region/casino. This view is placed within the "Deals panel" (see below).
3. "Homepage listing" - provides node-listing for homepage. This view is place within the "Homepage panel" (see below).
1. Landing panel - Provides complete landing page for each region/casino based on arguments
2. Deals panel - Provides complete "Deals" subpage for each region/casino based on arguments
3. Homepage panel - Provides homepage. Could theoretically even get away with just using the landing panel for this, but by using a separate one for the homepage we get a little more
flexibility and sanity.
There is perhaps no other Drupal-related issue which commands so much attention from site admins, Drupal developers, and Drupal core alike, as the subject of Drupal updates/upgrades.
Site admins typically want to have the 'latest and greatest' version just for general purposes. This is, of course, very understandable, all other things being equal.
Drupal developers like to be able to keep up with the latest release for various reasons: a) to take advantage of new features, b) to keep their skills current, b) because their clients want it, c) as any bonafide geek knows, it's alway fun to check out the new toys.
Drupal core is always concerned about Drupal updates, well because...it's Drupal core. The project and Drupal itself is dead, or at least frozen in time, if it ceases to innovate at semi-consistent intervals.
In a perfect world everyone - site admins, Drupal devs, and Drupal core are always perfectly in sync - all the time, 24/7.
Keeping up with the current version of Drupal core is not always practical. In some cases it might even be downright detrimental! This statement applies particularly to start-up sites, and/or people who are short on time. But you know what...
Having the latest version of Drupal, in and of itself, will likely have little to do with the success of your site. Though each iteration of Drupal does represent it's own quantum leap forward, that is not to say that versions before it are garbage. While this point may seem obvious to many, I've spoken with numerous people who seem to regard anything but the latest version of Drupal as a 'dinosaur'. That's just silly.
By all means - if time is pressing in on you, or your budget is strained, keep up with the latest security updates for your particular version of Drupal and don't give it another thought until there is a more opportune time to upgrade.
By the way, if the new version of Drupal less than 2-3 months old, this advice especially applies for sites which use numerous contributed modules. While many modules are updated before or soon after a new Drupal release, experience has shown that many others contrib modules do not get upgrades and/or reach stability for at least 2-3 months after the initial release date of Drupal core.
Don't be in hurry for your Drupal upgrade if the timing isn't right. Sometimes good things come to those who wait.
I am pleased to announce the official release of the Advanced Theme Construction Kit (atck) (project page):
atck was developed in a production environment for purposes of quickly building css and xhtml valid Drupal themes from scratch without having to un-theme an existing Drupal theme to do it.
atck components include:
1. WYSIWYG grid builder
A browser-based grid builder which produces starter code for a page.tpl.php file. The grid builder itself was originially built by Christos Constandinou and it uses a modified version of Yahoo Grids which is more flexible and easier to customize. With Christos' permission it, and the supporting css, has been customized so that it works for Drupal themes and so that it is css3 valid. Access the builder online (FF only!), or download it and run it locally. [builder cannot be on Drupal.org because of MIT license]
2. style.css [separate download because of BSD license]
style.css contains only the css needed to support what the grid-builder outputs, as well as some general 'resets'. The only modifications one should need to make here would be if they want to make their layout a fixed width and/or a different width (default widths are in %).
3. page-layout.css and template.php
These files are where the visual styling of the site happens. The source of these files is from a combination of code from the Hunchbaque theme and some changes/additions which I added in order to provide baseline settings I prefer and/or provide more granular settings. The beauty of these files is the simplicty of them - they include as little markup/styling as possible to avoid complexity, while at the same time putting many helpful tools/comments at your finger tips so that you can accomplish what you want.
A sample page.tpl.file is included as a reference for finishing your own page.tpl.php file using code output from the grid builder. Note particularly the variable names for the blocks, regions, menus, etc. (at this point the builder does not include those items)
5. fix-ie-6.css and fix-ie-7.css
These files are included for purposes of providing IE-only css to each of the respective versions. By using conditional comments like this we keep the main css files hack-free and atck css3 valid.
Please keep in mind that this is an initial release - comments, contributions, etc welcome! (please file such things at the project issues queue though)
As promised in an earlier article about blocking server spam, here are some advanced tips on shutting the door to these resource leeches:
#1: Non-existent urls getting hammered:
This is can be a major problem, one which I believe has been at least somewhat cured in Drupal 6, but for Drupal 5 and below a request to a non-existent page such as http://yoururl.com/node/vote/ does not trigger a 404 page as you might expect. Instead the entire front page loads up. Annoying enough as it is, but when combined with a confused/malicious bot that continually hammers the non-existent url, the resource load can be enough to weigh heavily even on dedicated server, let alone a shared-hosting account. [note: there is an update in the comments below with more specific information about the versions of Drupal which are affected by this problem]
What to do about it:
Certainly putting any paths you see that are getting hit this way in your robots.txt file is a good idea, but that does not always solve the problem. Sometimes more drastic measures are needed. Below is snippet from an actual .htaccess file that has on several cured malbot instances that were causing significant server slowdowns - feel free to use and append yours appropriately (be sure you do not have a line break before the [OR] if you copy this - and also be sure your last line does not have an [OR]):
#2: Have an IP? Awesome. Now keep bots from even reaching apache
If there is anything good that can be said about server malbots, as compared to their comment spamming cousins, it's that typically a server-spamming bot will have a static ip address instead of a (dreaded) dynamic one. This makes banning it much easier, of course.
During the course of administering a server full of various sites which have been Farked, Dugg, and StumbledUpon'd, I've learned first hand the value of optimizing a Drupal site/server to handle large amounts of traffic. I've also learned that eventually it's likely that the level of optimization for one's Drupal site/server will be rendered mostly irrelevant by frequent, and (mostly) malicious, circumstances.
Malicious and/or misdirected requests
Compared to more popular subjects such as Drupal optimization, Apache, MySQL, and/or PHP optimization - the subject of malicious requests gets a rare mention. Despite losing the popularity contest to those sexier subjects, rest assured, there is a lot more to running a site than just tuning the former items. All of those things can be working really, really well and your site/server can still be hammered to a state of dysfunction - even with very few users coming through the site.
Welcome to the wonderful world of denial of service attacks and/or server spam. Broadly defined this includes anything that is requesting something from your server that is of a malicious (usually the case) and/or misguided origin. Make no mistake it's a problem which anyone who is running a medium to large size web site will contend with, whether they know it or not.
Server spam/DDS attacks are NOT uncommon problems limited only to large or 'unlucky' websites. If you have a server and/or VPS with a frequently trafficked site, or especially one with several frequently trafficked sites you will be amazed at just how much processor, memory, and bandwidth can be allocated to malicious and/or wrongly directed requests at any given point in time. The exact of amount of resources that these leeches suck up varies greatly depending on many factors, but on the high-end I can share that several times over the last 6 months alone I've personally witnessed, and fixed, crippling issues stemming from server spam for sites that I system admin for. Likewise several months ago I was happy to be able to help resurrect Drupal.org one day when it was suffering from a particularly nasty malbot. (How many people has this happened to that never realize what was going on, and who in turn just blamed their host and/or Drupal??)
So once one realizes that server spam is a real, and not theoretical, problem how does one confirm the issue(s) on their own site/server and what can they do about it?