Looking into the processes on our server, we discovered that our httpd threads were running with very high CPU usage. It wasn't out of the ordinary for an average httpd thread to hit 80-100% usage. MySQL usage wasn't terribly high. Unfortunately, the problem wasn't easily reproduced. Certain pages loaded quickly at certain times. At other times they lagged for an eternity.

However, I found the answer when digging into the Zend Cache internals. It turns out that Zend Cache helpfully includes an option for garbage collection and periodic cache cleaning.

automatic_cleaning_factor

According to Zend, this option "tune(s) the automatic cleaning process (garbage collector): 0 means no automatic cache cleaning, 1 means systematic cache cleaning and x > 1 means automatic random cleaning 1 times in x write operations."

Sadly, this default setting was wreaking havoc with our highly trafficked server. So, I disabled it, with the following line of code in our config/site.php:

define('CACHE_FRONTEND_OPTIONS', serialize(array('automatic_cleaning_factor' => 0)));

The result? Average httpd thread has dropped from 50-100% down to 6-7%. I would encourage anyone running the default Zehd file cache adapter to check out this option. The improvement in speed has been dramatic. 

Andrew Embler is jazzed about the improvement of speed in concrete 5.4.

While the concrete5 page list block provides an RSS feed option, it isn't perfect. Its URL is a little unwieldy, and changes to the page list block may interfere with that RSS feed working. Additionally, I had some filtering requirements for my RSS feed that the page list couldn't quite provide. Those problems are on our radar, but I needed a fix now!

So what did I do? I made a custom single page and controller, at the /feed/ URL. Here are the components:

/controllers/feed.php

<?
 
class FeedController extends Controller {
 
   public function view() {
      Loader::model('page_list');
      header('Content-type: text/xml');
      echo "<?xml version=\"1.0\"?>\n"; ?>
 
   <rss version="2.0">
     <channel>
      <title>andrewembler.com</title>
      <link><?=BASE_URL . DIR_REL?>/feed</link>
      <description>The written words and audio of Andrew Embler, 
      on topics such as concrete5, the web, personal computing, music and art.</description> 
 
   <?
      $pl = new PageList();
      $pl->filterByCollectionTypeHandle('post');
      $pl->sortByPublicDateDescending();
      $posts = $pl->get(10);
      $nav = Loader::helper('navigation');
      foreach($posts as $p) { ?>
 
         <item>
           <title><?=htmlspecialchars($p->getCollectionName());?></title>
           <link><?=BASE_URL . $nav->getLinkToCollection($p)?></link>
           <description>
           <![CDATA[
            <? $a = new Area('Main'); $a->display($p); ?>
            <br/><br/>
            <a href="<?=BASE_URL . $nav->getLinkToCollection($p)?>">Comment on this at andrewembler.com</a>
           ]]>
           </description>
           <pubDate><?=date( 'D, d M Y H:i:s T', strtotime($p->getCollectionDatePublic())) ?></pubDate>
         </item>
      <? } ?>
 
      </channel>
   </rss>
 
   <?
 
      exit;
   }
 
}

As you can see, pretty straightforward. Call the PageList class, filter by post type, setup sorting, and print out RSS XML.

/single_pages/feed.php

This file is empty!

The controller contains the entire logic of the feed generator. The feed.php single page only exists so concrete5 will allow us to create it as a single page, through the dashboard. Simple and easy.

On Wednesday, January 27, Apple introduced a project that's been in development for what can best be described as "fucking forever." The Apple Tablet – in whatever form that might take – has been a mainstay of Apple rumor sites since the death of the Newton in 1998. Interest in an Apple tablet has waxed and waned over the years, but just prior to this announcement, the hype bar had been set high, with reports about Apple speculation breaking out of the tech blogs and landing in mainstream newspapers, magazines, and television shows. Steve Jobs had even reportedly called the project the most important thing he'd ever done. Obviously Jobs has a remarkable gift for hyperbole, but he's never said anything like this about the Apple TV or the iPod. This product was going to be something special. 

