Slashdot Mirror

Drupal is so old school, I hear the cool kids are using http://modx.com/ now.

I'm sorry, I misused the term 'backend'. I meant their so-called 'manager' interface, i.e. the admin panel. It uses ExtJS.

I've looked a bit deeper into the DBO layer. I am very far from impressed. There is no way to be charitable about only supporting MySQL, and PHP is a cross to bear in the best of circumstances. But check this out:

http://rtfm.modx.com/display/xPDO20/The+xPDO+Constructor

First arg is an array masquerading as a string. Way to go there. The username and password may be omitted, because that's always a good idea. The fourth parameter accepts at least 30 options, supplied as an array of class constants. The last argument is any crap you might want to pass to PDO -- one presumes an equal opportunity for havoc may be contained therein.

This pretty much guarantees that you will need to extend the constructor in messy, duplicative, hard to test fashion. And the example given is just that. Let's compare that to something else:
class AbstractModel ActiveRecord::Base

Aight, that wasn't fair. Really, I would continue reading this API, but doing so is making me feel ill. The quality of the documentation does seem to be good; I wish that the author had applied his talents to worthier causes.

I was using MODx Revolution for around two years, and it has many good sides, about which you can read on their website, in the books they published and in their wiki. But there are also some issues that led me to seeking an alternative now. MODx developers, please take this as an attempt of constructive criticism (and sorry for my imperfect English).

• Too much is stored in the db, and that makes it very hard to work with git. Even with the 'static elements' functionallity one must have the actual 'element' in the database even if the code is stored in a file.
• Poor performance of the backend. The backend is implemented entirely on ExtJS and is slow. Despite it's ExtJS it still requires to reload the page too often.
• Very hard to develop own stuff on top of it. Just take a look at the tutorial on creating an extension (called 'extra'). I've developed different 'extras' to implement custom functionality in my projects, and I constantly had the feeling that they just made simple things much overcomplicated.
• Poor documentation. Just take a look on their API docs. For example, the documentation for the modX::addExtensionPackage() function just says: "Add an extension package to MODX", and no information on the arguments besides what types they are.
• Some serious problems in the core. For example, the widely used function modX::getChunk() has a performance bottleneck and can't be used in anything like, for instance, displaying a big list of products on a page, despite that this is exactly what it's for. If one instead reuses a same chunk object to iterate through a set of DB records (using $chunk->process()), the performance is dramatically increased. This issue has been reported on the forums, but didn't catch much attention (I can't even find the thread now.) The getChunk() function is widely used in some very important modx extensions, and yet the performance bottleneck doesn't seem to bother to the MODx community.

This isn't the full list. This is just some random (but major) inconveniences I can recall right now. To me, MODx is a great idea which for some reason wasn't implemented well.

I was using MODx Revolution for around two years, and it has many good sides, about which you can read on their website, in the books they published and in their wiki. But there are also some issues that led me to seeking an alternative now. MODx developers, please take this as an attempt of constructive criticism (and sorry for my imperfect English).

• Too much is stored in the db, and that makes it very hard to work with git. Even with the 'static elements' functionallity one must have the actual 'element' in the database even if the code is stored in a file.
• Poor performance of the backend. The backend is implemented entirely on ExtJS and is slow. Despite it's ExtJS it still requires to reload the page too often.
• Very hard to develop own stuff on top of it. Just take a look at the tutorial on creating an extension (called 'extra'). I've developed different 'extras' to implement custom functionality in my projects, and I constantly had the feeling that they just made simple things much overcomplicated.
• Poor documentation. Just take a look on their API docs. For example, the documentation for the modX::addExtensionPackage() function just says: "Add an extension package to MODX", and no information on the arguments besides what types they are.
• Some serious problems in the core. For example, the widely used function modX::getChunk() has a performance bottleneck and can't be used in anything like, for instance, displaying a big list of products on a page, despite that this is exactly what it's for. If one instead reuses a same chunk object to iterate through a set of DB records (using $chunk->process()), the performance is dramatically increased. This issue has been reported on the forums, but didn't catch much attention (I can't even find the thread now.) The getChunk() function is widely used in some very important modx extensions, and yet the performance bottleneck doesn't seem to bother to the MODx community.

This isn't the full list. This is just some random (but major) inconveniences I can recall right now. To me, MODx is a great idea which for some reason wasn't implemented well.

Here's some bigger fish, such as Dell, Betchel (Hoover Dam and Chunnel engineers), Salvation Army... http://modx.com/why-modx/

More tools to efficiently create more sites for fewer actual visitors.

Go to the gallery (it doesn't hurt, really.) Sort by "Rank". Note that you've never seen any of these sites. Scroll down, noting that the thumbnails repeat (...) after 6 rows for a total of 24 unique sites.

Which is pretty good, considering how many distinct CMS tools against which all high "Rank" sites must be amortized.

One day something important will happen and the Western world is going to have to stop making so many web sites. And that sucks, because I think every brand and line of lingerie should have a complete site with lots of models, rebuilt from scratch every 18 to 36 days.

So in the mean time, yay for CMS tools.