Can MODx do this? + CMS Made Simple Comparison [was: Am I Missing Something?]

Hi All,

I have been carrying out a neverending search for the ’best’ opensource (or relatively inexpensive) CMS. I have evaluated everything under the sun (the recommended ones) ie Joomla (even new 1.5), Drupal, Website Baker, CMS Made Simple, Etomite, Jetbox, pMachine, ModXCMS etc. The problem is that all do something well, but are missing some key features I need (or need to be able to create relatively easily) - I know, I know, welcome to the club

But, I keep coming back to two: ModX and CMS Made Simple. They are XHTML compliant, are extensible, use PHP, have a great plugin architecture etc

Ok, so I want to love ModX, I really do, but the things that are tripping me up are:

1. The handling of news (blog) posts vs pages. This appears really confusing and I wonder why the ModX team chose to have everything in a ’menu’ hierachy with each called a document? Is it just me, or can I see a time where my website has hundreds (thousands??) of news ’posts’. Won’t the menu system become bloated and overwhelming to manage if every blog post (and its comments!!) are shown in the tree menu as a document?

I am sorry to go on about this, but it is really holding me back from implementing ModX (and i so want to!!)

I think I have a typical scenario where I need to create a website for a school that will allow different users to add/create/edit both news items ie "Latest sports news..." and pages "About our School" Why can’t they just either create a page or a news post? Pages would be the same as a document, but news posts need to be treated differently, they should be able to be assigned to tags/categories (whatever you want to call them) but I don’t think that should be displayed within the tree menu? What do you think, am I missing something here?? Having a post assigned to tags or categories means they can be called anywhere within a page using a snippet call. News items could be reused within a site or pages could dynamically get created to aggregate news items ie show me all posts tagged with ’sport’.

Am I right in that currently the way to add pages is from the ’backend’ and the way to add blog/news posts is from the ’frontend"? But, I could concievably create a document/folder in the ’backend’ that is actually a blog/news post?? Gee, how am I going to explain that to my users :-( ? This would seem a real usability issue, any solutions in the roadmap?


2. The user permission/access system. Man, I am confused :-( Can someone please explain to me the user/documents/user-document group relationships. I want to allow users to be able to only create/edit/delete pages in certain areas (under a category/folders etc) and/or the same with news items. it looks impossible with the current user perissions/access control. Have I missed something?

A few final questions if anybody can help me:

Does anybody have experience in using both CMS Made Simple and ModX and comment on the differences/advantages/disadvantages of both?
Are there any programmers for hire to work with us in doing custom work to extend the ModX framework for our purposes?

Thanks for your time

Dean

moderator: updated title for clarification / search purposes

Quote from: kiwi_dude at Oct 19, 2006, 09:42 AM

Is it just me, or can I see a time where my website has hundreds (thousands??) of news ’posts’. Won’t the menu system become bloated and overwhelming to manage if every blog post (and its comments!!) are shown in the tree menu as a document?

You can happily put the pages that you don’t want to see in the menu inside a folder, and just never expand it. At least in 0.9.5, this is loaded on-demand. There are other ways of getting at documents, including search, and that increases in 0.9.5 too.

Quote from: kiwi_dude at Oct 19, 2006, 09:42 AM

2. The user permission/access system. Man, I am confused :-( Can someone please explain to me the user/documents/user-document group relationships. I want to allow users to be able to only create/edit/delete pages in certain areas (under a category/folders etc) and/or the same with news items. it looks impossible with the current user perissions/access control. Have I missed something?

There isn’t any way of limiting a user to using certain parents in the backend, but this is simple in the front end (because most of the options are hidden from users). EDIT: The user group stuff *is* a mess, but we’re happy to help.

I have no experience with CMS Made Simple, so I’ll skip to

Are there any programmers for hire to work with us in doing custom work to extend the ModX framework for our purposes?

Yes.

1) The menu structure has a really handy feature that allows you to exclude documents from rendering in menus. There’s a checkbox on each page titled "show in menu" and it works great. We’ve got sites successfully running 3000 pages (or more ... even in excess of 10,000 pages, though I wouldn’t recommend that every day) .

You can create a webuser group and use the NewsPublisher snippet to add posts from the front end if you’d prefer.

2) Create a user group. Assign your editors/content creators to that group. Use Newspublisher to check for that group and viola... they’ve never got to hit the manager and are restricted by how you call your snippet (can be different for different sections).