And, perhaps unfortunately for the iPad, it was amidst this aura of lofty expectations and frenzied interest that the actual device came. And the dismissals followed almost as quickly. Oh, not from me, of course. And not from the financial sector. But from the tech press and those that read it? Disdain and derision. The reductive "fail!" could be found in the comments section of every article on the subject. Nevermind that these were the same people predicting the product would sell for twice its actual price. Nevermind that these people had never used the device in question. The backlash from many within the industry was swift and brutal.

And also wrong.

Much of the wailing in the tech press has been about what the iPad can't replace or augment. Each and every commenter and blogger seems to already have a home computer, a laptop and a smartphone, and finds it frustrating the iPad doesn't seem like a suitable addition to this lineup. But what about houses with only one computer, in which some additional web access, movie viewing or game play is desired? Our house was exactly such a place, a couple years ago, and I'll tell you this: every post-announcement morning, when I'm waking up with my cup of coffee and perusing my morning websites on the couch, I find myself staring with barely concealed hatred at the keyboard of the MacBook that I'm using. Oh, why can't you begone when I'm not using you!?

But even in my anecdote, I'm substituting a MacBook for an iPad. And I think that's part of the problem. In my example, and in all the examples posted by disgruntled Apple tablet devotees, we're thinking too small. I think the iPad is about to usher in an era of ubiquitous computing, in which computers are everywhere, fulfilling many functions, without the cruft of their lineage, like keyboards and mice. These things are thin and light enough that one might even mount them on a kitchen wall, or a refrigerator. Instead of a dashboard-mounted GPS device? Get an iPad. Instead of an in-car DVD player? Get an iPad. Instead of a bulky laptop to store recipes and podcasts on, for use in the kitchen? Get an iPad. These things are almost cheap enough to make that a reality. Like the iPod before it, these things are going to be everywhere. They're going to be appliances, with the power and backbone of a computer.

So, tech folks: don't ask how the iPad will replace a system in your highly ordered, highly scientific world view. We're tech people. We're kind the of people who organize our preference panes. We employ a meticulous file hierarchy. We keep our computer desktops free of virtual detritus. We owned MP3 players before iPods! We brainstorm features for email clients. Over drinks. In our LEISURE time! We enjoy using computers as much for the using of them, as we do to actually accomplish goals. The iPad can't compete with that. It wasn't built to. However, instead of lugging a laptop or netbook into the living room, kitchen, car, or on a plane, why not leave it in the den, and pick up an iPad instead. Hell, why not get two?

Andrew Embler would like two, please.

While wrapping up a site for a client, I encountered a problem that I decided to solve in new, more sensible way. You see, the client's concrete5 theme – as many do – has a sidebar with some special properties and CSS classes that differ a bit from the main content area. With this in mind, blocks of content and functionality, when added to the sidebar, need to be wrapped in some extra DIVs, to add additional style and padding to the content.

That's easy, right? That's concrete5 101: just create a custom template for your block, and apply that to your block. Copy the view.php file from your core block into your local directory, and apply the changes there. Easy as pie! Right? 

There's a problem with that approach. Read on for more.

Custom Template Views: All or Nothing

While the approach above is great and allows for endless flexibility, it's an all-or-nothing option: you have to copy all of the block's view template into your current directory, and work on the template that way. This is great when you want to make fundamental changes to the way the block appears, but when you just want to wrap the block in some content, and leave the block's actual view template unchanged, it's a bit cumbersome.

Furthermore, the two blocks I was working with were the form and the survey blocks. The view templates for these blocks are not lightweight. Plus, these blocks are complex. If the core view templates change in the future, I may miss out on some additional styles or features, having forked the entire template. It seemed like a bit much, since all I wanted to do was wrap the entire contents of the block in two DIVs.

A Solution

