I recently relaunched my website using some best practices I’ve learned over recent years. This is the first part of a post series detailing some of the steps I took and why.
The first step of rebuilding my website was to get the structure set up. I had run WordPress itself off of a checkout from Subversion for a while, but I typically took it a step further on client sites and wanted to do that with my site. The real trick here is to setting it up in a way that you maximize external repositories, while still being able to support your theme and other supporting materials inside a version control service. As I mentioned, Subversion supports what are known as “externals.” These are references to other source code repositories. They are ones that you support or that another developer maintains and makes publicly available.
The first step is to set up a repository of your own. I run a subversion server on one of my servers. But you can also find hosted services that offer repositories such as http://svnrepository.com/. This will allow you to check out a local working copy and start building your site. The next step is to do some minor setup in your repository.
WordPress has a Subversion repository which follows the standard practice of tagging versions. You can think of a tag as a snapshot of code. Many plugins are also hosted by WordPress.org which offers plugin/theme hosting. Theme and plugin authors check in their code to a subversion repository and once you know the basic URL structure, anyone can check it out anonymously. The themes and plugins also typically follow the branch/tag/trunk structure. However, for your theme, I would not recommend referencing it as an external. You wouldn’t be able to check your changes into your repository. It would be better to download it and add it to your repository or to export it into your sites directory structure and add it to your repository. If you were going to build a child theme off it, referencing it as an external might make sense. It all depends on what you need to do.
Here are the basic steps I take to set up a site:
- Create subversion repository
- Check out repository on my local machine
- Add branch/tags/trunk folders
- Create “database”, “graphics”, “providedItems”, and “src” directories inside the trunk directory
- Database stores content/structure dumps of my local development database
- Graphics stores design assets from the sites designer or my PSD files created for the site
- Provided Items stores things like copy, and other misc items related to the site
- Src will be the site root
- Move into src directory
- Create external reference to WordPress subversion tag for a folder called something like “wp”
- You can do it however you would like, but cannot install WordPress in the root. It’s ok though because you can put an index.php in the site root that will include WordPress and use WordPress’s configuration settings so that the wp directory doesn’t display in your sites URL.
- Create content directory, then inside of content, themes, plugins, uploads
- This is basically a recreation of the wp-content folder. You use one outside of the WordPress folder because WordPress is now an external reference, and you can’t check items into WordPress’s repository. By moving the wp-content directory, you can check in things like your themes/plugins into your repository and still enjoy version control.
- Create a folder in /content/themes/ for my theme and add in the theme I will be building from
- I have maintained a fork of the Sandbox theme for a while now, but have never made it publicly available, I may do that sometime soon. But it’s basically a very generic theme that offers lots of CSS classes/ID’s and has some customizations I’ve made to it to make certain things easier (like including page specific JS/CSS, etc).
- Back in the site root, create index.php, add a favicon.ico, robots.txt
- You should always include a favicon.ico file, even if it is just a blank one. Browsers automatically request it, and if it does not exist then WordPress still “spins up” to serve a 404 error, increasing server load. You can also block favicon.ico requests at the .htaccess level if you prefer.
- Create a wp-config.php in the site root and do configuration edits, setup database, etc
- One of the key edits here will be telling WordPress that you have moved the wp-content folder. The WordPress Codex has a pretty good write-up on edits you can make to wp-config.php.
- Go through install process with WordPress
- In the /content/plugins/ directory, I add external references for any plugins I plan to use for the site which point at the latest release tag for that plugin
- I have some standard plugins I always include in installs, but you can include any other plugins that you would like. Some of the default ones I always install are the Google XML SiteMap generator, All In One SEO Pack, and WordPress File Monitor.
- Activate plugins in the WordPress admin
- Activate theme in the WordPress admin
- Perform any default settings in WordPress admin
- Export data/structure of database and add to the /trunk/database/ folder
- Develop theme
At certain points you might need to commit your changes to Subversion so that you can do an “svn update” and get all the files for the external references you setup, but this post isn’t really meant to be a full Subversion how-to. Feel free to ask questions if you need to in comments and I’ll try to help out. In the end you end up with a structure something like this:
- Repository Root/
- branches/
- tags/
- trunk/
- database/ – Store database exports here
- graphics/
- providedItems/
- src/
- content/
- plugins/
- Plugin 1 – svn:externals reference
- Plugin 2 – svn:externals reference
- Plugin 3 – svn:externals reference
- <etc>
- themes/
- <Your Theme>/
- uploads/
- plugins/
- wp/ – svn:externals reference
- index.php
- favicon.ico
- wp-config.php
- content/
I think that pretty much covers the setup, but if something doesn’t make sense, feel free to ask questions. Once you have this structure setup, you’re free to develop your theme and check it into your repository / enjoy source code versioning. Once you’re ready to launch the site, you can either export your repository and upload it to the server, or if you want to be fancy you can check the repository out on your server and let the site run off it so that if you need to do updates later, all you’ll have to do is log in to the server and run an “svn update” to deploy.
Roughly 9-10 months ago, I switched from my iPhone to an enV2 with Verizon. AT&T’s coverage was just horrible, basically making my iPhone an iPod Touch with an expensive monthly subscription cost. Anyhow, the enV2 served me well, but I got to where I was needing to keep a closer eye on some things (WordPress Easily, some work stuff, etc) so moving back to a real “Smart Phone” was making sense. Enter the BlackBerry Curve.
I am a Web Developer located in Richmond, VA. Primarily, I work on the back-end of websites utilizing my database and desktop application coding experience from the past to achieve desired results for the user interface. Recently however I have started moving more into the UI realm, utilizing JavaScript and AJAX to allow for better performance out of the back-end systems.