There’s been sever discussions about CMS Made Simple and MODx ... SMF’s search isn’t so great, but Google does a respectable job.

Regarding the hiring of developers to extend MODx:

Most of the innovative features and API additions over the last year or so are a direct result of client-funded work by the Core Developers. Properly structuring any additions so you maintain an upgrade path (or if it makes sense it becoming a new part of the core distribution itself in subsequent releases) would be a major priority to me if I were to pursue this path. (And I have on multiple occasions!)

Oo, I assumed he meant in the backend menu. To clarify, the "show in menu" checkbox only affects the frontend display. (Actually, I think it’s coloured differently in the backend, but what I mean is it is still shown).

Hi Guys,

Thanks for the replies, much appreciated

Once again, please let me reiterate my willingness to get on board with ModX, but my responses below reflect my frustration with a couple of things that really hinder its usefulness:

The menu structure has a really handy feature that allows you to exclude documents from rendering in menus. There’s a checkbox on each page titled "show in menu" and it works great

Oo, I assumed he meant in the backend menu. To clarify, the "show in menu" checkbox only affects the frontend display.

I got excited about hiding the docs in the menus in the backend, until Paul clarified this for me. You can’t hide things in the backend :-( The answer of "do not expand the folder in the backend" as a solution to managing a large number of posts/pages is quite unacceptable when you are trying to give access to different content editors.

You can create a webuser group and use the NewsPublisher snippet to add posts from the front end if you’d prefer.

Hhmm, so if I had 3 user groups each with different users assigned to edit different NewsPublishers, I would have to create different pages with different NewsPublisher snippets checking for a different user group? Does it need to be this hard? Why can’t I assign a usergroup to a folder (and subfolders etc) from the backend, without having to manually edit each template?

Also, this workaround does not help me to allow specific users to ’create new pages’ restricted to certain folders/sections etc. If I understand correctly, the Quickedit is only for backend users, so to allow a user to use the quickedit functionality to edit from the frontend, they have to login to the backend first? Hardly an ideal scenario, the quickedit function would be more appropriate for the frontend users (or allow backend users to login with the frontend login form), this also does not help with restricitng specific users/groups to certain folders/document creation etc.

The user group stuff *is* a mess, but we’re happy to help

Great Can you give me an idea what you mean by "help"?

Most of the innovative features and API additions over the last year or so are a direct result of client-funded work by the Core Developers. Properly structuring any additions so you maintain an upgrade path (or if it makes sense it becoming a new part of the core distribution itself in subsequent releases) would be a major priority to me if I were to pursue this path. (And I have on multiple occasions!)

OK, how feasible is it that these backend ’user acl" needs could be addresses by hiring someone for a custom development. I mean, are these things possible given the present architecture and how useful would they be to others, is it just me that is finding this limitation crippling?

Is there anything in the pipeline I should be aware of, in regards to user access privileges in future versions? (Don’t want to spend lots of time/money on something that is already being developed)

The ability to assign user privileges to specific content areas is essential for almost all the work i need to do. A workflow/rollback system would be the icing on the cake ie Author A creates a page (only under the folder/category they have privileges for) and it needs to be approved by Editor A before it can be published. Is there a need for this, in the roadmap or would anybody be willing to extend ModX in this direction?

What about the idea of differentiating in the backend between pages/ducuments/folders and blog posts. I just need to ask "Is this what we have and things will stay this way, or is there some thinking/work on making the differentiation between news/blog items and pages/documents clearer/more defined?" I believe it is essential to make your platform viable in most websites that combine page and post creation. The current frontend/backend user system seems to do only half the job. Can we work together on this?

I hate to mention competitors, but have a look at CMS Made Simple - Demo and see how intuitive their Content->Pages, Content->News flow is. Makes sense, show pages in a hierachial manner (menu tree) and keep news/blog postings seperate. I don’t want to go with CMS, ModX offers more potential, but as it stands now, CMS is a lot more intuitive for users and even admins to manage content. The devloper in me wants ModX, but the user in me says go with CMS.

I am convinced that ModX is the most flexible/powerful PHP based CMS framework but please reconsider the way you handle news/blog posts and pages. It will make all the difference in usability and flexibilitydoe
- in my opnion

What say others??

Cheers

Dean

PS As a thought, does anybody want to create an AJAX in-page editor based on the QUICKEDIT module? Instead of a popup, it could either be a lightbox/thickbox type popup or better still an in-page editor, it could be based on frontend user groups instead of backend user groups ie login to the frontend and have the ability to ’in place edit’ without ever getting in to the backend confusion for ’tech newbies’. Maybe, the ability to add new pages (only under the folder the user has permissions for) could also be included here? Just throwing out the challenge

Quote from: kiwi_dude at Oct 19, 2006, 06:03 PM

Once again, please let me reiterate my willingness to get on board with ModX, but my responses below reflect my frustration with a couple of things that really hinder its usefulness:

The user group stuff *is* a mess, but we’re happy to help

Great Can you give me an idea what you mean by "help"?

We will help you find ways to accomplish it; lead you in the right directions where we can via recommendations, and keep you informed of how these things are being addressed and when, etc. The fact is that the cleanup of this mess is already in progress and this community can usually help you find ways to do what you want in the meantime.

As for the actual issue of content being stored as MODx documents vs. a single blog page that could be managed for a specific user, that is simply a matter of implementing a snippet and persistence mechanism to maintain the blog posts in the way that you want. The simple blog implementation provided by Ditto (and it’s predecessor, NewsListing) is not aimed at managing high-volume, multi-user blogs the way something like WordPress is, but there is nothing stopping anyone from developing that same kind of functionality within the MODx framework.

Quote from: kiwi_dude at Oct 19, 2006, 06:03 PM

OK, how feasible is it that these backend ’user acl" needs could be addresses by hiring someone for a custom development. I mean, are these things possible given the present architecture and how useful would they be to others, is it just me that is finding this limitation crippling?

Is there anything in the pipeline I should be aware of, in regards to user access privileges in future versions? (Don’t want to spend lots of time/money on something that is already being developed)

There is definitely work in the pipeline, but let’s discuss the issue of time/money vs. the idea of hiring a MODx developer for custom development that may be able to be contributed back to the project...

In my perspective, that’s the best thing you could do. Hiring a MODx developer to prepare a solution for you would ensure that your work was as maintainable as possible through future upgrades and would inevitably help the MODx project solve these problems more quickly. We are not yet a self-sufficient open-source project and depend heavily on contributions and donations, no matter what form they take; and this form of contribution is the best IMO. Sponsoring new components or core functionality in this way may cost an individual a seemingly significant amount of money upfront, but if it is done by a variety of people in a way that can be contributed back to the project efficiently, everyone using MODx will benefit as there will be a greater variety of quality vertical solutions, best practices, and case-studies available to the community. If it’s common enough functionality, as I believe what you are discussing is, perhaps some kind of sponsorship drive could provide a way for the community members most interested in these features to share the cost to have it developed.

Quote from: kiwi_dude at Oct 19, 2006, 06:03 PM

The ability to assign user privileges to specific content areas is essential for almost all the work i need to do. A workflow/rollback system would be the icing on the cake ie Author A creates a page (only under the folder/category they have privileges for) and it needs to be approved by Editor A before it can be published. Is there a need for this, in the roadmap or would anybody be willing to extend ModX in this direction?

Content revisioning, more robust I18N support, and more robust permissions in conjunction with a much simpler and proper user system are all features slated for 1.0 release. I am not only willing, but am working to this end already, though it certainly wouldn’t hurt to have some projects with dedicated funding that could be used to help quicken the timeline for getting these features into MODx or MODx Add-ons.

Quote from: kiwi_dude at Oct 19, 2006, 06:03 PM

I am convinced that ModX is the most flexible/powerful PHP based CMS framework but please reconsider the way you handle news/blog posts and pages. It will make all the difference in usability and flexibilitydoe
- in my opnion

Again, no one is forcing you to use Ditto or any other add-on that uses the MODx document structure to manage blog posts. Nothing in MODx requires this either. The idea with MODx is that you get small, reusable building blocks to create a totally custom site with very few limitations how it is either constructed or presented. This does not mean it integrates with existing PHP scripts, or that the default components will do everything everyone wants them to. It just means you’ve got a great canvas on which to craft a solution.

Feel free to contact me by PM if you want to discuss sponsoring any official MODx work to these ends or if you are just interested in contracting custom work that could at least produce some components generic enough to be contributed back...

It is always worth reading OpenGeek’s posts twice, and I’m going to read that one again tomorrow. I think he’s said this, but I’m going to say it again to make it clear:

It is entirely possible to use MODx with a custom data structure in addition to the bundled document model - doing so would sidestep the whole tree issue, and means an entirely custom solution is possible, within the MODx framework. Documents are not the only way of managing content. (Yes, this gets confusing, but that’s flexibility for you).

Basically, you could replicate the CMS Made Simple structure within MODx, but you couldn’t write MODx in CMSMS.

I would concede that if you don’t trust your editors, then you’ll run into issues with MODx as it stands presently. The majority of concerns that I’ve heard have been from people anxious about hypothetical issues; I don’t recall any actual problems that have happened. If you *can* trust people to keep within their areas while giving them more access then they need, then there’s no problem at all. However, as this *is* a framework, you can (with a little work) create whatever boundaries you need.

Quote from: PaulGregory at Oct 19, 2006, 07:26 PM

...I would concede that if you don’t trust your editors, then you’ll run into issues with MODx as it stands presently. The majority of concerns that I’ve heard have been from people anxious about hypothetical issues; I don’t recall any actual problems that have happened. If you *can* trust people to keep within their areas while giving them more access then they need, then there’s no problem at all. ...

Sorry Paul, but developing a website for a school and giving all interested parties ie community/parent groups/teachers/executive staff etc access to add/edit/change areas they have been given permission for is not a hypothetical problem, it is very real ie disgruntled parents, people making mistakes & deleting the wrong thing, spelling mistakes, bad grammar etc. Happens on a daily basis

I like the answers I am getting, it is possible, given the current framework structure. That is what I needed to hear

Very interresting thread, and nice input kiwi_dude. You’ve pointed out some inconsistencies and limitation of the current branch (the "quickedit paradox" and the permission system and workflow are awaited features for the next gen, among others).

But back on the topic. I have used CMS Made Simple before I came to MODx. This was one of my favorites along with Textpattern. Those CMS are quite similar to MODx in the sense that they have a very flexible templating system (tag based templating + content re-use -> forms in txp, global content blocks in CMSMS and chunks in MODx). But MODx adds another layer of flexibility with the ability to easily define custom data structure on top of custom design, through what we call template variables :

• You can create any type of custom content fields: text, rich text, number, date, images, checkbox, dropdown, email, url… with no limitations whatsoever. The best part: you can do so directly from the backend, without ever having to alter the database structure manually.
• Each custom field is linked to a given template: that’s why the custom fields are called Template Variables in MODx. It allows you to define which templates can use the custom variables, and possibly define several content structure if needed
• You can use, style and place those content field easily: a simple tag, [*my_template_variable*], and you can display the content wherever you like, the way you want it displayed. Better yet, if you need to make it available for frontend editing, just add a # before the variable name [*#my_template_variable*].

I am getting into details about this since it’s the reason I switched from Textpattern and CMSMS. If you like the freedom of CMSMS, you’ll enjoy MODx even more because of the added degrees of freedom (if you need it for your purpose).

A fundamental distinction between MODx and most systems out there is, it’s really a framework built on top of core CMS features.

Just wanted to point out one last thing which seems to be overlooked here : in CMSMS the news are handled by a module, an extension to the CMSMS core which does not handle anything other than pages in a directory structure, just like MODx. Right now, the MODx equivalent of the news module is Ditto, and as said earlier in this thread, it has quite a different logic since it rely on the directory structure. This sure means less usability for high volumes of news, but also much more versatility as it can be used for a lot of different things (used it to build a company directory and a product catalogue for instance). A news module similar to what CMS Made Simple has right now would indeed be possible in MODx as said earlier. I guess no one has really thought of getting started on it since there is Ditto.

But what you say make sense, Ditto is not for everyone and for every use.
The beauty of MODx is, you could build an interface like CMSMS has for news on top of Ditto. That would be like having a frontend of sorts to Ditto, maybe a Ditto module (*) ? I imagine it would not only provide a way to list articles out of the document tree, in a more blog/news like way, and who knows even offer an automatic snippet calls generator via a simple GUI (choose the sort order, number of articles to list, filter to apply... etc). Now here is an idea

(*) in MODx lingo, a module is "a program that can only be executed from within the manager" and "runs on top of the MODx architecture".. And for clarification purpose, Ditto is a snippet which are "bits of code to perform some dynamic action, such as retrieve data from a database or read from the SESSION values or a cookie. They provide the ability to separate "business logic" from the layout and presentation of your web page."