While this project is setup to cache tumblr, you can easily modify it to cache any website. It’s built in PHP on the symfony framework.

Configure it by changing the apps/frontend/config/app.yml file to add in the blog name, email, and password, with these config parameters: app_tumblr_blog_name, app_tumblr_email, app_tumblr_password

To cache a page, run it via command line:

./symfony tumblr:cache

Source is on github: Cache Tumblr Admin

This blog is build with WordPress, and in my first year of blogging, one of my posts received a lot of hits. Unfortunately, the default WordPress install I had setup wasn’t able to cope with the demand effectively. It was taking 2-5 seconds for visitors to load a page. That’s unreasonable for a simple blog and I’m sure I lost a lot of visitors because of it. So I looked into ways to make my blog load faster without paying extra for better hosting hardware. That’s when I found an excellent caching plugin called Hyper Cache.

With Hyper Cache, I made my blog page load from 2-5 seconds under heavy load, to down to less than a second,  under load the same load. The HTML itself only takes about 230ms to download, down from 4000ms, allowing the other resources to start downloading in a paralleled fashion much earlier. How is this possible? Well a caching mechanism works like this: The first time a page is requested, it will render it as normal, but what’s different is that it will save the rendered page in a special cache file. Then, subsequent visitors simply get handed this same cache file immediately, without much PHP processing required. It’s like skipping to the front of the line.

So we can see a cache has a huge effect on performance, and made a big difference to my blog, but what other benefits are there?

• Many people won’t know what a cache is, or how to install one
• Better experience for blog owners because they don’t have to learn how to install one after they experience poor site performance
• Blog is more ready to handle getting slashdotted
• Will ultimately give WordPress a much better image

In my opinion, well worth it. So WordPress team, please?

The default Yii Migration command asks the user for a confirmation before running if there are any tables that have been changed, this is quite a sensible default, but I don’t want to be asked if the command should be run after a deployment. Of course it should be.

To see what options can be configured, open the Migrations file

vendors/framework/cli/commands/MigrateCommand.php

Any of the public class variables can be configured in your config/console.php file. Using the commandMap parameter, you can configure values for Yii Commands. Then specify the migrate task, and then the config values you want to change. In this case, I want to change interactive to false, so it won’t ask for a confirmation.

Sample config/console.php:

return array(
 ...
  // database migration, don't ask for confirmation
  'commandMap'=>array(
    'migrate'=>array(
      'class'=>'system.cli.commands.MigrateCommand',
      'interactive'=>false,
    ),
  ),
);

The main configuration file protected/config/main.php returns an array of parameters. Edit this file to merge 2 arrays, 1 from main.php, and another from local.php.

Edit main.php to look like this:

<?php

return CMap::mergeArray(
  array(
    'basePath'=>dirname(__FILE__).DIRECTORY_SEPARATOR.'..',
    'name'=>'Web app',

... other parameters ...

    'params'=>array(
      // this is used in contact page
      'adminEmail'=>'webmaster@example.com',
    ),
  ),
  local_config()
);

// return an array of custom local configuration settings
function local_config()
{
  if (file_exists(dirname(__FILE__).'/local.php'))
  {
    return require_once(dirname(__FILE__).'/local.php');
  }

  return array();
};

And then add any of your own configuration to local.php in the same config directory.

<?php
return array(
  'components'=>array(
    'db'=>array(
      'connectionString' => 'mysql:host=localhost;dbname=db_name',
      'username' => 'my_user',
      'password' => 'secret',
      'enableParamLogging'=>true,
    ),
    'log'=>array(
      'class'=>'CLogRouter',
      'routes'=>array(
        'file'=>array(
          'class'=>'CFileLogRoute',
          'levels'=>'trace, info, error, warning',
        ),
        'profile'=>array(
          'class'=>'CProfileLogRoute',
          'report'=>'summary',
        ),
      ),
    ),
  ),
  'params'=>array(
    // this is used in contact page
    'adminEmail'=>'yourself@example.com',
  ),
);

Here we’ve overridden the adminEmail parameter to yourself@example.com, we’ve added in custom database username and password, and we’ve enabled logging.

