In a separate post, I have complained about the shortcomings of the editors available for WordPress, Drupal and other content management systems.

The solution I have been using lately is BlogDesk. I have been using it for months to post on my blogs (I’m using it now). Lately I have extended its use for other projects such as my new allergy information website. That one uses Drupal, and has many types of content (blog, page, story, book …). Some of these need more configuration than BlogDesk can manage, so uploading from my desk top does not work for everything.

What does work well is to use BlogDesk to type text, embed images, format, add links etc. The built-in spell checker is pretty good to. Use only the Post section, not the More section. Add page breaks manually.

You can then view the HTML, where you can make further changes if necessary, such as adding floating DIV blocks etc.

When you are done editing, switch the view to HTML, then copy the entire post.

Disable the editor in the editor in your content management system. Paste the HTML into the body of your post body.

WARNING: Do not attempt to edit your post with a built-in editor at a later time if you use the above method to add additional HTML tags. The editor may remove or alter your carefully constructed HTML code. FCKeditor (for Drupal) seems to alter the HTML less than most.

I just disabled the built-in editor for WordPress. After trying several editors for Drupal, I’ve given up on them all. For now, I’ll stick to HTML, thanks.

I love the idea of WYSIWYG (what you see is what you get) editors, but I don’t like what any of these editors do to my posts.

I’ve had problems with TinyMCE, for example, I lost a lot of work when I tried to edit a link, and ended up jumping to the link instead.

Most on-line editors filter the HTML, which is just plain nasty if you are trying to embed elements in floating DIV statements for example (for an example, see this article on how to install TinyMCE in Drupal).

Although the idea of WYSIWYG is great, in practice the available options are wanting.

Typing HTML has problems as well. At first there is a lot to learn, but you get used to it. The problem is typos. Most of the links in my posts open a new window - it would be too easy to mistype “_blank” or leave out a quote somewhere.

The solution I have been using lately is BlogDesk. You can read more about extending the use of BlogDesk on a separate post.

Widgteditor is a simple replacement for a Drupal text area, with a WYSIWYG style editor.

It’s simplicity makes it interesting, and it is perfect for comments.

It has problems though, and for me it is a non-starter.

Firstly, there is no way (no easy way that I am aware of) for configuring where it appears. For example, I would like to be able to enable it for comments, but not for composing nodes (stories, pages etc.).

Secondly, I do not find it suitable for the article that I post. It is too simplistic. For example, when you want to insert a link, it provides for the link location only. There is no control over where the new URL will appear (same window, or new window for example).

As of this writing, it has a bug in Drupal 5, causing it to appear twice per text area.

If your needs are minimalist, and you don’t want to see any HTML, this editor may be the one for you. If you have slightly more demanding needs, consider TinyMCE or FCKeditor .

I am seriously frustrated with the TinyMCE editor, which I had installed on my allergy information site.

I came across a few short-comings, and I don’t think I can live with either of them.

Firstly, it messes up the HTML. I had painstakingly formatted some content, so that there was a list of items on one side, and a Google ad on the other. In order to prevent content above and below from wrapping around the arrangement, I needed to insert a couple of <DIV style=”clear: both;”></DIV> statements. TinyMCE stripped out both tags. I was kind of expecting that, so I did a preview before committing some other changes I had made. I didn’t save the changes due to the loss of the tags.

Much worse happened some time later. After spending quite a while on typing up some content, I clicked on a link in the content to edit the link. Instead of selecting the link, TinyMCE sent me to the link. When I pressed the back button, my changes were lost! That’s when I removed TinyMCE from my system. It won’t be coming back. I’d rather type out raw HTML then have that happen again!

A third shortcoming is that I can’t have a full-featured version of the editor for stories, and a stripped-down version for comments. This is likely the fault of how it is implemented in Drupal, than the editor itself. What I want though, is a way for visitors to do a little formatting of comments, and for me to do a lot of formatting of articles.

I will be investigating other editors when I have time. I will post again when I have had a chance to check out a few.

What editor do you use? If you want to share, do leave a comment!

Although everything is fully explained on the Drupal site, getting clean URLs to work can be tricky. Actually, it is more a matter of confusion. If you are not confused, you will have no trouble. If you are confused, you may be missing something.

The first thing to understand is the Run the clean URL test. When you click this link, Drupal attempts to go to [your domain]/admin/settings/clean-urls, for example www.allergy-details.com/admin/settings/clean-urls. If you get a 404, then your system has failed the test, and you have to configure it to work. If you end up at the Clean URLs configuration page, then all is well, and you can enable clean URLs.

