Is there someone with experience with Drupal, Joomla/Mambo and WordPress who can tell what the differences are? What are the strong and weak points?

For better or worse, I am that person. So here's my summary of the advantages and disadvantages of each of the above CMS platforms.

Drupal

Advantages

• Very clean core code.
• Good project leadership from Acquia.
• Some very good developers available for hire.
• Fewer clowns available for hire (you can either code Drupal or you can't, it's harder to fake it).
• Can be made very server efficient in the right hands (scaleable).

Disadvantages

• Less ready made drop-in plugins. You're going to  have to get your hands dirty almost every time.
• More imposing default user interface.
• Fewer developers.
• More expensive developers.

Joomla/Mambo

Advantages

• Good menu system.
• Strong static page structure (cf. weblog).
• Built-in membership/community features.
• Long time on the market.
• I'm searching here.

Disadvantages

• Built-in performance pretty sluggish/clunky.
• Horrid built-in URLs.
• Weak weblog section.
• Hard to theme. A Mambo/Joomla site looks like Mambo/Joomla, like it or not.
• Crappy built-in SEO. Leading SEO plugin belongs to a very peculiar developer and is encrypted (have fun repairing the SEO plugin, we reverse engineered and decrypted it for our site to make our changes even after paying for it).
• Nasty, nasty core code. Very difficult to fix broken items.
• Fractured community (never healed after Joomla/Mambo split back in 2006).
• Most good plugins are pay.
• Rather mediocre developers. Anyone who likes to code in Joomla/Mambo in 2011 ought to see a psychiatrist.
• Developer pricing is all over the map as there are many old-school Mambo/Joomla developers still ought there churning out convoluted future-resistant code quite affordably.

WordPress

Advantages

• Huge community.
• Easy to optimise for performance thanks to Donncha O Caoimh and Frederick Townes. Great work guys.
• Easy to theme in a unique way. A WordPress site does not have to look like a WordPress site.
• Great plugin architecture.
• Plugins for everything.
• Lots of great professional developers.
• Fast development cycle. Improvements every year.
• Active leadership from Automattic and founding team. Particular thanks to Mark Jaquith for keeping the community running with less nepotism and more fairness than most collective human endeavour.

Disadvantages

• Fairly weak core code (in comparison to Drupal, but not Joomla!) but core getting better every year.
• Lots of really crap faker developers in the pool who couldn't build a working website to save their mother's life.
• Lots of popular but seriously broken plugins which will cripple your website performance forever and make it nearly impossible for you to cleanly upgrade (NextGen Gallery, I'm looking at you but not just you).
• Really crappy commercial themes which are heavily marketed but compromise your ability to either upgrade or switch themes and compromise performance for the life of your site.
• Weak static page management without adding plugins. Easily fixed with said plugins.
• Too fast an upgrade cycle. You have to keep upgrading your site, whether you like it or not, for security reasons. There are no security releases only new versions. Feel the pain for a commercial site with running a full complement of plugins. Corollary: choose your plugins and plugin developers very, very carefully for cleanliness of code and frequency of update.

Conclusion

For a very large commercial project, I can see a justification for choosing Drupal. On a big project, most of your expense will be custom development anyway - everything has to be optimised and integrated - so you don't much care one way or another about a myriad of plugins which you will probably not use. I still wouldn't make that trade-off: slightly better core code for a vast pool of community contributed code. But it's a defensible position.

Joomla/Mambo should die a violent death. We did our first CMS project in Mambo and last year redeveloped a couple of existing sites in Joomla. Our best developers - very platform agnostic - threatened to quit if I accepted anymore Joomla work. Such crappy, convoluted spaghetti code they'd never seen. And these developers have had ample chance to see the worst side of WordPress.

The only justification for a site in Joomla/Mambo is that it's legacy (i.e. you already did a lot of custom development on it six years ago and don't have the budget to migrate) or that you are part of an international network standardised on Joomla/Mambo and the mothership discourages anyone from leaving the central platform (our client's situation). For everyone else, just migrate out and count your blessing that you got your site out alive. Enjoy the fresh air and clean code of WordPress (or Drupal).

WordPress is the platform of choice in my opinion for the small, medium or large business. Whatever holes you can find in WordPress (editorial management process, page management, ecommerce, membership site) are easily solved with high quality plugins.

The cool part about WordPress is that the core is kept clean so that you aren't forced to load code you don't need if you want a simple weblog. Thus WordPress can be a weblog, a corporate information site, a membership site, a store or an international news network.

We regularly develop advanced real estate sites in WordPress, maintain a very sophisticated insurance site, have developed elaborate furniture rental systems and develop the most delicious cooking sites as well as gorgeous online literary reviews. Not to mention political, news and law sites. All in WordPress.

The danger with WordPress include the overhyped commercial themes which don't solve your problems but pretend to (I'm looking at you DIYthemes.com and Thesis, WooThemes and ElegantThemes). A related danger are the weak developers and hangers on who have infested the huge WordPress community and enthusiastically give bad advice, whether about SEO or gallery plugins. These clowns will happily break your website for pay or into a defective by design commercial theme. Forewarned is forearmed.

Just like any other serious professional endeavour you need steady hands on deck when you want to take your site to the next level if you want to maintain performance, appearance and compatibility. Once you have substantial traffic or need ecommerce, WordPress is no longer a DIY venture for the non-programmer.

We personally recommend people start a new site on WordPress.com unless they are developing for an established business. Once you have an audience or a functioning business, self-hosted WordPress is the way to go. Even the sky is not a limit. There are few sites we could not develop better and faster in WordPress.

By Alec

Drupal vs Joomla vs WordPress: Developer’s Perspective

