MODx Advanced Capabilities

Just a minor note:
To win votings, your position has to be crystal clear. MODx is still hovering between CMS and CMF. The more CMF you are the more you limit distributional standard-forms of components which work on an "install&go" basis. That’s, basically, the difference between an API and a framework. As far as I can see the success of MODx is limited to a community which is based on small "we-must/can-do-it-all" businesses, i.e. people who do the design, the programming and the hosting all together. This segment of the market is limited, though.

Moderator note: Split originally from the Pakt Awards Announcement thread.

I respectfully disagree on your analysis there mr. silent.

In fact, none of the large projects I’ve worked on with MODx have involved a team smaller than 3 or 4 people, all specialists in design/code/etc. Then again, I’ve got a bit more experience with MODx than your average user, too...

Great, Mr. Thrash!
Why don’t you let us share the results of your big projects and give us links or at least descriptions of time/effort/functionality relations? The majority of examples I find mentioned here in the forums are, well, pretty small. (which does not inherently mean that only one person has done it, could be 3-4...)
I would have loved to use MODx in the last two of my projects, but I couldn’t - due to workflow and multi-language issues. Honestly: those are - for me, but maybe not only for me - the main two reasons to distinguish small from big projects: workflow and multi-language. Where has MODx made his points here?
Or where will it make them?


EDIT: I come back here to the issue I had with David M. - success stories! We need them! If we cannot rely on a huge user-base we must and should rely on huge success!

Quote from: silent at Sep 21, 2006, 10:16 AM

... MODx is still hovering between CMS and CMF. The more CMF you are the more you limit distributional standard-forms of components which work on an "install&go" basis. That’s, basically, the difference between an API and a framework. As far as I can see the success of MODx is limited to a community which is based on small "we-must/can-do-it-all" businesses, i.e. people who do the design, the programming and the hosting all together. This segment of the market is limited, though.

I believe it is just the opposite; the less CMF you are, the more you are forced into hacked solutions on top of components intended to be install and go. This traditional CMS space is for non-technical users to put up sites without any development work, typically with preskinned components with limited options for changing the look and feel. The key differentiator being the ability to isolate three different concepts, the the content/markup, the design/style, and the logic. In this sense, MODx makes it easier than ever to divide responsibilities among content editors, designers, and coders, in a way that is much more maintainable than the traditional approaches, IMO.

Quote from: silent at Sep 21, 2006, 10:50 AM

I would have loved to use MODx in the last two of my projects, but I couldn’t - due to workflow and multi-language issues. Honestly: those are - for me, but maybe not only for me - the main two reasons to distinguish small from big projects: workflow and multi-language. Where has MODx made his points here?
Or where will it make them?

We do not offer out-of-the-box worflow or multi-lingual solutions yet, so your requirements do not match the product at this time unless you decide to implement a custom solution using the framework. I do not consider those functional requirements to be the difference between small and large projects however, nor do I consider them a limitation for implementing such requirements on real-world projects. It’s simply a matter of what you get for free, out-of-the-box, with MODx, vs. what you have the resources or funding to develop and/or purchase as part a project.

The project I’ve worked on are not multi-language project (yet). Two quick examples for you though (not counting client contributions to content of course):

http://mymedcard.com/ was developed over a 4 month period and involved a team of 5 folks. Copywriter + Designer + Project Mgmt + Double Down on Coders ... things you won’t be able to see include custom components that dynamically and automatically build the card envelope stuffer (address label "stamped" into a designed statement stuff type printed piece), custom remote data query tools to pull and update card printing status, automate the card printing, lots of administrative reporting, lots of user self-management tools and so on. This uses XPDO extensively, which is playing a much larger role post 095.

http://corganics.com/ took a couple of months and 3 people (design + code + proj. mgmt./genral assistance). It uses a customized version of ShopX and ties into a real merchant account processing system, and will be one of the first multi-lanugage sites when it becomes more straightforward in MODx.

If you need multi-language sites (robust implementations thereof) right now with publishing work flow, 095 or earlier is not the right tool for the job (as it comes "out of the box anyway"). 097 is built on top of XPDO which is available today, and XPDO will be available as an add-on to 095 I suspect. It definitely takes discipline and conscious effort to manage multlple-contibutor jobs, but it can be done.

You are correct though and its a very fair statement to say that most of the projects mentioned on the forums are handled by micro- or mono-teams (1-2 folks). But that doesn’t define the project’s capabilities.

But that doesn’t define the project’s capabilities.