There is no actual path to …/admin/settings/clean-urls, so if the test generates a 404, don’t go looking for this missing file!

Note: The following applies only to Apache servers.

What you need to do is fix .htaccess. This is part of the Drupal installation, but it can sometimes go missing. In my case, I used FileZilla to move the extracted Drupal files down a directory to where they belong, the .htaccess file got left behind (because it starts with a dot, FileZilla can’t see it).

There are two ways to fix this problem. One is to use your server’s control panel to move the .htaccess file to where it belongs (in the root directory of your Drupal installation). The other option is to edit the existing .htaccess file, remove all contents, and replace it with the correct contents. If you unzip the .htaccess file from the Drupal .zip on your PC, you can copy the contents from there. Or you can copy them from this post (if you are viewing this post from the front page of my website, or from an archive, you will have to click the “read more” link to see the .htaccess file contents from this post).

Continue reading

If you have tried the Quickfile e-commerce module for Drupal, you may have had frustrations trying to get the paths right to reach your digital download files.

The path to a digital download file comes in two parts. Part one is supplied by the Directory for quickfiles parameter under the Quickfile module Main settings tab. Part two of the file path is supplied by a specific quickfile node in the file path parameter.

When you configure Quickfile, the Directory for quickfiles is relative to the root directory of your Drupal installation. If you create a directory called “digital_downloads”, then the Directory for quickfiles parameter should contain “digital_downloads” without any slashes (either before or after the path name).

Assuming you have no sub directories in your digital_downloads file, the File path parameter for a particular quickfile node is just the name of the file to be downloaded when purchased. Do not include a slash in front of the file name.

Visit the quickfile module setup thread for more information and ideas.

It could have been a disaster. It very nearly was. Had I not done a full backup of my original Drupal installation of my allergy information website before attempting an upgrade to Drupal 5.0, it really would have been a disaster.

Assumptions

• Your website consists of a Drupal installation only, and has no subdomains. If your situation is different, use this procedure as a guide, but watch out for how you might effect the rest of the website, and act accordingly.
• Your Drupal installation uses the MySQL database.
• You have access to the back end of your website, and access to phpMyAdmin to administer your database.

Website Backup

Here is how I did the backup of the Drupal installation:

1. Put your Drupal website in maintenance mode. This will prevent changes to the content by users or visitors (e.g. adding comments) while you are doing the backup.
2. Using FileZilla (any other FTP client will do), copy all files under the home directory (usually public_html) to your personal computer. This ensures that you can revert to the original code and basic configuration (e.g. name and password of database etc.)
3. Back up the database. Good database backup instructions can be found on the Drupal site.
   In addition to the instructions on the Drupal site, I suggest you select the “Add DROP TABLE” option under Structure so that if you need to restore your database, you do not manually have to drop tables.

That’s it! You now have a full backup. I recommend you follow step 3 regularly so that you can always restore the content of your website should disaster strike. You should also copy the directory where you keep files (such as photos used in your posts) onto your personal computer.

Website Restore

Half way through my attempt at upgrading my Drupal-based website, I found that it was a failure, and that not only did I need to revert to the original code-base, I also had to restore the database.

I followed these steps:

1. Delete all files under public_html.
   Note: If your website consists of more than just a Drupal installation (for example, subdomains), you must be careful what you delete! Step 2 above should get you back where you started, but at this stage you really only want to delete the Drupal part of your website.
2. Upload the backup copy of your home directory to the server.
3. Using phpMyAdmin, drop all tables in the Drupal database. (This should not be necessary if you selected the “Add DROP TABLE” option when you did the database backup).
4. Select the Import tab in phpMyAdmin.
5. Import the database backup file.

Your Drupal website should now be in exactly the same state as it was when you did the backup.

You will be well advised to practice this procedure on a test server (e.g. on your personal computer) so that you know exactly what works and what doesn’t for your installation. One little mistake during the backup could make it impossible to restore your site!

There are so many content management systems to choose from, which one is best? I am a firm believer in open source, so I have limited my choice to open source systems. This still leaves a huge long list of CMS (content management systems) to choose from.

A while back I spent a lot of time checking out the options, and after some time, narrowed it down to WordPress or Drupal.

This article provides a little insight about each system, and provides my recommendation about how to choose between the two.

About Typo3