Post from: Foliovision

You might also like

1. Mambo / Joomla
2. Mambo Embedded Page Menus
3. Foliovision Tools

SEO Image managing a large sub directory of images uploaded via FTP

Uploading images one by one through an image editor is fine, uploading twenty that way is annoying. One of the reasons to prefer WordPress over Typepad is that you do have direct access to the server via ftp. So this was clearly not acceptable. It wasn't even possible to change the file ownership of httpd via SSH (without root permissions).

Back in SEO Images we tried to move the images, but there was a problem. Images could not be moved or deleted, even renamed. Researching more this issue we found out a problem with users and their permissions. Images uploaded by FTP belong to user fv, but PHP runs as user httpd.

So the issue is that FTP and PHP runs under different user, but these users cannot touch each other files, except reading it. We tried to set the folder owner to fv and group httpd, but newly uploaded files were still locked to PHP.

After much deliberation we came up with several potential solutions.

1. One possible way would be to create some nice HTTP uploader with progress bar, where you'll be able to upload more files. Since you cannot do it in PHP, there is an option to use flash uploader. BUT BE VERY CAREFUL, since flash uses different session than your browser, so even if your form is secure, the flash upload will not be. So if you chose flash, chose your flash uploader carefully. Security is always priority number one.
2. Other option is to use FTP inside PHP. So the PHP will FTP into the folder and change the permissions when there is a file (or directory) that doesn't belong to PHP script user. This will solve the issue, but in order to for PHP login to FTP, you have store the login information somewhere on the server. This again is a security risk. You can of course enhance the security by encrypting the login information, and change the pass-phrase for encryption every couple of hours, but for this to be really secure, you have to use second computer (possibly non-public) to generate the pass-phrase. So this solution turns out to be not really practical.
3. Since this is all a permissions issue, it can all be dealt with by changing the permissions for uploaded image files to 766 and images directories to 777. This may be very dangerous, especially on cheap shared hosting who often have mod_security turned off and who do not protect the directories between clients.
   
   But changing permission turns out to be the easiest solution and probably safest solution (safer than storing ftp login info on your server!). When your server security is high and, like us, you only need this to upload images, maybe this is what you want. If you are working with an httpd file manager but would like to be able to use FTP with it, just set the permissions of uploaded files via HTTP and also FTP to 766 and folders to 777 and you're good to go.

In our particular case we actually had to change a bit of code to change permmissions of newly created directories in KFM to allow the FTP manager to work on the uploaded images.

@chmod( $physical_address, octdec( '0'. $kfm_default_directory_permission ) );

wien docks crane

The great thing about this fix, is that our image manager is now totally compatible with FTP, so uploading and managing hundreds of images is no longer a concern. Together with Lightbox, SEO Images effectively becomes full scale gallery software and not just for a few images per post. Here is an example gallery of images of Vienna's industrial south.

By Peter

How to get HTTPD and FTP to play well together or SEO image management nirvana

Post from: Foliovision

You might also like

1. How to prepare FTP uploaded images to work with SEO Images in Filezilla
2. Foliopress WYSIWYG Image Management now works in Safari
3. FV Testimonials: Management Guide

That figure should be enough to strike terror into any developer. But that number will change very soon as PHP4 has hit the end of the line.

PHP4 incompatibility started off not as a deliberate decision. Generally I like wider compatibility.

But on serious consideration, I'm not worried about Foliopress WYSIWYG being PHP5 only.

Why not?

• Our own webhost no longer supports PHP4 (they will put up with it on legacy projects, but strongly discourage it).

• 
  One click image posting from Foliopress WYSIWYG
  via updated KFM right click: this image and caption
  were posted with a single click

  One of the core components in Foliopress WYSIWYG is Kae Verens's brilliant KFM (Kae's File Manager) which we have turned into an advanced image manager (see illustration right). Kae is no longer supporting PHP4 in future development: "PHP4 is a hindrance. My own project has already announced a similar plan - we will no longer be catering to PHP4 after the present release."
• PHP5 has been available for 3 years now and is thoroughly tested and is at version 5.2.5
• PHP5 has a lot of improved functionality over PHP4.
• PHP4 will start to disappear like dry brush this year. In six months there will no longer be PHP4 legacy issues as anybody keeping their online applications up to date will have moved on to PHP5 for one reason or another.
• Foliopress WYSIWYG target user profile: our users will be running PHP5 for the most part. If not now, in two months. Anyone who cares enough to change the default text editor in their WordPress or Drupal install is likely the kind of person to be running PHP5 and not PHP4.

Sometimes releasing new software is great. One isn't hindered by legacy issues. We are looking to the future - Foliopress WYSIWYG will be PHP5 only. In any case, Foliopress WYSIWYG is good enough that it's worth upgrading in a heartbeat to PHP5.

Other Discussion: PHP4/PHP5 Compatibility Decisions

• Mantis: Dropping Support for PHP 4
• Support GoPHP5.org
• GoPHP5
• Matt Mullenweg speaks out against PHP 5
• Threshold State: Why PHP 5?
• ifacethoughts: The PHP Rift
• WordPress and PHP 5
• What MM doesn’t know about PHP5, and how it hurts him and his users
• PHP5 Only Version?
• phpCollab 3 only for PHP 5?
• Website Baker 3 will be PHP5 only
• Next Midgard will be PHP5 only

By Alec

Why Foliopress WSYIWYG will be PHP5 Only

Post from: Foliovision

You might also like

1. Foliopress WYSIWYG: Known Bugs
2. True WordPress WYSIWYG: Foliopress
3. New Foliopress WYSIWYG version with Dropdown Customization