The May issue of Communications of the ACM contained a very interesting article called “Why Cloud Computing Will Never Be Freeâ€. It sometimes reads like an ad for the service that the author’s company offers, but it’s still an in-depth presentation of why the cloud computing price war has resulted in services that cut corners. Buyers beware!
If you’ve tried running WordPress on Bluehost, you may have run into this: you change your Permalink Settings, and the site no longer works. You get “403 Permission Denied”.
The fix is pretty simple. Just edit the .htaccess file in the blog’s root directory and add the line Options +FollowSymlinks. I put it after <IfModule mod_rewrite.c> because that was suggested by the article that I found on the interwebs.
I don’t know why I’ve only had to do this with Bluehost, but their tech support told me that they don’t have any plans to fix whatever the underlying issue is.
I was trying to use Akeeba Backup (formerly “JoomlaPack”) to move a Joomla site from a temporary location under my personal site to its own hosting account. The site packed up fine, but I got the error “Could not open logs/index.html for writing” when unpacking with kickstart.php.
A little research revealed that you sometimes get this error when unpacking to a hosting account’s root folder. You can get past this by unpacking to a subdirectory and then moving the files to the root. It looks to me like my host, 1and1, wasn’t allowing the kickstart scripts to write to the logs folder. I couldn’t figure out how to fix the permissions, so I used the subdirectory workaround. After unpacking everything to a subfolder and then moving it to the root, I just needed to change two paths in configuration.php and the site was working. I never was able to move logs/index.html to the main logs folder, but the site is working fine without it.
I did need to follow one important tip in the Akeeba Backup manual and force “binary mode” when transferring the site’s .jpa archive file down from the original host and up to the new site.
When our users started upgrading to Firefox 3.0.10, they began noticing that our Dotnetnuke intranet’s menu bar was broken — only “Home” showed up, not the rest of the page titles.
It turns out that DNN uses a config file to tell it what capabilities the various browser versions support. For some reason, the user agent string from Firefox 3.0.10 isn’t recognized.
I empathize with the arguments on the DNN forums that it’s not a good practice to maintain a table like this, but I’m not going to try to rewrite DNN. Since I’m not worried about really old versions of Firefox accessing our Intranet site, my fix was to edit the file \js\ClientAPICaps.config and add this to the first section:
browser contains="Firefox"