Along the way, I discovered Typo3 - a very powerful and interesting content management system. Typo3 looks like it can do just about anything, and looks extremely flexible. I spent quite a bit of time with it.

The problem with Typo3 is that it is very difficult to set up. The main problem are the templates - very powerful, but they are not based on any standard such as HTML or PHP etc. The developers have invented their own system, and you have to learn it from scratch. This is no trivial proposition, even for people who are good at this sort of thing and very tech-savvy.

Does Typo3 have place in the online world? It certainly does - it allows you do to do just about anything you could possibly imagine with a content management system. If there is a CMS out there with a feature, Typo3 probably has it too.

But this comes at a cost. As they say on the Typo3 website:

“… the flexibility and richness come with a price: complexity. If you’re not ready to spend a month learning the system and are in a hurry to satisfy a customer, you should probably look into getting somebody to help you or look for something else.”

Typo3 is well documented - probably better than any other open source content management system out there. They have a large pdf download library of Typo3 documentation which explains the system very well. The only problem is that you need to read almost all of it to understand the system.

About Drupal

Speaking of something else, Drupal is an excellent candidate. It is very capable, but only as complicated as you make it. The basic install is, well, pretty basic. Although you can do a pretty good website with it, you will almost certainly want to add modules to get it to do everything you want. They beauty of the Drupal system is that you only install what you need, so if you don’t need much, you end up with fairly simple system. Not really simple - if you want really simple and just a blog, WordPress is probably your best choice.

Drupal does take a while to set up, but as long as you are reasonably savvy with the basics of setting up web applications on a server, its not too bad. If you know any HTML and PHP, that will help you if you need to customize templates, but in many cases this will not be necessary. And if you decided to customize your templates and therefore need to learn (or learn more about) HTML and PHP, you will find this knowledge useful for other web projects.

Drupal is easy to get up and running, but takes some time to set up just the way you want. Chances are though, you will be able to get what you want using Drupal, without a huge time investment. And you can get started with something right away, then add modules and build features as you need them.

Drupal or Typo3

Unless you need a very specialized installation for a large organization, you are probably better with Drupal. Between the two, I recommend Typo3 only if Drupal does not meet your must-have requirements, or if you really like fiddling with esoteric systems. If you choose Typo3, you will certainly have a great site, as long as you put in the long hours and hard work to learn it properly.

Information About Content Management Systems

A good place to research content management systems is the CMS Matrix. It consists of a very long list of content management systems, popular and obscure, free and paid. It lists the features of each, and allows you to do a feature-by-feature comparison between several systems that you select.

Related Article - WordPress vs. Drupal

All of my fully operational websites use WordPress, and I am in the process of setting up some websites using Drupal.

Update! I now have two fully operational Drupal sites: an allergy information website, and my own SEO Service and Technical Writing Service website. The content is not complete, and the allergy site will have more modules added. Both sites work very well.

You can read my comparison of Drupal and WordPress.

I have installed TinyMCE for Drupal several times now, and every time I do it, I get messed up! Although the instructions are complete, somehow they are not really clear. So if you have tried installing TinyMCE in your Drupal installation and you are having problems, read on. You may be making the same mistakes that I have been making, in which case this article will help you.

The first thing to understand is that you must download two separate zip files.

First, there is the TinyMCE Drupal module. In your Drupal installation, place the zip file at [root]/sites/all/modules/. Extract the zip file, which will add the tinymce sub-directory, in which you will find the includes and themes sub-directories.

Second, there is the TinyMCE package itself. Download it, and place it in the newly created [root]/sites/all/modules/includes directory. Extract the zip file, which will create a new tinymce sub-directory, with three sub-directories under that: docs, examples, and jscripts. These three directories must be moved up one level, so that you now have the following three paths:
[root]/sites/all/modules/includes/docs
[root]/sites/all/modules/includes/examples
[root]/sites/all/modules/includes/jscripts

You can now delete the [root]/sites/all/modules/includes/tinymce directory.

The files for TinyMCE are now installed. Enable the module on the Administer>>Modules page (Administer>>Site Building>>Modules for Drupal 5 installations). To control some finer points of what fields can use the editor, go to Administer>>TinyMCE page (Administer>>Site Configuration>>TinyMCE for Drupal 5 installations).

This should give you a fully functional WYSIWIG editor for your Drupal installation. Remember to configure access based on roles, as required, so that the editor appears (or not) for anonymous and authenticated users.

Instructions for adjusting the IMCE module are included with the Drupal TinyMCE module pack. IMCE is a separate plugin.