Fortunately, there's an easy solution to this problem.

1. Create a custom template like you would at any other point. 
2. Within this custom template, add the new DIVs required by the special custom template. 
3. Within the DIV, instead of cutting and pasting the entirety of the block's view template, cut and paste this instead:

<? 
$bvt = new BlockViewTemplate($b); 
$bvt->setBlockCustomTemplate(false);
include($bvt->getTemplate());
?>

I'll walk you through what's going on here. First, we instantiate the BlockViewTemplate class, with our current block's object passed into the constructor. This object is the $b object, and it is always in the scope of  a block's view template. 

Next, we call setCustomTemplate method for the block's view template, and pass false as its argument. Why? If we didn't do this, we'd have an infinite loop on our hands. That's because the block object we're currently working with already has a custom template. That's the template that we're rendering right now! So what we're doing here is basically refreshing the current block, and grabbing the template for the block when a custom template is not activated. 

Finally, once complete, we call getTemplate() to return the block's template before a custom one was set. For the form, this will be /path/to/concrete/blocks/form/view.php. We include this, confident that it will continue to work and remain up to date in the future, and knowing we didn't have to duplicate a large amount of view code just to do something simple. 

Andrew Embler just wants to make your coding life easier and a little more elegant.

A mobile world.

In the world of smartphones, the iPhone was a game-changer. We can debate the relative merits of the various players, but it can't be denied that, when it debuted, the iPhone brought a lot to the table. Nowhere is this more apparent than when using Mobile Safari. The world finally had a usable, standards-compliant mobile browser.

However, something interesting occurred almost immediatley after the iPhone was released. Web designers began creating iPhone-specific websites. These websites use stylesheets (and sometimes entire images and content) to tailor their form factor and presentation specifically to Mobile Safari. They will also frequently ape the iPhone aesthetic. 

Initially, this puzzled me. If web designers are building standards-compliant websites with decent liquid layouts, Mobile Safari displays them quite well, and pretty quickly. For example, this site, when viewed on Mobile Safari, displays impressively well, with no tailoring toward Mobile Safari in particular. 

However, as I started thinking about it, I realized that most websites aren't exactly like your garden variety blog. They have grown to include lots of JavaScript, images, and extraneous cruft that can slow down rendering on the iPhone's more lightweight processor. In these cases a mobile version can make a noticeable difference – even though the regular website could still easily be viewed. 

Enter c5touch.

With all of this in mind, I present to you c5touch, a Mobile-Safari-optimized concrete5 theme. 

c5touch is based on an impressive Wordpress theme named WPTouch. If you run a Wordpress blog, I highly recommend it.  c5touch doesn't do half of what WPTouch does. This is partially because Wordpress, by its very nature, is a much more structured system than concrete5. But it's also because c5touch is young, and is being made available more as a simple exercise in what's possible in concrete5 with a little bit of tweaking. I would love for some enterprising soul to extend it in further directions. Consider this initial offering a proof of concept.

Download, Installation and Setup Instructions

concrete5 makes it easy to install and activate themes. c5touch is a little bit different, however, for one reason: it's not the only theme you're going to have on your site. c5touch compliments your site's main theme. You install c5touch, but you leave your site's main theme (or themes) activated, and add some code to your site to enable the usage of c5touch when concrete5 detects your site is being requested by Mobile Safari.

Before You Start

1. Download c5touch

Grab c5touch from here.

2. Install c5touch on your site.

FTP c5touch to the local themes directory on your site. Unzip it and install it through the dashboard. Don't activate it! (For more information on how to install a theme in your concrete5 site, check out this link)

3. Modify concrete/libraries/view.php

As of this writing, the latest stable release of concrete5 is 5.3.3.1. This tutorial requires a change to the core which have not yet been released. You can, however, add the change to the core file directly, confident that it will eventually be released.

First, locate the comment that says

// Extract controller information from the view, and put it in the current context

