I’ve been looking into using some PHP on this blog in order to reduce rebuild times. My sidebar, which is included on each page using Movable Type’s @MTIncludes@ tag is used to collate information from a variety of sources (although currently just my bloglines blogroll). Due to the way MT handles templates, this sidebar is being rebuilt for each and every page – so in the case of my blogroll, thats one request to bloglines per entry, category page, date archive etc. @MTIncludes@ can be used to include static files rather than other Movable Type modules, so my initial thought was to change my sidebar from a module template to an Index Template so it only gets rebuilt once. The problem with this is that @MTIncludes@ performs a static import – that is to say it imports the content when the page doing the including is built, but won’t pick up any changes to the included file afterwards. This is an even bigger problem when you consider how Movable Type rebuilds files – the index templates are the last to get done, so at best the individual entries will have an out of date include, and at worst might not find the file to be included at all.
What is needed is a dynamic include – a way to produce a page fragment once, and have pages automatically include this fragment when required. PHP seemed like the obvious answer, and the solution was surprisingly simple. As an experiment I created two new Index templates – a new experimental index, and my PHP sidebar which is the page fragment to be included. The new PHP index is setup to produce @index.php@, and I inserted the following @require@ statement to pull in my sidebar:
My PHP sidebar just contains the same code, but its output file is now called @sidebar.inc@. The result? Each request to @index.php@ will pull in the latest copy of my sidebar, meaning I can update @sidebar.inc@ without having to rebuild pages which reference it. Additionally, I can put more computationally intensive operations in the sidebar as it is only built once.
My next step is to roll this out across the rest of the site. Before I can do this I’m going to need to handle the fact that many of my current pages with a @html@ suffix are going to become @php@ files. Luckily I was planning to “de-cruft my URL’s(Cruft-free URLs in Movable Type)”:http://diveintomark.org/archives/2003/08/15/slugs anyway, and one of the steps for doing this involves setting up Apache redirects to hide the suffix from the outside world and making sure old references can still find the new files.
magpiebrain 
4 Responses to “A more efficient Movable Type with PHP”
Doesn’t this mean that work needs to be done every time anyone *reads* your pages, as opposed to every time you change them? Surely this is *more* work?
Depending, that is, on how often your pages get read. 😉
Nope – you see MT builds the sidebar once, and creates a sidebar.inc file. PHP does get invoked per page request to include sidebar.inc, but its farily good at that sort of thing. So on the one hand you have longer rebuild times and more polling of sites like bloglines (to the extent that the guy who runs del.icio.us said “Please stop!”), on the other hand you have much shorter rebuild times but with a slight hit on each page request.
I’d hope that Apache/PHP would be smart enough to know when it can cache the pages in question (if sidebar.inc hasn’t changed for example). If this caching is good, then it should be nearly as efficient as returning a ststic page.
interesting, because when I tried to use php require in my index template a week or so ago, it created an error (which exactly, i cannot remember) (and yes it was being saved as a php file)
Guess i’ll try again – at least i know now that someone else has found success with it.
There is certainly no problem using PHP in MovableType. MT ignores PHP and leaves it untouched. I did have some problems getting all of my pages to find the sidebar.inc file – I had to add a new search path to include_path like so:
==
php_value include_path ‘.:/usr/local/php-4.3.4/lib/php:/path/to/my/sidebar.inc’
==