It surely doesn’t. That’s why I’m here. Thanks for the info! There is still a highly promising way to go. And I’m confident that the discussions we have here are a valuable contribution. Thanks also to OpenGeek. I do not share his opinions in this specific case - but I appreciate them and have to think about them... and will come back to them- since I think he might get on a wrong path.
Just cool to have the chance to do so- a valid, real pleasure!

EDITEDIT: I changed some wordings of this post, but not one of its intentions...

Definitely LAST edit: I would like to see MODx compete with RoR than with J!
Joomla is ok for those who are ok with predefinied limits and architectures, whereas RoR relies on a new approach of programming. Sticking to PHP and harvesting all of the experiences made with this type of development seems to me to be the right way to go. MODx will not be able to compete with J! for the next few years - just in terms of user-base and sites done - but it could attract all those who feel limited in their dev-skills, which are based on PHP. I’ll shut up now, waiting for the final 095 release...

I’ve said for a long time that MODx will be "Ruby on Rails for the rest of us" (i.e., ubiquitously deployable, equally capable, and easier to start with). And on that note, I’m splitting this thread off, as there’s some interesting dialog going on here.

Indeed, interesting thread.

Two issues, then:

"Positioning" as CMS or CMF
It is true that if being a CMS is not the main focus, and if being something for people who just need a CMS is not the main focus, then the chances of winning a contest of CMSes is not as likely. At the other extreme, if MODx wasn’t in any way a CMS, it wouldn’t even have been eligible to enter.

Not winning a CMS popularity contest does not mean that MODx needs to change from the current situation of being a CMF with a CMS pre-installed. To change to being just-CMS would be like rethinking long-held university plans because you didn’t win a local beauty contest that you entered on the spur of the moment. To change to being just-CMF would be deciding never to enter another beauty contest, even though you have already planned a long-term diet plan and have posture lessons scheduled for alternate Thursdays. MODx is a working CMS in a CMF where you can change it. It’s the greatest starting point available. Not fitting into boxes defined by other people is a sign of uniqueness.

MODx was never about "being the most popular CMS". I doubt it ever really will, because it does currently need multiple skills (ie a large team). It’s unlikely to be the solution of choice for a non-programmer’s one and only personal website. If you can’t reapply skills learned on either another project or extending the project, then MODx probably isn’t ideal. Thus I think the number of MODx websites is always going to exceed the number of MODx users.

As it stands MODx doesn’t provide a full role management structure; others will rejoice that MODx doesn’t impose one. So from a user privilege point of view, in practical terms either team members all have full access or you create systems to limit access yourself. This doesn’t mean a large team can’t use MODx - it just means you have to trust the team.

I think that 2 beliefs are necessary to agree with OpenGeek’s words:
1) Dividing responsibilites doesn’t mean denying users access to areas outside their remit.
2) Truly large multi-national organisations have a website for each area / language, rather than one monolithic multilingual website. Easy code re-use between multiple MODx sites (and a range of language options for the Manager) makes a multilingual site network attractive. Therefore size and multi-lingual single sites are not at all linked.
As I truly believe both these to be the case, I agree 100% with OpenGeek’s view above. And I don’t always agree with him.

MODx isn’t designed to win a CMS popularity contest, it is designed to enable people to create and maintain websites that aren’t cookie-cutter copies of each other.

The lack of examples of "big" sites done in MODx
Whilst the MODx community is one of the strengths of MODx, it is absolutely false to assume that this forum represents all the users. Quite a lot of first-time posters have managed to operate a MODx-powered website for several months.

And because the licence of MODx does not require every site to announce that it is "powered by MODx", many users are quite rightly not publicising the fact. I have lost count how many MODx powered sites my company has launched for clients, and I have no intention of discussing any of them directly on this forum or anywhere else. Perhaps where I am the only stakeholder in a site, then I may use a site as an example here and there, but it just doesn’t feel right to talk about other sites here. In any event, most of them are not particularly special or earth-shattering - they’re just websites that work.

At least one of the people whose sites are in the "You and Your Sites" section has asked me to obscure the references to the domain because the client doesn’t want the technical discussion of the site to show up in the search engines. I’d imagine that designer will think twice before discussing his next site on the open internet.

Finally, of the two sites Ryan mentions, I’ve seen him mention Corganics a few times where it is appropriate. I’ve never seen him mention the med card one - the use of work-in-progress 0.9.7 features makes it a misleading example of MODx given that 0.9.2.1 is still the current release, and I’d imagine that would count as a pretty good reason not to big it up here. Plus, as MODx *is* a framework, anything is possible with it.

All in all, the larger the site, and the bigger the team, the less likely it is that the site will be mentioned here.

