Thu 24 November 2011
What do I mean by “using WordPress as a library”? Usually, when building WordPress based project one takes vanilla WordPress source, and then applies various adjustments on it. To shape WordPress to your needs, you have to cut the original sources in several places.
|- wp-admin # administration module, most likely not to be edited
|- wp-content # directory where user themes and plugins dwell
|- wp-includes # probably not to be edited
|- wp-config.php # config created by user
+- wp-blah-blah.php # other distribution files that should not be edited
So making an application implies a need to make a lot of changes
in different places in a source tree.
And this is far away from what I mean of “usage as a library”,
so how is third party source code used like a library?
Here I name few examples: Smarty, Doctrine, NuSoap.
All these products are just put in a corner of your project,
and their files do not blend with files edited by your own.
This makes easier things easier when upgrading the library, –
just replace the directory with sources.
And in general it adds clarity to the code.
So the problem is that WordPress has to be adjusted in many places
inside its source tree.
But can we move all these points where changes should be done
to the separate directory. Of course we can,
and this post is about how to do it.
And the principles stated here actualy applies not only to WordPress,
but actually to many other CMS and frameworks.
First of all after studying WordPress source code,
I have found that wp-config.php,
does not have to be in the root WordPress distribution directory,
but also in the directory that is one level up of it.
This means that we can create directory called “blog”,
let it be the root directory of our project.
Inside it we have wordpress directory.
And this is good – we already moved config file out.
The next thing is to move wp-content out of WordPress.
Actually we do not move this directory out just make copy of it –
and it will be the directory,
where major customizations of our blog will happen.
So inside “blog” directory, we create “app” directory, –
this is where we keep files changed by us.
Nevertheless we will make this directory our application root.
Inside this root there will be directory wp-content and favicon.ico image.
And if is needed also .htaccess.
Now in our blog we have two directories “wordpress”,
which is immutable source code of WordPress, and directory “app”,
which contains nothing but only our customizations.
Now we have to setup a virtual host for WordPress
so that document root would be situated in app directory.
And when HTTP request comes to it,
then the request tries to get to the file which is in the directory,
but if not, then go to corresponding file in “wordpress” directory.
To achieve that we have to configure vhost in a certain way.
We will rely on Apache directive “AliasMatch”.
Here is how it goes::
<VirtualHost *:80 >
CustomLog "/home/user/blog.dev.dev-access.log" combined
<Directory "/home/user/blog/app" >
Options Indexes FollowSymLinks Includes ExecCGI
Allow from all
AliasMatch /wp-(.*).php /home/user/blog/wordpress/wp-$1.php
AliasMatch /index.php /home/user/blog/wordpress/index.php
AliasMatch /wp-admin/(.*) /home/user/blog/wordpress/wp-admin/$1
That is it, we now have directory structure like this:
|- wordpress # do not touch it unless upgrading WordPress
|- app # Here aoof files that we edit
+- wp-config # application config, editable
Of course this setup applies to development version,
and we have to merge these directories when deployed on live,
to return to original WordPress directory structure.
But we solved our problem,-
in development environment we use WordPress as a library.