Vim tips articles
Thursday, October 26th, 2006A quick pointer to a really useful series of Vim articles by Joe ‘Zonker’ Brockmeier that also appear on Linux.com.
A quick pointer to a really useful series of Vim articles by Joe ‘Zonker’ Brockmeier that also appear on Linux.com.
We’ve been working with Tim and Wandy, the owners of Planula Bed and Breakfast/Divers Retreat, for over three years now on their site underwater.com.au and for almost the same amount of time have been saying that we need to update the Planula site.
Well of course we’re happy to say it’s now done and was released a few days ago.
Having successfully maintained their own website for years, Tim and Wandy were, and still are, understandably hesitant about moving from a static HTML site they knew, to a new database-driven solution. I’d like to run through a few of the reasons we encouraged (bullied?) them into using Wordpress.
I’ve mentioned some general reasons to use a solution like Wordpress in a previous post. Here are a few more specific ones which, while referring to Planula, are equally relevant to many sites.
They were already doing a lot of copying and pasting to add new content which works fine for consistent content but is a more work if, for example, new pages need to be added.
It’s very easy on a static html site for small inconsistencies to build up over time and become harder to change, e.g. with navigational elements. Altering the left navigation in the new site is now as simple as adding new pages and/or shuffling current ones in admin.
Their latest content can now be consumed by anyone who subscribes to it via the automatically generated newsfeeds. This is an effortless form of marketing and can be used in a variety of ways such as their “Latest News” on the Planula listing page on underwater.com.au.
There are always sections in websites that aren’t immediately clear and need time and use to get a better idea on how they should be approached. This is much easier if things can be moved around quickly to respond to changing needs or circumstances.
It would be naive to pretend that this solution is the be-all, end-all and I’ve already mentioned Tim and Wandy having some hesitation. Their primary concern was how much they would be tied to this solution and what if they needed to change to another or back to a static HTML site?
Thankfully this is also a common concern for developers and therefore there are several solutions or “exit strategies”:
Methods exist to import Wordpress data into other solutions, such as Textpattern and Drupal. As a sidenote; It’s quite notable just how many more there seem to be for importing into Wordpress.
It would be possible to do this via Wordpress itself but there already exist other solutions like Blue Crab which “is a program that you use to copy the contents of a website to your computer, in whole or in part”. This is a Mac desktop application but of course Windows equivalents exist
Another point worth mentioning; the site has now moved from a tables-based layout to one based on CSS stylesheets which on the whole (apart from the markup introduced by a few plugins) means somewhat smaller pages sizes and more content dense HTML. The separation of the page styling also means future changes to the look of the site can be introduced across the whole site much more quickly.
We’re waiting to see how these changes affect the visits and search engine behaviour of what is already a popular website. Of course we’re hoping they improve even more.
So go visit the site and even better visit Byron Bay and stay at Planula!
If you’re in the mood for design patterns, my article, Decorating with External Data has just been published on Zend Developer Zone and runs through an example of using the Decorator.
I’m really interested to see it get a bit of a kicking from those who really know their design patterns, so if you’re one of those people please let me know of anything I should or should not do in the comments here or at DevZone.
Yes, I know the title is a little cheesy, but it does introduce some of the recent projects we have been working on.
One of the things that is often requested is a means for businesses to update their own content and this generally requires some kind of content management system. For previous larger projects like underwater.com.au, the requirements have been specific enough to require a custom system to be developed. For smaller projects, however, a custom solution is often overkill. In this article I’m going to run through some of the thoughts that went into developing a couple of sites using Wordpress.
Yongala Dive is a small dive resort based in the Great Barrier Reef Marine Park which primarily runs trips to the famous S.S. Yongala Wreck.
Their previous static site was difficult to update and maintain and was also in need of search engine optimisation. We started by looking at their statistics to get an indication of how the site was being used and from that came up with the following overview:
These were some of the findings that were used in the development of the site and influenced decisions, such as, what order pages appeared in the site navigation.
I initially started looking at using a pared down version of our own content management system but decided that in this case it would have been the wrong choice. Instead, the advantages of using a solution like Wordpress include:
Bear in mind that many of the above benefits apply not only to your involvement in the project, but also in the case of you no longer working on the site. If, for example, your client employs an in-house developer it will be to your benefit to have allowed for that.
The Australian Divemaster Academy is an initiative of Byron Bay Dive Centre, taking students from beginner to Divemaster in 10 weeks of training.
The main requirement for this site, aside from introducing the course, was to provide a means for the non-technical staff to update news and the program calendar. The relative simplicity of Wordpress’ “Write Post” process was really the key reason to use it.
We also added the WP-iCal plugin to publish the calendar posts to an .ics format so that calendar applications like iCal, Sunbird and the upcoming Outlook 2007, can subscribe and be kept up to date with program availability.
Wordpress is not a panacea and I have to admit that moving from developing object-oriented, MVC-architected, design-pattern-influenced, ok-I-sound-like-a-wanker, code to Wordpress and many of its plugins feels like a step back in time. Articles recommending what not to do when developing modern PHP applications could find examples in Wordpress and its plugins.
Just to mention a few: Functions are often huge and on occasion perform everything from querying the database to outputting the HTML. The API seems geared mainly towards retrieving HTML output when often you’d like to set or retrieve more basic data like an array or an integer. Many plugins would benefit greatly from updating the indexing of the database columns but make no such recommendation.
One example is a plugin that had database queries nested in two levels of loops. Having first retrieved some data, it used it to loop through another query and in turn, used that to loop through a further query. In a small test it had already run over 100 queries and would have increased in line with the number of posts. A reworking of the code reduced the total queries down to 2. (Note: I did do what you’re supposed to do with open-source code you see needing some work; fix it and send its developer the reworked solution. I’ve intentionally not named the plugin as a mark of gratitude to anyone who gives their time to helping others out.)
However, before I go on and on, getting all precious and code nazi, I have to admit that it is fun to hack away at Wordpress. If your client makes a request the first thing you can do is Google for a plugin. Often there are a selection that almost meet the mark which can then be used as a prototype to show the client. If not immediately appropriate, most can be adapted to the needs of the business.
In short while you still need to be vigilant there is a real sense of liberation in being able to focus on finding solutions to your clients needs rather than getting overly (and the danger being unnecessarily) precious about the code itself.
Anyone looking for a good comprehensive run through of a Zend Framework application should read Rob Allen’s My Take on a Zend Framework Tutorial.
As it’s a PDF, you might like to read it using this trick from Jon Udell: Vertical PowerBook as ebook reader. He uses a Mac but I’m sure you can achieve much the same on other OS’s.
While getting the hang of the Zend_Controller_RewriteRouter, which is now included in Zend Framework 0.1.5, I was adding the routes in my index.php (bootstrap) file and wondered if there was any way of storing them elsewhere. It is possible to loop over Zend_Controller_RewriteRouter::addRoutes() but the method I will describe here is based on some recent updates to Zend_Controller_RewriteRouter by its author Michael Minicki.
The point of RewriteRouter is to map urls, like ingredients.com.au/recipe/tomato_sambal, to whatever controller, action and parameters needed without having to use external (and often painful!) methods like mod_rewrite.
For the sake of this article I’ll use a relatively simple URL…
ingredients.com.au/articles/cooking/
First setup some routes in a config file “routes.php”. Note that this does require the latest version of the RewriteRouter which needs to be checked out from the subversion repository…
$config['routes']['articles'] =
new Zend_Controller_Router_Route('articles/:category',
array('category' => 'all',
'controller' => 'articles',
'action' => 'index' ),
array('category' => '[a-z_]+') );
This establishes a route called “articles” that will respond to any url of the form “/articles/whatever” with the colon in :category indicating that it is an url variable that can be recovered through Zend_Controller_Action::_getParam( ‘category’ ). The controller and action indexes make the action “indexAction” in the controller file “ArticlesController.php” the final target. To cover cases where there is no category specified the default setting “all” is given. For extra assurance :category has to be a string containing only lower case letters and underscores as indicated by the final requirements array.
Next load them into the bootstrap file using Zend_Config_Array:
$routes = new Zend_Config(
Zend_Config_Array::load(
'../application/configuration/routes.php', 'routes' ) );
Then create the RewriteRouter object and pass it the $routes…
$router = new Zend_Controller_RewriteRouter;
$router->addRoutes( $routes );
All that is needed now is to pass the $router to the front controller…
$controller = Zend_Controller_Front::getInstance();
$controller->setRouter( $router );
That’s it, now the routes are nicely stored outside of the bootstrap file and with the rest of the domain files.
Aside from the manual pages mentioned I can’t close without pointing to an actual recipe for tomato sambal !!
I should also mention that it’s well worth getting involved with the development of the framework even if you can only do so in a small way. After a relatively short discussion via the issue tracker about having some means to load routes in one hit, Michael Minicki had implemented one (thanks Michael).