Published: September 12, 2010
The simple answer is that WebsiteBaker doesn’t use URL rewriting (Apache mod_rewrite, or Zeus rewrites). Therefore, to keep content well organized it’s stored in the ‘pages’ directory, which can be renamed if you want. Request rewriting does add more complexity to a site, so I think this decision is generally a good one considering WebsiteBaker’s target audience.
It’s really about personal preference. Having /pages in the url is unlikely to have a bad effect on SEO. I just like clean URLs, which is likely also true of some of my site visitors.
My goals, in order of importance, are:
Now let’s look at the available options and see how they measure up.
Since /pages is in the URL because the pages files are stored there, it seems logical to just store pages directly in the WB root folder. Before creating any pages log into the Admin section. Open the Settings tab, click Show Advanced Options, and blank out the Pages Directory field. Sounds simple enough, but as some threads on the WB forums have discovered (this one and this one), it doesn’t always work, and if you’ve already created pages you’ll need to edit the files on your web server. But for me, the main reason for rejecting this option is that it fails on goal #2, thus creating too much file clutter. What else can we try?
We know that WB creates links based on what’s entered in the Pages Directory field. So what would happen if we left it blank and then told the server (via Apache rewrites) to look for pages under /pages/?
RewriteEngine On
# we'll only apply this rewrite rule to files that can't be located.
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ /pages/$1 [L]
That seems quite simple, and seems to work, until you start to create pages. Then, because Pages Directory is blank, new pages are stored in the root directory, and everything falls apart. There are other problems with this method, but we’ll come to those later.
Now we know that Pages Directory must be set to the directory where your pages will be stored, so we’ll set it back to /pages. This means that in addition to needing to use rewrites to tell the server to look for pages under /pages/, we also need to make sure WB only gives out URLs without /pages/ in them. It makes sense to first look to the code that creates menus. If you’re still using show_menu() in your template I would recommend switching to show_menu2, it’s far better and is installed by default with WB. How does show_menu2 create links for menus? It does it the right way, and use the _pagelink() function in the wb class.
Looking at the _pagelink() function (line 161 of /framework/class.wb.php) we find that it creates links using the PAGES_DIRECTORY constant. So we duplicate that line, comment out the old one, and remove PAGES_DIRECTORY from the new one. Problem solved? Not quite. This change together with the rewrite above will work for wysiwyg and code sections, as well as menus. But other module sections may or may not correctly remove /pages/. The reason is that some modules wrongly use PAGES_DIRECTORY rather than _$wb->pagelink(). Others use $_SERVER[‘PHP_SELF’], which includes /pages/.
So what’s the ultimate solution. WB core code should include a new constant PAGES_URL that can be set in the same way as PAGES_DIRECTORY. Then core code and modules can be improved to use PAGES_URL wherever _$wb->pagelink() can’t be used. And with a small modification to $wb->page_link(), it can be used to replace $_SERVER[‘PHP_SELF’].
But in the meantime the next article shows some changes you can make to get this solution working.
WebsiteBaker - Removing /pages/ from the URL - The Code
Update: Because the URL rewrites rely on the file/directory not existing, if a user creates a page that is the same name as an existing directory/file, e.g. config, admin, etc. the page will not be ‘viewable’. (Thanks to Ruud on the WebsiteBaker forums)
Maybe this WB forum thread is interesting for you too :-)
http://www.websitebaker2.org/forum/index.php/topic,4715.msg29120.html#msg29120
Posted by cws on 29 Sep 2010