The modx backend. A living nightmare?

Ok this is my first post here and so I say hello to all faithful modx followers (and to the leaders as well):

HELLO.

I also want to express, that my modx "career" started only a couple of weeks ago and believe it or not I’m halfway through with two (and a half) commercial projects. Something I would never have dared to dream of. It just happened. In other words I believe modx is a great in many ways and it has potential to become even better.

Still there?

OK, now get yourself a nice cup of tea and listen for a while...

(Attention: The following lines may contain offensive content)

<rantmode>

Though I learned from the forum that some of the things I’d like to discuss will change in the (hopefully not so far) future, I feel compelled to let off some steam that has been building up in the last 24 hours.

What’s wrong with that backend?

Sure it looks nice’an’clean. You even have four different themes to choose from, but underneath it’s a living nightmare! I’m neither talking about the frames (in fact I like them), nor I’m talking about the table monsters that terrorize the neighbourhood. No, now I want to talk about the really important stuff: Forms.

Please, enter your backend and push the "New Document" Link. This is what most of our customers will have to face most of the time. In other words this is where the magic of modx happens.

What we see is a nice form cut into thee pieces each one containing a one or more form fields:

- Document Setting
- Document Content
- Template Variables

Now have a look at at mutate_content.dynamic.php as well into the resulting html code.

Nowhere I can see a <fieldset> enclosing the three areas. Instead of a nice <legend> I get a meaningless div around the headlines. Even a <h3> would have been far better than that.

And this is just the tip of the iceberg. Tons of inline styling and a complete lack of semantic or at least clever class attributes. Some of you might ask "Why is this important"?

Well it makes simple things so much harder.

Example:

A simple class for each row of the table would give us designers the opportunity to switch part of the form fields on and off.

<tr class="tv_description></tr>
and
tr.description {display: none;} (I know there are other ways to do that...)

No need for javascript plugins anymore to accomlish something as simple as this

Even inserting special text containing instructions would be within reach. :before and :after would just do the trick.

Those <tr> around the TVs could also use individual classes. Somewhere around line 970 you could simply add

class="tv_’,$row[’id’],’ to the line creating the <tr> tag for each template variable.

Even a monkey could finetune the backend that way.

</rantmode>

Please don’t get me wrong. This is not about biting the hand that feeds me. After all, this is open source and free (as in free beer).

It’s just that I can’t understand why something as clever as modx completely fails to meet the most simple standards in this particular area. Please don’t tell me this is a common problem in other parts of the code as well.

Semantic html, basic use of css. I thought this is what modx is all about.

Really, something as simple to achieve and as important to have should not be the subject of desperate hacking attempts.

I know that there is a magical 1.0 hovering over the modx community. I didn’t have the time to check up the respository BUT I really hope the backend gets a serious overhaul.

So that’s it for tonight.

Keep the faith,

pepebe

P.S. If anyone is interested in "hacking" parts of the backend to beat some sense into that beast, let me know. I will gladly participate.

Check the repository: http://www.modxcms.com/resource-listing.html?tags=manager
and look for ManagerManager and http://www.modxcms.com/Customize-Manager-Fields-1342.html

Check the wiki:  http://wiki.modxcms.com/index.php/Customizing_the_Manager_Homepage

The power of modx is that you can fix it, you can build it, you can choose by yourself.
Check the forum: http://modxcms.com/forums/index.php/topic,33046.0.html

Many snippets/plugins/modules/modx-functions wouldn’t be what they are if not the community/forum
discussed how to improve them. So please dump your good objective ideas. 

//I’m a "modx follower" = My modx solutions are not like anyone elses

This is a very constructive rant that I share the sentiment with. That i am crazy about MODx is a given, but some of the markup of the manager is a nightmare, for sure. I am very excited with the upcoming release of Revolution and all that it promises. However, one of the side effects of the commitment to the Revolution development is that the 096x branch hit a stalemate in terms of UI enhancements (there have been countless under the hood enhancements). And I am the first to say that as a community the responsability is all of ours to fix this.

I think that some of these issues are what spawned the Revolution project in the first place, it sometimes is easier to simply start from a clean slate than to fix legacy code (some of which is pre-modx).