And add the following line above, so your source looks like:

Events::fire('on_start', $this);
 
// Extract controller information from the view, and put it in the current context
 

4. Enable application events for your site.

Enabling support for concrete5's application events allows site developers to hook custom application and website code into common concrete5 actions, without having to modify the core. These must be enabled first, however. Add the following line to config/site.php:

define('ENABLE_APPLICATION_EVENTS', true);

5. Hook into the global "on_start" event.

The on_start event (which we added to older concrete5 versions in step 3) is run by the view library at the very beginning of a page rendering session. This is before a theme or controller is loaded. It is here that we wish to check which browser is requesting our site and, if necessary, switch to our iPhone-optimized theme.

First, create a file named site_events.php in the config/ directory. Then, paste the following code into this file.

Events::extend('on_start', 'ThemeSwitcher', 'checkForIphone', 'libraries/theme_switcher.php');

This code may look complex, but it's fairly simple. The first argument, "on_start" is simply the name of the concrete5 application event we'd like to hook into (note, this is separate from controller-level or page-type-level events.) The second argument, "ThemeSwitcher" is the name of a class we're going to call a method in. The third argument, "checkForIphone" is the method in the ThemeSwitcher class that we're going to call. Finally, the fourth argument tells us where we can find the ThemeSwitcher class.

6. Create the ThemeSwitcher class at the proper location.

Now we need to create the proper class file at the location specified in step 5. Create an empty file in your local libraries directory, named "theme_switcher.php" Then, paste these contents into the file (minus the line numbers.)

<?
 
class ThemeSwitcher {
 
   public function checkForIphone($view) {
      if (strstr($_SERVER['HTTP_USER_AGENT'], 'iPhone') ||
         strstr($_SERVER['HTTP_USER_AGENT'], 'Android') ||
	 strstr($_SERVER['HTTP_USER_AGENT'], 'webOS')) {
         $iphone = PageTheme::getByHandle('c5touch');
         $view->setTheme($iphone);
      }
   }
 
}

This is code is quite simple. It simply checks to the current request's user agent to see if it contains keywords that indicate the user is using a mobile webkit device. (Update: This now includes Android and Palm's webOS.) If so, we grab the theme object for the c5touch theme and render the view (which is passed as an argument to the method) using that theme.

And that's it! Bask in the glow of iPhone compatibility. 

Additional Notes and Other Helpful Tips

Now, you'll probably notice that there is still a bit of work to be done to get your site to look top-notch on the iPhone. c5touch is a starter theme, but you'll still likely have to create page types and some custom style rules to really get everything to look great. Here are some things I've done on andrewembler.com to go the extra mile.

1. Add some of your main site's css to the iPhone optimized theme by using c5touch/site.css.

Your site may look somewhat drab. Copy some of the block-level and reusable styles that you're using throughout your site from your main theme, into the c5touch site, using the empty site.css stylesheet. For example, all my masthead images have drop shadows and some other effects applied to them. I copied this from my main theme into my iPhone-optimized theme.

2. Scale images

While my text looked great when I started using c5touch, the images within the content space were much too large, and looked silly. So I'm using the following custom code in my image block view template to scale them down.

<div class="main-image">
<?
$v = View::getInstance();
if ($v->getThemeHandle() == 'c5touch') { 
	$ih = Loader::helper('image');
	$ih->outputThumbnail($f, 275, 1000);
	?>
<? } else { ?>
	<div><img src="<?=$f->getRelativePath()?>" class="footer-image" 
width="<?=$f->getAttribute('width')?>" height="<?=$f->getAttribute('height')?>" 
alt="footer image" /></div>
<? } ?>
 
<? if ($altText) { ?>
<div class="main-image-caption"><?=$altText?></div>
<? } ?>
 
</div>

This code ensures that, when images are displayed in the c5touch theme, they will be scaled down, using concrete5's autoresize algorithm (which takes care of caching, transparency, etc...)

