Wednesday, December 30, 2009

Real Application Alternatives

I read an article this morning indicating that Microsoft is taking the threat posed by OpenOffice seriously. I see this as wise on their part...for a company that has a history of being late to take some things seriously, most notably, this new fangled internet thing, which back in the 90's it they staggered and wimpered to make any serious effort with their web browser, which I suspect is only surviving today because it's part of the Windows OS. Later on they mocked and poked fun at Linux, which now has a huge foothold in the server market and small device and appliance markets.

Many of these "app killer" apps still have serious limitations that prevent any real traction. Thunderbird is a great email client, but has long lacked some of the features that Outlook has like appointment calendars, for example. Gimp is a very cool graphics application, and very powerful and completely free. It does, however, suffer from usability issues that conflict with it's peers like Photoshop, which is frustrating, and doesn't fully support importing Photoshop files, though pretty good, it does miss some random effects and other things when importing at times.

OpenOffice on the other hand, seems to be a very legitimate alternative to MS Office users. I use OpenOffice and have very few issues when working with clients that have standard office docs (without the "x" on the extension), and any I have had have been cured by sharing as open document format files. They looks and work pretty darn close to Office (pre Office 2007) so flipping between the two is easier as well.

It seems to me one of the more difficult aspects getting big business away from MS Office is the fact so many of them pay a huge licensing fee every year for access to a huge product line. SO switching to OpenOffice would save them little or nothing in these large license packages and add to that the complexity of yet another application to support for IT staff and training.

In the case of OpenOffice, they are not taking over, not because lack of features or usability, but, more because of simplicity and Microsoft large hold on business via bulk licensing fees.

If you are a small business or at home office, try OpenOffice, it's a very real alternative to MS Office, and free!

Tuesday, December 22, 2009

Migrating Drupal Installs

I am sure it comes as little surprise from the direction of my posts lately that I have been up to my nose in Drupal management and development. With that I have found some tweaks and quirks of the system I am trying to document, partly for my own good later on for reference, and partly for anyone else that has the problem and may find this blog.

Most recently I have developed a Drupal based site for a client on my multisite install, and, after development, had to move it to another server.

This presents issues of file and folder permissions and ownership, and most any shared hosting has no ability to run a CHOWN (change owner) functions on files or folders, though most allow CHMOD (change mode).

When Drupal is installed, the user sets the domain folder to a 0777 CHMOD and, during install, it creates a few subfolders for file uploads, theme settings and images and any other user storage needs. When it creates these folders it is owned by "apache" (or whatever the web server is) and CHMOD of 0775, which allows the server to read and right to and from those folders with no problems. However, when the web site is moved to a new server, if you download the existing site, and upload it all to a new server, all folders are owned by the user and typically has default permissions of 0755, and files of 0644.

To work around this, typically setting all those same files and folders to 0777 and leaving the ownership as user owned is a valid and workable tactic. But there are some cases where it does not. I recently learned that in one case, the module xmlSiteMap, the site map is not retrievable with those permissions.

Should you encounter such errors with xmlSiteMap, or any other file creating module or the core of Drupal, what I have found the quickest and easiest way to get around the problems is simply to delete the directory altogether, and go back to the module or theme and rebuild it by rerunning the configuration of said module or theme. Doing so will rebuild the necessary directories and files with proper permissions on each.