P.S. If anyone is interested in "hacking" parts of the backend to beat some sense into that beast, let me know. I will gladly participate.

You can count me in on this, but there would be a lot to change. But it would be sooo much better I have been meaning to ask if the team will maintain a dedicated dev team/group for maintaining the 096x branch once Revo is released or will it be maintained simultaneously by the same core team?

Thanks for the constructive rant (I am still looking for the offensive content, must be between the lines).

I think much of what you’re talking about is legacy code not written by anyone on the current development team. I suspect that if there were an easy fix it, it would have been done some time ago -- thus the impetus for Revolution.

I’m speaking strictly for myself, here, not for MODx or for the development team, but as soon as Revolution is released, I’m switching all my non-trivial sites to it and never looking back. I’ll also recommend Revo to all new users. Architecture aside, Revo is infinitely more convenient to use and to to learn and the Manager is much more intuitive.

Here are just a few of my reasons:

• Add-on installation with a few mouse clicks in the Manager. (If you want to see this in action, install Revo and install SPForm -- you’ll have a working, spam-proof contact form up at your site when the install is finished -- compare to the few dozen steps and mis-steps to do this in 0.9.6).
• Add-on upgrades with a few mouse clicks in the Manager.
• Add-ons configurable during installation via GUI. (Imagine getting a Wayfinder dropdown/flyout menu on installation -- it doesn’t exist yet, but it’s quite doable in Revo.)
• Upgrade to a new version of MODx without FTP.
• Search for System Settings by name or description.
• Edit snippet parameters (properties) in a grid without worrying about ampersands and back-ticks.
• Edit any and all $lang entries in a grid in the Manager.
• See the list of documents, snippets, chunks, files, or plugins with one click.
• Cache pretty much anything.
• No more confusion from nested caching.
• Customize the Manager’s menu system with a few clicks.
• Greater granularity in permissions.
• Permission access policies.
• Run multiple sites that share the same MODx core.
• Locate the MODx core outside the site root.
• Easy access to MODx objects in your code.
• Easily create new MODx objects in your code (docs, system settings, chunks, you name it) and set *all* their properties.

@mrhaw Thanks for the links. Especially the one about "Custom help page for users". I never even dared to hope for such a nice feature...

@dev_cw So revolution is really something to look forward. Nice to know. I’ll have a look in between projects.

I agree on your idea for a some legacy support for the 0.9x branch.

You can count me in on this, but there would be a lot to change.

Lets start with manger/actions/mutate_content.dynamic.php. It took less than 5 minutes to add some individual styling options for all <table> and <tr> elements. It’s all hard-coded html. Adding the lacking <fieldsets> and <legends> would also not be a problem. I can’t see any problems with existing plugins like for example manangermanager, but I might be wrong about that.

I don’t know where to post such changes here. Cut’n’pasting the code here doesn’t seem to be appropriate. Any recommendations how to proceed?

@BobRay More facts about revolution that make it sound very promissing. Thanks for the overview.

I suspect that if there were an easy fix it, it would have been done some time ago

Sometimes its easy, sometimes not. You have to start with the easy ones and believe me if mutate_content.dynamic.php is in any way representative for the rest of the backends coding, than it might be like stealing the proverbial candy from a baby

but as soon as Revolution is released, I’m switching all my non-trivial sites to it and never looking back.

Experience has taught be to wait for a while before I present "revolutions" to my customers. I’ll start with some localhost experiments and perhaps even a life bloglike thingy so I can see what happens from a "safe" distance.

Greetings,

pepebe

I’m speaking strictly for myself, here, not for MODx or for the development team, but as soon as Revolution is released, I’m switching all my non-trivial sites to it and never looking back.

I have 2 problems that will keep me from being an early adopter (well 3 if you count that I am never an early adopter of anything, but that is another issue all together) - 1) is that I have not had the luxury of spending any significant time with Revo, so I will first need to get myself to speed. How fast that happens will depend on my workload and the type of sites I am working on. I am only aware of a handful of people that have really dived into Revo at this point so community help will be limited (I suspect you will bear a large load of the assistance since you seem to be the most knowledgeable on Revo outside the core team); 2) I have just recently reached a point of total comfort with 096x, it took a lot of time and effort getting to this point, to start from zero is a bit overwhelming and as with the previous reason it will depend on the types of projects i will be working on. Ironically the projects I will be ’learning’ Revo on will need to be simple projects (to avoid missing deadlines while I learn a specific feature or method) which is what 096x would be better for while more sophisticated projects would be in 096x because that is where I feel comfortable that I can deliver what I promise

