I’m currently in the middle of upgrading my WordPress installation to 1.5.1.3, and thus things might not be working quite right around here for a bit. I’m not dead, and I will be going back to my original design once I can take to time to develop a theme properly. With all all of the hacking I did to the default installation of WordPress 1.2.1, it could be a little while. Bear with me…thanks
When creating a website, it’s best not to make experimental changes to your code directly on your server for the whole world to see. What if you accidentally mess things up beyond all recognition and don’t remember exactly what you did? It’s a good idea to test developmental changes in a protected environment where you know they won’t effect anything that’s mission critical. Typically this is simple to do as you can just edit the files on your local machine before uploading them. Making a test bed for WordPress, however, is a bit more difficult due to the nature of dynamic page generation.
WordPress uses PHP to pull data from a database, and then subsequently creates the needed HTML based off of that data. Without the PHP, your page would merely render as junk. Thus, in order to see a design change made in your CSS, you’re usually forced to upload the file to your server so WordPress has access to its heart and soul. Not anymore…
In an effort to make things easier on WordPress users wanting to customize the default installation, I’ve created a static version of the default WP template and have placed it in a zip file along with a clean copy of wp-layout.css and print.css. The template includes a sample entry that utilizes many common HTML elements so you can tell exactly what they would look like on your page.
In this developmental sandbox, you can make structural code changes, try out new CSS techniques, whatever you want…all without having to worry about messing up your live site. Once you get things the way you like them, simply update your real files accordingly, and you’re good to go!
Last week, Andrei Herasimchuk of Design by Fire announced a contest to see who could take his site’s current design and “clean it up, optimizing it for best semantic and structural architecture.” Having the final code judged by three industry bigwigs (Dave Shea, Dean Jackson, and Eric Meyer), Andrei is offering the winner their choice of any three Adobe products. It’s a widely known fact that software from Adobe is like crack to designers, so I figured I’d have a go at it.
I by no means would consider myself an “expert” on web standards (at least not in the same league as these guys), but my anal-retentive temperament has provided me with the abnormal patience to sit down and scour the web for details regarding this subject matter. I’d like to think that although I may not have a lot of industry experience, I have read tons about web standards and do enough work on my own to offer advice when it’s needed.
The contest consisted of cleaning up three different pages of code, and also optimizing the CSS involved in creating the look of Andrei’s site. Initially underestimating the amount of time it would take to complete this cleanup, I immediately downloaded the necessary source code and began hacking away.
One of the things that surprised me when I first switched from Movable Type to WordPress was its lack of multiple templates. In MT you create numerous templates which allow you to change the look of different pages on your site (i.e., the homepage, archive pages, individual entries, etc.). If you want a list of your favorite links to appear on the homepage, but not on the page for an individual entry, you just delete that section of code from the appropriate template.
WordPress handles its pages a bit differently. Everything is based off of a single template, and through the magic of database queries and dynamic page generation, the right content is always shown according to which type of page you’re looking at.
By using a single template, the default installation of WP will show the exact same sidebar on every page, and likewise, whenever you view an entry listing, it will always look the same. This one-template structure is viewed as a blessing to some, but an over-simplification to others.
What if you want to show a list of just the entry titles on your archive pages, rather than the entire entry itself? What if you want to hide the sidebar’s calendar on your individual entry pages? There are countless scenarios like these that require a little more flexibility than the default index.php file can give you.
This issue has been discussed many times on the WordPress support forums, but I’ve found most of the proposed solutions to be less than ideal. It’s rumored that the functionality to control these types of things will be built into WordPress 1.3, but for the time being, it seems we’re on our own.
Many people suggest using .htaccess rules and simply forward visitors to templates other than index.php. I feel this method over-complicates things, and here’s why:
Using some simple PHP and the functionality that’s already built into WordPress, you can easily control what appears on different page types without having to create multiple templates. The key lies in exploiting a few under appreciated variables…