18 Jan

webme-mu: create your own website

I’ve just finished the first version of the site creator. You can create your own website using this wizard.

This involved a bit of work on my part – I needed to separate personal files (images and other downloadables) from internal files (scripts and other resources), and ensure that personal files could be read from anywhere on the server, not necessarily from a web-accessible directory.

Then, I needed to write the site generator to write config files automatically.

Then, WebME needed to be hacked to load the correct config file, based on the domain name requested.

This has worked. I now have two sites running on that server (http://verens.webme.eu/ and http://webme.eu/), both of which use the same engine instance. The only things that are separate are their databases and their personal files.

The best thing about this was that it was possible to do this without compromising the structure of the downloadable version of WebME. The downloadable version and the multi-user version use exactly the same source code. The only difference is in the config file. In the case of the multi-user version, when the config file is loaded, it acts as a proxy, loading the correct site-specific config file.

After all that work, I need a drink! Please, give the site a chance, and report any problems you come across.

8 thoughts on “webme-mu: create your own website

  1. Hi Kae,

    How do you handle the sub domains?
    I’ve playing around with in on different hosts with different settings.
    Some hosts, if you create a folder it is automatically handled as a sub domain.

    But let’t say it isn’t so, or that you don’t want the user to have a physical folder in your www-root, but rather, let’s say www/customers/folder here, I haven’t been able to come up with something good yet.

    I did a lot of playing around with .htaccess and regex to get the given sub domain and direct it to the corresponding folder, but I all managed was getting caught up in a redirection loop… πŸ™

    Do you have any good tips on the topic? Haven’t checked you CMS yet…

    Thanks!
    Mickster

  2. I should have added – I saw at your wizard, that the user can create his/her own sub domain on the fly. Hence my question =)

  3. I’ll write a proper article explaining it later today, but a short version is this:

    1. separate your site-specific files (html templates, images and css) from your engine files (php which serves the site)
    2. make sure all site-specific files are served through a script, instead of accessed directly
    3. have a simple config file which contains DB info and the userbase (the directory where the site-specific files should be served from)
    4. now, the cool bit – move your config.php to somewhere like ~/sites/sitename.com/config.php, and in its place, manually create a config.php which looks at the $_SERVER[‘HTTP_HOST’] and figures out from it where to look for the correct config.php. This allows you to have multiple separate sites served from a single CMS, all based on the domain name.

    I hope that’s clear, but in case it’s not, I’ll write a fuller explanation in a separate article later.

  4. That was a quick response. And good – I do get it πŸ™‚
    1-3 is done, I just got to figure out if step 4 works all the way for me. I had some arguments against doing it that way, but can’t remember them now. Hmmm.

    But first I’m gonna do some KFM 1.4 testing! πŸ™‚

  5. Pingback: klog » Blog Archive » hosting multiple sites from the same CMS engine

  6. We did this with our CMS a couple of years ago – it’s a great move. One thing to watch is that video content can’t be served through a script, it needs to be served statically from public_html.

    Also make sure that you have a good system for deploying database changes, it’s not much fun when you add new fields and forget to run the upgrade script on each database.

    But overall, this has saved us countless hours of grief keeping sites up to date.

  7. thanks for the notes, Harvey.

    There is a system in place for handling DB changes.
    All DB changes (and some simple file operations) are done through an upgrade script. Upgrades are run if the version number noted in the site’s config file don’t match the version number hard-coded into the site’s index.php. When a DB change is required, I first write the changes into the upgrade script, then change the version number in the index.php and the next time the site is visited the upgrade runs, changes the DB, and updates the version number in the config.

    It’s much easier to manage than changing the DBs individually!

Comments are closed.