But we don’t need to prove that MODx works in large team sites. Your limit is your imagination and ability. I can see that examples and provided code help, but essentially what you’re saying there is that it’s easier if someone else does something. If you need additional skills, then you need another team member. MODx itself could be considered a team member, but it’s not always going to fill every gap in your team.

Quote from: silent at Sep 21, 2006, 11:36 AM

I would like to see MODx compete with RoR than with J!
[...] Sticking to PHP and harvesting all of the experiences made with this type of development seems to me to be the right way to go.

Indeed, easily porting or integrating a long-established PHP application is much more attractive than trying to find an appropriate RoR solution to reuse (or more likely writing from scratch in RoR). The quantity of open source available for PHP makes it a safe decision.

Quote from: rthrash at Sep 21, 2006, 12:56 PM

I’ve said for a long time that MODx will be "Ruby on Rails for the rest of us" (i.e., ubiquitously deployable, equally capable, and easier to start with)...

Quote from: silent at Sep 21, 2006, 11:36 AM

...Thanks also to OpenGeek. I do not share his opinions in this specific case - but I appreciate them and have to think about them... and will come back to them- since I think he might get on a wrong path.
Just cool to have the chance to do so- a valid, real pleasure!

...I would like to see MODx compete with RoR than with J!
Joomla is ok for those who are ok with predefinied limits and architectures, whereas RoR relies on a new approach of programming. Sticking to PHP and harvesting all of the experiences made with this type of development seems to me to be the right way to go. MODx will not be able to compete with J! for the next few years - just in terms of user-base and sites done - but it could attract all those who feel limited in their dev-skills, which are based on PHP.

I’m glad you are enjoying the dialogue; I certainly am too...

We’ve got to be careful though, because when speaking of Ruby + Rails vs. PHP + MODx, there are some significant differences at the language level which make them difficult to compare, but I think ultimately, it comes down to three key points when MODx goes head to head with Rails: data schema/storage/manipulation, run-time configurability (think data-driven vs. build-dependencies), and run-time performance; though the Agile purists and Ruby and/or Rails enthusiasts will likely have a lot more points to add in the fundamental Ruby vs. PHP debate.

That said, xPDO is my initial attempt to address some of the features in all three of these areas, and though it still requires some more implementation work to truly start to compete with RoR’s ActiveRecord facilities and automatic schema change handling, I believe I am on the proper path with this effort, especially after my attention came upon the debate surrounding this post on how object-relational mapping solutions are the computer science equivalent of the Vietnam War. That post and many related to it have inspired me to some new thinking on how to handle xPDO’s object caching mechanisms, and have me yearning for a pure object database solution in the vein of db4o, except targeted directly at PHP/JavaScript in the context of AJAX/Web 2.0.

I’m gonna stop right there; I’ll have a lot more to say on this soon, probably in a series of blog posts I will be featuring in conjunction with the initial previews of the new xPDO-based MODx core.

Very nice debate indeed... good call to split it from the original thread.

We had a lot of discussion among the team during the marketing IM conference a few months back : was MODx to be positionned as a CMS of CMF ? There was a large consensus for the CMF positionning (maybe unanimous actually...). Most of us will agree that MODx might just be the most flexible open source content management platform around these days, and by a long shot at that. Having tested a LOT of those, it sure is my opinion.

Of course, some key features are still missing : workflow and multilanguage have been mentionned. User management could also be a key MODx weakness. But choosing a system is always a balancing act, and MODx has more strong points than limitations. One of those strong points is, you always find workarounds to the limitations, that’s how flexible it is. I am not even mentionning the fact that choosing a system is not only based on the current state of things but also on the perspective there is for the future.

Jason’s post about 1.0 have me convinced the future is pretty bright indeed, and workarounds can do the trick until then. It’s my bet, and some people will do the same too. My point is, making a choice is not only a feature based decision but also a philosophical one : choosing flexibility and design control over features coverage is, to me, the best way to go.

Last but not least, even if so far I (and others I know) have worked mostly alone, on small to medium projects with MODx, it won’t always be that way. I already had some opportunities that didn’t translate into contracts for which I contacted MODx coders/developpers, since it was out of my skill scope. I am pretty sure it will happen more and more often. Hopefully, this will help the dev team funding development, as I am very much into the idea of having client fund new features, modules, plugins and snippets (developped under a GPL license).

I have said this a few times : I believe there is room for a MODx (certified or not) professionnal network. I already have a list of people I will definitely call if I need things out of my skill set. As the marketing guy, I am fond of the idea of coordinating business opportunitites through a marketplace and connecting skilled / available people to work together on MODx projects, which could prove especially useful for advanced projects requiring different skillsets. It’s been on my mind for quite a while and when the time is right, I’ll take the lead to make this happen.