Feel free to use this as a straightforward way to add custom config values to your Yii project. Just remember to make local.php an ignored file in Git or Subversion.

We split the template finding code out for code maintainability, and we enhance it on where to look for the file. First it tries to find the template in the language and country eg: en_CA, then it tries to find the template in the matching language, and if that is not found, it falls back to the default language.

/**
 * Load a static page.
 * @param sfRequest $request A request object
 */
public function executePage(sfWebRequest $request)
{
  $template = $this->findTemplate($request->getParameter('view'), $this->getUser()->getCulture());
  $this->forward404Unless($template);
  $this->setTemplate($template);
}

/**
 * Check if a template page exists for a given culture.
 * Be intelligent and check if language & country exist, try language, and then default to english.
 * @param string $name Template filename to check
 * @param string $culture Symfony culture string
 */
protected function findTemplate($name, $culture)
{
  // for safety, strip out all non-alphanumeric characters
  $name = preg_replace('/[^a-zA-Z0-9\s]/', '', $name);

  $directory = $this->getContext()->getModuleDirectory() . DIRECTORY_SEPARATOR ."templates";
  // try language and country: en_CA
  if (is_readable($directory . DIRECTORY_SEPARATOR . $culture. DIRECTORY_SEPARATOR . $name ."Success.php"))
  {
    return $culture. DIRECTORY_SEPARATOR . $name;
  }
  // try langage only: en
  elseif (is_readable($directory . DIRECTORY_SEPARATOR . substr($culture, 0, 2). DIRECTORY_SEPARATOR . $name ."Success.php"))
  {
    return substr($culture, 0, 2). DIRECTORY_SEPARATOR . $name;
  }
  // try default language
  elseif (is_readable($directory . DIRECTORY_SEPARATOR . $name ."Success.php"))
  {
    return $name;
  }
  return false;
}

The template directory should have the default language file as usual, eg: templates/helpSuccess.php, and then there should be folders for each language and possibly language & country with the same filename, but localized. eg: templates/fr/helpSuccess.php

Edit your routing.yml file which is probably located at apps/frontend/config/routing.yml, and add the following routes to add an about, a privacy, and a terms and conditions page.

# static pages
about:
  url:   /about
  param: { module: home, action: page, view: about }
privacy:
  url:   /privacy
  param: { module: home, action: page, view: privacy }
terms:
  url:   /terms
  param: { module: home, action: page, view: terms }

If you are going to keep the generic rules, make sure you add these new rules before the default actions.

Clear your cache:
./symfony clear-cache

Then inside the module named home (create it if it doesn’t exist), add the following action:

  /**
   * Load a static page.
   * @param sfRequest $request A request object
   */
  public function executePage(sfWebRequest $request)
  {
    $directory = $this->getContext()->getModuleDirectory().DIRECTORY_SEPARATOR."templates";
    $name = $request->getParameter('view');
    // for safety, strip out all non-alphanumeric characters
    $name = preg_replace('/[^a-zA-Z0-9\s]/', '', $name);
    if (is_readable($directory.DIRECTORY_SEPARATOR.$name."Success.php"))
    {
      return $this->setTemplate($name);
    }
    else
    {
      $this->forward404();
    }
  }

The template files will be on the home/templates directory, called aboutSuccess.php, privacySuccess.php, and termsSuccess.php

This action will check if the template file exists, and if so load the template, if not it will forward to the 404 not found page. Easy and safe static templates. Add more routes and the appropriate template file as required.

Does it really matter if you use ASP.NET MVC, Struts 2, Yii, or Rails? Well it might, but for many websites these modern frameworks are just as competitive as the next. Use the stack that is most appropriate for your customer’s situation and is the best choice at the time. Since this is the real world, it will probably change a couple of years in the future.

Leverage Community Extensions

Each framework out there has libraries of modules, extensions or plugins that enhance functionality and provide features that would you otherwise would need to write yourself. If it exists, and it’s in good shape, don’t write it yourself, leverage existing extensions that are appropriately licensed for your project.

Future Proof your URLs

It no longer makes sense to have a web site with extensions, be it .html, .php, .jsp, or .whatever you can think of. Arstechnica even created their own .ars, for no reason that I could tell. Yes the web started with .html because websites were simply serving static files, but that is no longer relevant anymore.

