about fixing the RSS feeds problem with iWeb using Apache RewriteRules. Here is an update for those using a web hosting environment where they do not have godly power over the Apache configuration files. I’ve recently transitioned to the former situation from the latter and I’ve had to adapt my strategy for dealing with this little bug a bit.

Side rant: WTF Apple? This RSS feed publishing bug is well known and well complained about and from a programming point of view is trivial to fix. People bitch about it in the forums, and it’s wrong, even though some of the forum dwelling sockpuppets keep saying that it’s perfectly alright to have to upload your site twice to make up for the broken links produced by otherwise nicely functioning software. So look, either your hosting service is broken or your software is broken. Just fix it.

Rant off.

So anyways, won’t work in an .htaccess file driven hosting environment. It has to do with the URI-to-filename translation handler phase of the Apache request chain. In my last commentary I suggested a RewriteRule (henceforth: RR) that looked like this:

RewriteRule ^/Example/(.*) /$1 [R,L]

To remove the spurious “Example” (or whatever you named your site in iWeb) string from the URLs in the RSS feeds, and the links pointing to the RSS feeds. If you put that in the server configuration file that’s fine. The RR short-circuits the URI mapping phase and will happily redirect things from the URI-segment “Example” even though it does not exist (because iWeb does not create it, which is the whole reason for this little exercise). However, when including these directives in .htaccess files, this approach will not work because the URI-to-filename translation handler has already started and when it does not find the directory “Example” in your document root, it fails out.

There is a solution however. How it is executed depends on how you push out files to your hosting environment. What need to happen is that one needs to create a directory at their DocumentRoot called “Example” and place an .htaccess files in this empty directory with the following directives:

Options +FollowSymLinks
RewriteEngine On
RewriteRule ^(.*) /$1 [R,L]

Using this approach the same thing will happen. Apache will find the bogus directory from the buggy URL and then the RewriteEngine will then take over and translate your paths such that they resolve properly.

It should be noted that while it might be tempting to just create this directory and .htaccess file on your local disc in your ~/Sites/sitename directory, there is a problem with that. Every time you publish your site, it will get over written by iWeb. So it has to be placed on your web host machine some other way. I just wrote a bit of shell script to create the directory and .htaccess file .

But really, iWeb should just be fixed so this is irrelevant.

I’m currently looking at RapidWeaver. This is becoming foolish.

Seems like most of the “external” hits to my blog are being generated by Google searches hitting my second blog entry. In the aforementioned entry, that arises when using iWeb to “publish to a folder” when you don’t wish to host your site on the Mac hosting service. So, since people seem to be finding this blog by Google searches like “using iWeb with Apache” I thought I would toss out another thing I do when using iWeb to publish to other hosting platforms.

If you’re using iWeb you’re obviously using some flavor of OS X which means you have a UNIX shell utility on your system called rsync. It’s a file transfer utility that is far more flexible and interesting than FTP, and since you can do it over SSH, you have more options when transferring your files to some sort of shell-based hosting environment since many places allow SSH use since it’s far more secure than things like FTP. Moreover, rsync is smart enough to figure out which files have changed since you last used it so it will only transfer the new files rather than: 1) having to copy over your entire site every time; or 2) figure out what the new files are and copy them manually. Finally, if you remove pages locally, it will remove them from the remote server as well. This does involve using the terminal program. so if that freaks you out, then I can’t help you – but I will address how you can streamline the process somewhat.

The basic command you want to issue (from the terminal) will look something like this:

rsync -vrca –delete –rsh=ssh /Users/username/Sites/sitename/ username@www.example.com:/www/docroot

The first file path is the pathname to where iWeb stores your published site when you publish it to a folder. The default place is in the “Sites” subdirectory of your home directory and the “sitename” defaults to what you named your site at the top level. Note the trailing ‘/’ on the path name – it tells rsync to push out the entire contents of that folder. The hostname “www.example.com” should be replaced with the name of the machine your site is hosted on and the “username@” is your username on that machine. Finally, the path after the ‘:’ (no spaces between hostname and that) is the document root of where your website files go on the hosting server. Note the lack of a trailing slash on that.

If you run that command, it will take all your “publish(ed) to a folder” iWeb files and transfer them to the proper spot after prompting you for your passphrase. And when you update your site, it will only push out the new files, or ones that have been changed rather than transferring everything. And entries/files/images that have been deleted, will also be removed at the remote end. Play with this until it’s putting the files from the right place, to the right place (will involve tweeking your file paths to taste).

For the non-UNIX-savvy, here is an easy way to automate this process rather than having to deal with this rather cumbersome command (requires administrative access on your Mac):

1) Edit the file /etc/bashrc to include the following line: source ~/.bashrc (admin access needed).
2) In the root of your home directory create a file called .bashrc if it does not already exist (note leading ‘.’ character) and add the following line to it:

alias publish=”your long tailor-made rsync command” (quotation marks included)

3) If you want to execute the command immediately, execute the command: source .bashrc (optional).

Now, all you need to do whenever you are ready to push out new changes to your iWeb publish(ed) to a folder website, just open the terminal program and type publish (or whatever you named the alias). There are probably other Mac-oriented ways to alias this command, but this is the UNIX way and that’s all I know.

Cheers.

OK, so when using the iWeb “Publish To Folder” (ie: not to mac.com) option it does not get the RSS feed urls right. The on-page links to the RSS feeds will be munged up and the pointers that the RSS feed gives will be munged up as well. Charming. A known fact. Thanks Apple! But, if you happen to be hosting your iWeb produced website on an Apache webserver that you have control (or influence) over, there is a pretty easy fix to this little issue. Our friend mod_rewrite will take care of things.

If you have named your top level site name “Example” and are publishing to the url “www.example.com”, all the links will work – mostly. Your sub-page named “Blog” will be reachable at:

http://www.example.com/Blog/ (as it should be)

however even if you tell the “Publish To Folder” dialog (as you are supposed to) that your site is:

http://www.example.com/

iWeb will try to force your RSS URL to (as it should not be):

http://www.example.com/Example/Blog/rss.xml

as well as making incorrect links in RSS feed itself.

If you can get all up in the Apache config, the following directives will take care of the problem once and for all (where “Example” == the name of your top-level site name):

RewriteEngine On
RewriteRule ^/Example/(.*) /$1 [R,L]

iWeb in certain circumstances is putting the name of the top level site page into the URL as it should not be doing. This simple rewrite rule will take care of this particular mistake.

Caveat: this will now work if you have a sub-page with the same name as your “top-level” page name.

From experience, I know that hand-coded/programmer-generated html is better than that which tools like this can produce, but this is really egregious. Of course, the problem does not surface if you are “publishing” to mac.com, but I thought that Apple prided itself on not acting like Microsoft.