3. Experiment!

This tutorial is meant as a starting point. Currently, c5touch is by no means a drop-in solution. If there's enough interest, I'll investigate expanding this into a concrete5 package. This would be ideal, as the package format could automate all of the various steps that currently have to be performed by a developer. But in the meantime, I'd love feedback from anyone, as well as suggestions. I hope this proves useful. 

As CTO of concrete5, Andrew Embler is required to be tethered to his iPhone 24/7. This will make that a little bit easier. He would love to hear from you below, or through twitter.

We've heard the criticism: concrete5 isn't as fast it should be, on low-end hardware. Know that we're taking this to heart with our next version, due out in several months. concrete5 version 4 should feature a number of improvements to speed up both the editing and viewing processes, including more AJAX-based editing (which reduces costly and time-consuming page refreshes) and much more usage of the built-in cache.

However, there are other ways to speed up a concrete5 site that can be done today. Your site can benefit by removing certain unneeded or unused portions of code.

1. Don't use jQuery? Don't load it!

concrete5 uses jQuery extensively, and we love it (at least, I do.) However, it's not necessary for all front-end functions. If you're not using jQuery in your site on every page, remove it from the required header for users who aren't logged in. This will ensure that the site doesn't load unnecesssary and costly JavaScript, while also keeping it editable.

To do this: 

1. Copy concrete/elements/header_required.php into your local elements/ directory.
2. Open this file, and locate these lines:

$this->addHeaderItem($html->css('ccm.base.css'), 'CORE');
$this->addHeaderItem($html->javascript('jquery.js'), 'CORE');
$this->addHeaderItem($html->javascript('ccm.base.js'), 'CORE');

3. Change those lines to this:

if ($u->isRegistered()) { 
	$this->addHeaderItem($html->css('ccm.base.css'), 'CORE');
	$this->addHeaderItem($html->javascript('jquery.js'), 'CORE');
	$this->addHeaderItem($html->javascript('ccm.base.js'), 'CORE');
}

2. Don't make your theme editable.

I think the way we've enabled designers to make editable stylesheets is one of concrete5's coolest, nearly-unknown features. (Click here for an introduction and example.) However, if you're working on a site for a client, you probably don't need this. Furthermore, did you know that by enabling this feature, you're parsing a stylesheet for editable rules, when you don't need to?

Granted, the stylesheet gets cached, and you're probably not losing a lot of performance. But every little bit helps, and waste is waste. To change this, look for any lines in your theme that are called this way:

$this->getStylesheet('my_stylesheet.css');

and change them to:

<?=$this->getThemePath()?>/my_stylesheet.css

3. Make sure you're running an opcode cache on your web server.

This is a must. Make sure you're at least running Zend Optimizer on your web server. If at all possible, forego Zend Optimizer entirely, and use something like APC, XCache or eAccelerator. (Note: we used to recommend eAccelerator primarily, but its lack of maintenance concerns me. Perhaps APC instead?)

4. Building Custom Blocks? Don't put expensive logic in their constructor!

We've seen it frequently, and we may even have been guilty of it from time to time. What's that? Putting block startup logic in the block constructor (the __construct) method.

Why is this bad? Isn't that where it's supposed to go? Well, block's get instantiated at several points in concrete5, and that means that the block is going to run those functions every time that happens. Instead, stick your block startup logic in a method named "on_start." That method only runs once (plus, you can be sure it will run at the right point.) 

5. Use API Methods whenever possible.

Rather than making custom calls to concrete5 tables, use the API methods if at all possible. How does this help performance? Well, here's the trick: it doesn't always. Sometimes (*gulp*) it might even hurt performance. 

But - and this is a big but - in the long run, these are the best methods to use for performance and code accuracy. In version 4, we're going to be addressing caching for a large number of built-in objects, including attributes, users and files (pages and their attributes are already cached.) This means that if you use the built-in API for files or users, you'll automatically get caching, and that means performance increases. 