If you build a website with .jsp as the suffix to all URLs, and then a couple of years later your boss wants to re-write the website in python, does that mean you change all URLs to be .py, and setup mass url re-writing schemes to handle the old URLs? No, this would be a nightmare. Protect your future self by completely leaving the actual technology used to build the website outside of the URL.

Another bonus is that these URLs also end up being more SEO friendly!

Use a JavaScript Framework (maybe)

If you are building an AJAX heavy website such as GMail or Facebook, use a JavaScript framework. This is not relevant for many sites that simply use JavaScript to provide some enhanced functionality, but for websites that are heavily dependent upon JavaScript and simply cannot function without it.

I’m not talking about jQuery or Prototype, while those are good libraries that abstract the differences between browsers and provide easy to use functions, they are not built as a comprehensive framework. I’m suggesting you use a framework like JavaScriptMVC, SproutCore, or Spry. These frameworks can be used in tandem with jQuery, but go much farther in helping you organize and control your JavaScript code.

Watch a demo video of what JavaScriptMVC can do for you.

I foresee a new framework will be created to make developing fully interactive AJAX applications as easy as it is to write current MVC applications. Current frameworks like Ruby on Rails and Symfony provide everything you need to develop a modern application without having to build plumbing infrastructure; however, they do not provide nice components for interactive applications. In addition to a robust server core, this new framework will have a client side JavaScript component that simplifies the process of building interactive web 2.0 applications. Some critical components would be:

• Form Validation. Libraries do exist to validate forms in JavaScript, but they don’t integrate with the server side form validation. In this new framework you won’t have to write form validation code twice.
• Paginated Lists. Almost all web applications have at least one page where data needs to be searched and listed with pagination. We need to have this same functionality in JavaScript to skip a full page reload and provide local caching of the results.
• Animation Library. While script.aculo.us and jQuery have made simple animations and visual effects much easier to do, I believe we can go even farther. Web applications also need to gain that fluidity and soft animations that desktop applications such as Exposé have had for a couple of years.

I also see huge resources being directed towards mobile development because ALL current generation smart phones are built for an incredible web browsing experience. As home users have switched from desktop computers to laptop computers in the last few years, people will slowly start switching to hand-held devices for their primary communication and Internet needs. Most likely this will have one primary effect: web frameworks will have a mobile optimized version of the site done automatically. Little to none developer intervention will be required as only resolution, text sizes, and layouts will be modified for the mobile version.

Lastly I see tools and libraries around 2D and 3D drawing elements. Most likely these libraries would be rendering to a Canvas or a WebGL element but something better could be created. Both of these are young standards right now that show a lot of promise on delivering the ability to draw pixels directly in a native HTML web page. While they will be used first in simple computer games, I am very interested to see what libraries are created to facilitate these elements being used appropriately inside next generation web applications.

What do you think the next 5 years will bring?

Firefox, Safari, Google Chrome, and soon Opera all support the HTML5 video tag with the ability to play Ogg Theora encoded videos (except Safari). On the other hand, H.264 is only supported by Google Chrome and Safari. Both of these formats do the same thing, they specify a compression standard that allows for efficient playback at relatively small file sizes. There are a number of technical differences, but generally, they preform relatively the same. The big difference between the two is that Ogg Theora is royalty free and available for anybody to use, while H.264 is encumbered by patents held by the MPEG LA association. This same organization will charge anybody who uses it a hefty royalty fee starting in 2011.

If you have a personal blog and want to put a video on your website using H.264 this means you need to have to hire a lawyer to create a deal with the MPEG LA to allow you to use their codec. This will either cost you a lot of money, or they will not allow you to do it. They do have the right to simply deny you if they don’t feel like it.

However, if you use the open Ogg Theora format, you are free to simply upload the video to your website to start using it, the same as uploading an image. Ogg Theora is not covered by any patents and is royalty free.

I don’t understand why both YouTube and Vimeo are both going the non-free route. Is it simply because they have the money to pay MPEG LA? Whatever the case, endorsing H.264 encoded videos as the format for video on the web is an option for large companies with money to pay, but it’s completely the wrong choice for blog writers and any small or medium sized organization.