Don’t get me wrong, I am very excited for Revo’s release, the sooner the better. Once I finally get my feet wet it will be ’the one’ for sure. I am not the brightest bulb on the tree so it may take me some time to get to feeling comfortable in the new realm, specially when client expectation are on the line.

Now, on the other hand, I wouldn’t be surprised if the team may have an assault plan with major tutorials and learning material that could demystify the transition, in which case it will take much less time to get to speed (for me at least). I trust that the award winning team knows what is needed.

Sometimes its easy, sometimes not. You have to start with the easy ones and believe me if mutate_content.dynamic.php is in any way representative for the rest of the backends coding, than it might be like stealing the proverbial candy from a baby

From what I remember most of the presentational code should not be too difficult to clean up. Did you already do the mutate_content.dynamic.php file? Don’t forget to check the dynamically generated stuff like the TVs and input widgets. I am sure in some cases it may be a domino effect. Also need to consider that by editing the markup for these pages several plugins may no longer work (ManagerManager will definitely need to be tweaked since it won’t find the sections).

Oh boy is this my favorite thread of late ... ;0

Let me start when situations like this occur and I catch them soon enough: Welcome aboard pepebe and thank you for volunteering!

I agree 100% with your analysis and your suggestions for improvement are dead on. I welcome your semantic-stylings for our Evo 1.0 release and the sooner you can create a patch set and we can start getting them incorporated and tested, the better. The legacy code is a bit of a mess in the manager, and I too am not talking about the frames, though I’m not as big a fan of those are you are.

I also agree that this really won’t talk all that long to overhaul, but I’ve simply not had the time to tackle this outside of some internal work I can never seem to get around to finishing. While it’s being addressed, I think every field should also get a unique ID, too, on it’s containing element. And the tables can go for the most part too, where appropriate. Unique IDs on the fields and wrappers and whatnot will make it easier to do cool things with ManagerManager, which I find indispensable at this point for first-class customer experiences: generic CMS with a bespoke feel and experience in no time.

And to answer a couple of points above. We have adjusted the markup a little, but never went past a rudimentary brush up. Also the legacy branch will indeed need a team to maintain and we honestly expect it to be around for a long time (via Evolution). Revo is going to be quite cool no question, but Evo isn’t going to be ignored or deprecated any time soon.

Please create a JIRA account and let’s get started (and PM me offline with a good time to have a quick Skype voice chat and to plan some minor details).

Good to hear you are on board Ryan. I was not sure if this was a welcome discussion since it may open a whole new can-o-worms on 096x and divert attention from Revo’s release.

@pepebe feel free to delegate some tasks to me, once you have defined the markup I can help with the modifications

I’ll join the party!

@rthrash: I’ll find out what JIRA is and create an account. Don’t expect anything before Monday.

@dev_cw: I have already begun to strip the code from all unnecessary trash. Right now the whole thing is free of tables and has plenty of <formfields>, <labels> and <ul> to organize the content. Perhaps I have went to far already, but there is no way back for me now. It just looks to good to be ignored. I’ll post the results on sunday or monday.

Some things that came to my mind during overhauling the code.

- Buttons/links to switch on/off different formfields. It’s way faster than scrolling down to the template variables. Hot or not?
- Couldn’t core variables like "pagetitle" or "description" be organized under "manage resources"? This way you could give some documents all variables and other none. Also some internal control over the general layout of a formfield would be neat (this would also be true for template variables). Seems to be some serious slashing an trashing. Anyone interested?
- Any idea how to change and manage stylesheets for the backend depending on user, group, documentgroup?

Any other ideas, wished?

Greetings,

pepebe

P.S. Tomorrow I’ll create a new mail adress for this project and pass it arround to all people willing to participate. Skype also sounds good, but I have to buy one off those damned headsets before we can do this. It was already on my wishlist. I wonder if I could use my mobile bluetooth headset...

Please do not mess ManagerManager... it is a great addon....