Andrew Embler loves the thrill of watching a large number of SQL queries drop, drop, drop...

Recorded in Christmas 2008, as a response to the ridiculous hype over abnormal wintery weather conditions here in Portland, OR.

Additional concrete5 theme-related documentation can be found at concrete5.org.

Code Recap

The following are examples of the code that was used in the movie, to setup editable areas, and make a template editable.

Add an area named "Main Content 2" to a page

<?php
    $a = new Area('Main Content 2');
    $a->display($c);
?>

Make a template editable

Remove the title tag from a template, and replace it with this:

<?php 
    Loader::element('header_required'); 
 ?>

Common area and template names

Standard area and template names for themes

Just to clarify, for those whose php is a little rusty and couldn't see the coding example in the video too well, the syntax for getThemePath is:

 <?=$this->getThemePath()?>

And to insert it into a line that originally says:

  <link href="style.css" rel="stylesheet" type="text/css" />

And add it like this:

<link href="<?=$this->getThemePath()?>/style.css" rel="stylesheet" type="text/css" />

January, 2002

Lackey: Hi, Steve? Er – sorry; Mr. Jobs? Hi, my name’s Frank. I work down in, oh well, it’s not important. Anyway, I just wanted to let you know that there’s this site – Spymac – that’s been getting a lot of press lately with some leaks about an Apple PDA. I know, I know – it’s total bullshit. They’re pulling these pictures out of their ass. But it’s got people talking. Their mockups are really hideous, but what if we did something like that? Not something so played, like a PDA, but maybe something like PDA, phone combo? Wouldn’t that be cool? Hello, hello?

March, 2003.

Lackey: Yes, Mr. Jobs? It’s Frank again. Hey, I’ve gotta tell you – we’ve been monitoring Mac-related chatter in magazines and on forums, and there’s this guy, Dvorak? You know him? God, he won’t shut up about Apple switching to Intel processors. I know, I know! Please don’t be angry with me – I know it’s a pain in the ass, and would require massive developer support. Yes, I know it would be almost impossible to get legacy apps to run well. But, but we have to dosomething! He just won’t shut up about it; he’s driving everybody nuts!

March, 2006

Frank: Hey, Jobso! How’s it going? I’m bananas about Intel right now, B-T-W. Anyways, just wanted to let you know, there’s a bunch of people running their mouth about that PDA rumor. I know, I know – I thought that we could shut’em up with the Rokr too, but that thing was such a piece, right? Anyway, I still think it would kill, if we did it right.

January, 2007.

Frank: Stevie! What’s happening? Congrats on the iPhone? That thing is pimp! It’s gonna move like nothing else. Yeah, umm, that’s what I’m calling about. I know, I know – we’ve given them Intel, we’ve given them a goddamn phone – what more can these people want? Everything they ever crow about is getting handed to them and it’s never enough. You know, I heard a few of them clamoring on, hoping that they’d be able to make apps for the iPhone. I know! I told them that the web is gonna be really bangin’ on this machine, but they wouldn’t let it go. We might need to look into that. Maybe some kind of SDK, some paltry gesture – well, we’re gonna have to do something to shut these people up.

And that’s not all. The latest thing? A subnotebook. Subnotebook. I don’t even know what that means either! Doesn’t matter that we make the best damn portables in the industry. They want something smaller! Something lighter! Yeah, it’s horseshit, isn’t it. Anyways, that’s it.

January, 2008

Frank: Another killer keynote, Steve. Love the new iPhone firmware. Those dancing icons are the fucking best. Anyway, diggin’ the MacBook Air, the new Mac Pros. Seems like everything’s sewn up, right? I mean…these rumor sites, they’ve got everything now! I’m predicting three months, max, and they’ll be closing up shop. Talk to you later, buddy.

Andrew Embler still thinks Apple humor is funny. He can followed and suitably congratulated on twitter.