Archive for category WordPress

Solving the WordPress IIS 500 Error for Image Display

For quite some time we had an issue where on an IIS server there was a WordPress 500 server error anytime we use the media Library to upload images. We set the permissions on the parent directory of the uploads folder but this would not resolve the issue.

It took a long time to figure out the issue and finally I found these posts that provided the immediate solutio – set the PHP/Windows temp directory to be accessible by the IUSR account.  Instant fix.  Thank you to all those who have provided the solution.

Now the request to the WordPress development team – include this in the notes or setup for Windows installations.

 

 

No Comments

Drupal vs. WordPress

Let me start with a note on my bias – I love WordPress. This said, I have tried not to let it color this post that attempts to highlight when and where to choose between WordPress and Drupal. No matter, I look forward to some solid comments from all sides on these ramblings.

This evaluation really comes down to a definition of the task you desire. I have found that WordPress is the ideal selection for any blog. I have also found it to be an excellent choice for a small to medium Web site. Why? In two words, elegant simplicity.

On the setup side, WordPress is so simply to install, create themes, add enhancements that it is easy to get an excellent site up and running in a very short time. Then on the administration side, the user experience is an excellent one for those who are not familiar with technology. I have been able to bring luddites up to speed in WordPress post, page and comment management in mere minutes.

Drupal I have found to be more suitable to larger Web sites that require a greater level of development for custom applications, multiple themes, multiple languages and other aspects you would expect of a full bore content management system. For a blog or small Web site I find it to be overkill and adds a level of complication that adds too great an expense to sites that so not require custom applications.

This difference is apparent in the extensions to WordPress and Drupal. Drupal features a large set of modules to extend features. WordPress appears to offer many more. The difference comes not just in volume, but types. Drupal has a set that is clearly more technical in nature than WordPress. Also, a good number of the modules are seen as jumping off points for custom development. This is far different from the WordPress plug-ins that are targeted to the Web site maintainer who has little if any programming knowledge.

And this comes to the real difference I see with these two platforms. Drupal is clearly targeted first and foremost to code lovers and developers. This is readily apparent in the language used on the Drupal site, its blog postings and in general. Development discussions on the site are highly technical and constantly refer to a mix of PHO, JavaScript and JQuery as minimal requirements for Drupal development.

WordPress on the other hand has a greater balance between the average Joe that wants to have a blog/site and the developer. Surfing to wordpress.org you find that this is tailored much more to the layman than Drupal.org. WordPress also has a broad commercial path to get started via wordpress.com. Then when you do dive into development, you find that with minimal PHP skills you can customize and modify themes.

I find that this separate target of hard core a developer (Drupal) to the general population (WordPress) is clearly evident in area of theme management. In Drupal, the themes are all managed external to the Drupal interface. You compile and create the various layouts on the backend (as you do in WordPress) and then must manage these from the back end. In WordPress, you have access to theme templates form within the interface for modifications. This distinction is key. There are two levels of expectations here. In Drupal there is the expectations that the framework will usually require far more coding and management than should be permitted via the interface. WordPress on the other hand considers the possibility of editing templates to be something that should be permitted to the administrations right from its graphical shell.

Again, this comes back to suitability of task. I would not want a large scale site with numerous complex templates to be accessible by any old administrator – hence Drupal. However, if I have a small site where the admin, maintainer and developer are likely the same person and the theme is straight forward then the interface access is reasonable.

Here are some other side-by-side comparison.

Editing Interface

I hate the Drupal editing interface. The listing of pages without any management options means it takes me a long time to find and then adjust content. The content listing and editing options in WordPress are simply far more elegant than anything offered in the Drupal core or via any add on modules I have found. For this interface reason along I prefer WordPress.

Comments

WordPress has focused for years on its comment moderation capabilities. They are top notch. Drupal’s are rudimentary at best. Having now used both, I would have to eliminate Drupal as a blogging option for a site that expected high comment volume. Drupal is a fine technical solution. Drupal is simply not up to the task when it comes to the associated workflow.

Simplicity of Free Themes and Theme Design

WordPress and Drupal take a few minutes to install. Getting started with adding a free theme for WordPress takes a few minutes to find tens of thousands of items to get started. Drupal then takes quite a bit to customize even free themes. This difference real comes to the forefront with my experimentations. I can transfer an existing site with drop down menus and a couple of area designs to WordPress in half a day. The same effort took me (and an experienced Drupal developer) a week.

Media Library

WordPress offers a simple but elegant media library. And a couple of plug-ins really push it to an even better solution. Drupal’s media management is barebones. Media is considered a node or content element just like any other item such as a page or post. This is excellent when you want to develop a larger application on top of the framework. However, it falls short for a simple site.

Plug-Ins

WordPress offers not just one plug-in for everything imaginable – there must be three or four. The modules that extend Drupal are simply not as varied and there are less options for each task. More to the point, adding, testing and tweaking just seems to be so much faster and easier in WordPress than the developer focused interface offered via Drupal.

Here are some other articles for thought

