I have been programming in web development for more than a decade. I first starting doing web after learning programming and initially had just a programmer’s view point. But since diving in I have learned and desire to use a web standards approach to development along with a K.I.S philosophy. I have written main scripts and even my own PHP OOP framework that acts as a custom CMS that is still powering some sites. After using my own framework for a period of time I sought to not publish it but rather use an existing one. And as a result have used WordPress and MODX extensively along with demoing many CMS products. So as a developer my goals for a CMS are that it must output exactly what I want for HTML, allow me as a developer to extend and create custom features apart from the core relatively easy, and allow me to train a content editor to manage the web site.
A simple definition of a template is as follows. A template handles the code that makes up the look and feel of a given web page. Ideally you want 100 percent control of the code output.
Custom fields would be a way to add custom data attributes to a web page or article. If a web page represents a product then that page needs all product data attributes connected to it. This will allow easy pushing and pulling data to different platforms with a centralized data repository. This will also allow to create features like similar products that return results based on the defined data attributes. Now when data changes it will push changes automatically to all systems using the data source.
One way to accomplish this via a CMS is to create custom fields that are attached to a web page. It would be ideal to be able to quickly and easily add custom fields and have them separated by product/template type.
Joomla! custom fields
In Joomla! it is possibly to add custom fields to an Article but after an initial review the setup seems very complex and relies on the developer creating custom database tables. Custom tables are not bad it just reduces the flexibility and increases the time required for adding/removing fields. Here is an overview of this process: http://docs.joomla.org/Adding_custom_fields_to_the_article_component, note there may be another method to accomplish this but I did not find it in my research. Also because you would be creating a custom table existing extras more than likely would not be able to use that data.
MODX custom fields
In MODX there is a native and robust feature to add custom fields called Template Variables (TVs). TVs are attached to a one or many templates. A template can easily be chosen on a per page instance. For example a template Product A could be created and then a second template Product B. Each template can share some or all TVs and then have TVs that are unique to each template. This is managed via admin/manager area and requires no additional code. Because this is native feature there are many existing extras that take advantage of TVs. Here is an overview of how they work: http://rtfm.modx.com/revolution/2.x/making-sites-with-modx/customizing-content/template-variables/creating-a-template-variable.
Web page organization
Web page organization is important to how the information architecture is presented and for the site map. Ideally there would be a way for a content editor to manage this will relatively low training requirements. This also can effect SEO in how things are set up and the generation of a search engine site map. For a developer it is ideal if a simple query or existing functionality can be used to create navigation menus with complete control over what HTML will be generated.
In Joomla! you need to learn and master are S.C.A.M. Which stands for sections, categories, articles and menus.
Note taken from video: http://www.buildajoomlawebsite.com/joomla-3/lesson-8 starting at around the 5:45 mark.
If you have built tradition websites this is one of the hardest concepts for a developer to understand about Joomla!. You don’t create pages as such. Instead you create content items and then create menu items that in effect create a page. You can have multiple menus and multiple menu items. Content is managed under Content articles and Categories. Similar to folders and files in windows. The equivalent of folders are categories and the equivalent of files are articles.
This to me seems like a huge downfall to Joomla!. It requires making many different pieces in different places to make a single page. This seems like a different approach to creating custom fields that was mentioned above and I understand this approach to be the commonly used approach. This approach can make a page more robust but each level of robustness also introduces another level of complexity. Without doing a lot of research into this I would assume that tools that are generic in approach would be difficult to develop but tools that are specific in approach would be the common approach. Then this would require following any third party menu organization method to be able to achieve the desired results. I gather that either making a good site map is difficult because you must follow a given origination of 3rd party modules/extras or you really must have a very deep level of understanding of Joomla!. And this seems complex for just for a copy writer to use such a system. Also with this approach I have to wonder about performance. The more complex a page becomes I would assume that performance will drop. It would appear that each menu and such would be unique queries to the database.
MODX uses a visual folder and files tree that is similar to Windows Explorer: http://www.threeeyedbird.com/blog/2012/06/26/modx-101-understanding-the-resource-website-tree/. Recourses, web pages, can be either a folder or a file/page and can be dragged and moved around as desired. If the template uses Wayfinder or similar extra to build the navigation, the navigation will mirror what you see in the administrator/manager. There should be no complex relationships, what you see is what you should get. And for creating a sitemap it will follow the same structure as your organization with no special setup if you use something like: http://rtfm.modx.com/extras/revo/googlesitemap.
Third party components/extensions & support
Both systems provide ways for developers to extend the basic product and they can be managed via the respective administrative web sites.
Joomla! has more than 8,000 third party extras listed on their website that are free or at cost. This appears to add a lot of value to Joomla! ecosystem. Many of the extensions appear to be specific prebuilt packages. This can be a good thing but if you are new to the Joomla! and the extension needs customizing a newbie may find it a very difficult task. Also the complex relationships with Modules, Menus, Categories and Articles needs to be understood before many of the extensions can be used.
Another benefit of Joomla! is that it has a large community and about 160 consultants listed on their site should you need to hire one.
MODX also has more than 500 hundred free third party extras along with a small but growing number of companies that provide premium extras. MODX extensions are often more generic parts that need configured or built. This often allows for a lot of customization and if the extra followed MODX coding standards then the developer has complete control of the code output. Generally these extensions do require reading documentation or a tutorial before you can configure them correctly and also understanding how to call a Snippet as that is what most extras are. One big difference from Joomla! is that snippets can be called anywhere in MODX. In a template, page, chunk and custom fields (TVs).
Content editor & manager
The concepts of creating a template and the organization of a site will dictate how a content editor will use and manage a web site. For the purpose of this article a content editor may be a person that likes technology or simply has to do it for their job, but they are in no means a developer.
Content editor would need to have at least a basic understanding of S.C.A.M. along with how the current site is set up to be able to find the content block that they wish to edit. It appears that a developer can reduce some of the fields on the Articles pages to edit, although they do appear to be Global not per template. If the organization is complex then having a content editor that makes occasional changes would be difficult for them to remember the relationships but a regular editor should be able to make their way around after training. Creating new content of blocks seems like this would be a difficult task for the average content editor as it requires a deep level of understanding of the site organization.
MODX allows a developer to hide & show all fields through Form Customization: http://rtfm.modx.com/revolution/2.x/administering-your-site/customizing-the-manager per User Group and action. In other words it is fairly easy to minimize what a content editor is allowed to edit and see. This is huge as it bring a new level of control but also allows a developer to create a very simple interface for a content editor so that they are not overwhelmed with all of the options. There is one aspect that is not always obvious, right clicks. They are everywhere and sometimes you must do a right click to see the menu options, training should be done to show editors these features. As for finding your way around the back end, if the developer followed MODX conventions finding the correct page to edit should be an easy and initiative task in the Resource tree or via the search option. Once it is found simply click on it to edit it. There are also several visual indicators in the tree that tell the status on the page. Creating pages is also follows the tree structure, where you place the new page is where it will show up on the site.