We installed TinyMCE editor extra (heralded as the most popular WYSIWYG editor for MODX) and after a few days of use, noticed that when we saved an HTML page after working on it in the editor, the HTML header and CSS in it was gone. Searching for an explanation, I found on the Web mentions of this very same behavior (mostly in Word Press forums) associated with Tiny MCE.
Some users justify this behavior saying that this editor creates its own HTML structure before editing a page and then removes it when saving that page. This assumes that the original page is just a DIV or a fragment of an HTML document. However, this default editor behavior seems unacceptable.
Has anyone else in MODX community experienced this issue?
Is there any TinyMCE setting that can prevent it from happening?
All our pages on some portals are complete HTML documents, and they break after we make any modification and then save. When we check, DOCTYPE declarations, HEADER sections (including all CSS and JS sections) are gone.
However, if I understand you correctly, all your html is contained within the Content area of some resources? When this is the case does your template only contain [[*content]]? Under these circumstances I would be very cautious about using any sort of Rich Text Editor on the content area.
Mate it’s possible that your answer is in the settings area.
personally I use “TinyMCE Rich Text Editor”, it’s another version but very customizable.
this version has a setting called “Valid Elements” where you can choose what labels you will accept on the html code, eg:
With this is so easy modify the text editor and decide exactly what you need.
Nut I think the version that you are using should have a similar setting, hope that helps.
+1 for Andy’s suggestion that the outer HTML for a page (html,head,body tags) be put in the template, not the resource content. Not only will that make TinyMCE behave, it should also reduce the load on the database and speed up page loads.
Another huge +1 for @andytough’s response regarding FULL HTML documents in the content field of a resource. This to me seems to defeat the purpose of using a CMS at all. At the very least the common elements should be put into a template and or chunks and use TVs to change some of the properties of the Template at a per resource (page) level.
Thank you all for your thoughtful replies. We do use templates in some of our portals developed in MODX. The ones I have this problem with are generated by developers in other tools (like Muse - and yes, I know it has been discontinued and Dreamweaver), so in these cases we try not to play with their HTML (I guess, in an ideal world, all MODX development should be done in… MODX, right?). The problem started when we tried to provide a WYSIWYG editor to some portal’s content editors, so they could graphically add text, documents, etc online to their pages. Unfortunately, TinyMCE is enabled on all portals, so, it caused issue with the ones without templates!
So, if TinyMCE’s default is to remove HTML and Header sections, I guess it will not work for us.
OTOH, how complicates would it be to check first if tags like <HTML>,<HEADER>,</HEADER>,</HTML> exist in a page when opening it?
You can disable the editor on specific pages if that helps. On the resource settings tab, uncheck Use richtext, and that will then fall back to the raw HTML.
Thanks @markh. Unfortunately some of the pages we would like to allow users to modify are complex HTML documents, so providing them a WYSIWYG interface is almost a must.
For users to be able to update pages, they need to be capable of
uploading new content (images,videos, documents)
modifying some page HTML
To do that in MODX, my understanding is that they will need to connect to the manager dashboard with higher (but still limited) permissions than read-only users. Therefore, I granted them a slightly modified Content Editor role and enabled TinyMCE. As we saw, this has issues and limitations.
So I guess the more general question (and I should probably create a separate post for this) is:
What solutions do MODX administrators use to create user-updatable websites/CMS’s?
The general idea is that, as others have suggested, that you break up a design, and then make the segments that need to be editable in fact editable. That includes using the content for just content (e.g. the basic text/images on a page), and TVs or standard resource fields for other editable portions like hero elements or sidebars etc. The other markup, and especially things like head, headers, footers, etc: those go into the shared template.
That means that you, as the developer, create basically a bespoke set of templates that the other users fill in. There are different levels of complexity and functionality that can go to, with something like ContentBlocks as the more powerful page building with different layouts and such, while the standard page title and content fields at sufficient for the simplest pages.
The workflow using Muse/Dreamweaver you mentioned isn’t quite compatible with the general idea of using a CMS as I’ve used them. If such a workflow is what your clients need to use, why not just let them upload the resulting HTML over FTP and skip the CMS entirely?
Or to flip the question around, what is it you’re hoping to achieve with a CMS (wether MODX or otherwise)? Are you trying to get your users to stop using Muse/Dreamweaver/full-page (i.e. u templates) HTML editing, or is that a continued requirement?
Thanks for the exhaustive reply, @markh.
We are relatively new to MODX intricacies. Once chosen as our future CMS, we had to convert a number different portals to it:
a) Ancient Oracle Portal sites (for which we creates templates and individual content pages with TVs).
b) DW/Muse sites (for which we either embedded all HTML in individual MODX pages or just left them as physical files)
c) Newly developed portal sites (which will be MODX-complaint)
Clearly from yours and other replies, a common way to allow users to edit pages does not seem viable.
I also tried NewsPublisher, but could not mak eit work. Anyone has experience with Fred or other editors? Do they all behave like TinyMCE?
As with all content management system you need to define editable areas for your editor to manage. Fred, tinyMCE, redactor, contentblocks or any other solution will all require some form of integration into your html. If you’re pasting in entire HTML documents into the content area of a resource then you’re narrowing down your options of integration methods and those options are somewhat dependent on the markup produced. For example if you had an article that you wanted to make editable then you could do something like this:
<article>
[[*RichTextTV]] // Using TinyMCE or Redactor etc
</article>
Which could eventually render results such as:
<article>
<h1>Heading</h1>
<p>lorem ipsum dolor sit amet.</p>
</article>
However if your markup is more crowded with classes and requirea a class on each element tag too then it may not render correctly ie if you needed:
<article class="generic-article">
<h1 class="generic-article_heading--large">Heading</h1>
<p class="generic-article_paragraph--regular">lorem ipsum dolor sit amet</p>
</article>
TinyMCE won’t inherently know to put these classes in and so having clean html and css can be quite important for a rich text editor solution.
Fred is also a great option but you’ll need to again get involved in the markup to be able to setup the correct dropzones and editable areas. That being said if your markup is drastically changing from page to page, rather than creating a plethora of template variables and templates then Fred is probably your best option, aside from editing directly in the HTML. I want to go as far as saying you’ll just need to insert one opening and closing tag to define editable areas, but don’t quote me on that.
If the pages that are being created actually share the same component markup then introducing content blocks and building the pages actually in MODX with content blocks could be a really good and viable solution for you. I encourage you to take @markh up on the consultation to determine if this could be a good solution for you.
I think pretty much all rich editing tools for MODX are meant to operate only on a portion of the HTML. Fred/ContentBlocks are page builders, so they offer more capability, but are still focused on just their content bits.
You mention you created templates and individual pages with TVs for the Oracle Portal sites - that’s likely what you’d need to do for the DW/Muse sites, too.
If you imported the content into different contexts, that could help in easing you through the migration. You could enable a rich text editor like TinyMCE for the contexts (portals) that were properly migrated to a templated system using a context setting, and disable that editor it for DW/Muse sites that still expect the full HTML in the content. The DW/Muse editors would still use their previous ways of editing pages in DW/Muse and copying that into MODX or overwriting their physical files; until you’ve converted it into templated resources.
It might be worthwhile to consider booking a consult to discuss what you’re working on here in a video call. You could show how you’ve imported things and I can try to explain/show how that specifically would (or would not) fit in the CMS/MODX model and recommend how to move forward. There’s a lot of knowledge in the community, but it does seem like you have a very specific situation that warrants diving deeper than a couple of forum posts allow.