, ,

33 Comments

TypePad versus WordPress.com

First, I love WordPress.  I run my blog using WordPress on my server and have found it trouble free with a helpful community and unlimited possibilities via the available themes and plug-ins.

However, for those cases an ASP managed service is called upon, I do not find the paid services of WordPress.com (or other WordPress MU based services) to be up to snuff. The lack of the ability to edit the theme files lead me to require an alternate solution.  Sure, WordPress.com allows for CSS editing that may be applied to the available templates.  However, this is simply insufficient to create the robust solutions I find my clients need. 

This lack of template editing in WordPress.com leads me to recommend the services from TypePad.  TypePad provides unfettered access to create, modify or add template files as well as any number of CSS files.  This has enabled us to do things like switch out the comments engine or add forms via third-party solutions. 

P.S.: If installing your own blog software or in need of a simple CMS for your own server I still recommend WordPress. 

Agree, disagree? 

1 Comment

WordPress Server Migration Process

I have found that I am moving a fair number of WordPress sites around to different servers. The following is an outline of the steps I have found useful that can reduce the complexity (and cost) of these migrations.

Yes, I know that a bunch of these steps couple be eliminated with simply copying and moving databases around. That is great if you are very familiar with db managed and related tweaks. This is more of a dummies guide to the transfer. Please though do comment and let me know your thoughts and best practices you have found for such migrations.

Option 1: Database familiarity required

  1. Setup up a Web server with mySQL and Apache. If a hosting recommendation is required then I recommend WestHost that can provide this service for less than $35.00 per month.
  2. Setup a mySQL database to match the database name, ID and password in use by the currently active WordPress installation. This is found by looking in the active site’s wp-config.php file.
  3. Install the version of WordPress currently in use for the active site. To simplify matters, copy the wp-config.php file from the active site for use on the new site. It is not uncommon for the site to be operating under old versions of the software. Archived versions are available for download at http://wordpress.org/download/release-archive/.
  4. Back up the database. The easiest way to do this is to install the WP-DB-Backup plug-in. After this five minute install an admin can then create and save this backup of ALL tables.
  5. ZIP the database backup and use phpMyAdmin to restore the database to the new server. Instructions may be found here on http://codex.wordpress.org/Restoring_Your_Database_From_Backup
  6. ZIP the entire active site. This is then uploaded to the new site to replace the default WP files used during the install. (Some folks have said to skip the initial install of WordPress and rely on the database and file transfer for the install. If this works for you – great. I like the initial setup first to confirm that the dB is setup and the software works properly. This helps identify other issues such as the server itself not being configured properly for WordPress. Sure, this is wiping out the initial install. But the confirmation of the WordPress compatibility with the server is nice.)
  7. The site will then by default be set to function at the live site domain. The site needs to be checked before the domain name is transferred. Either set the internal DNS for the server and computer connection to the new server or enter the dB and change the values to one that will work to check the site.
  8. Review the site and check for any errors. The only error I have ever run across is that occasionally the path information to the files on the server need to be adjusted in the dB. This is a very quick task for someone familiar with myPHPAdmin.
  9. Switch over the DNS to direct traffic to the new server.
  10. Adjust the new servers Apache configuration to direct the domain traffic to the WordPress directory. This is usually done via a control panel.
  11. Adjust the WordPress settings to serve up the site under the new domain. This is done within WordPress’ main settings page.
  12. Check site, Feedburner and Google Analytics and other external hooks.
  13. Once comfortable with the new site, the old site may be decommissioned.

Option 2: In this option the client does not have to mess with the database items at all. I have found that this works well with sites that do not have too many posts.

  1. Setup up a Web server with mySQL and Apache. If a hosting recommendation is required then I recommend WestHost that can provide this service for less than $35.00 per month.
  2. Setup a mySQL database to match the database name, ID and password in use by the currently active WordPress installation. This is found by looking in the active site’s wp-config.php file.
  3. Install the version of WordPress currently in use for the active site. To simplify matters, copy the wp-config.php file from the active site for use on the new site. It is not uncommon for the site to be operating under old versions of the software. Archived versions are available for download at http://wordpress.org/download/release-archive/.
  4. Set up the links (blogroll) items on the new site.
  5. Zip the entire content of the entire active site. This is then uploaded to the new site to replace the default WP files used during the install.
  6. Export all content using the built-in export utility and deliver the XML export file to the client. This should end the use of the old server.
  7. Uses the built-in import function to import the provided XML file. They select to create author accounts as prompted by the import.
  8. Adjust user accounts as needed.
  9. Review the site and resolves any errors.
  10. Switch over the DNS to direct traffic to the new server.
  11. Adjust the new servers Apache configuration to direct the domain traffic to the WordPress directory. This is usually done via a control panel.
  12. Adjust the WordPress settings to serve up the site under the new domain. This is done within WordPress’ main settings page.
  13. Check site, Feedburner and Google Analytics and other external hooks.
  14. Once comfortable with the new site, the old site may be decommissioned.

,

No Comments