I always struggle with the problem that WYSIWYG editors are messing up MODX template language code. Especially if I use more complex Snippet calls with a lot of parameters this is a big problem.
Sample Snippet call before Redactor:
&activationEmailSubject=`Thanks for Registering!`
and after activating Redactor:
<p> &activationEmailSubject=`Thanks for Registering!`
If you turn on Rich Text for a resource its not possible to switch back without saving the messy stuff (need to go to database and manually set back the richtext field.
Any hint on how to prevent this behavior?
Shouldn’t this be a feature of the MODX wysiwyg editors to ignore MODX tag/template language?
There’s not a whole lot we can do about that in Redactor currently (that I can think of at least) but I do know that can be very annoying.
To get around having to put complex tags into the content, there’s a few options I’ve used in the past:
- Put it in a chunk, and call the chunk in the content instead. A simple one line
[[$signupForm]] rather than what you posted will go a long way. It’s still likely to be wrapped in a
- Use ContentBlocks with the Snippet input type to insert it instead. Or the Chunk input type to basically insert the chunk approach again.
- Create a template variable “afterContent” that is available on all templates (though perhaps only for the full admins rather than every editor), and put any tags in there.
Mark’s work arounds are currently your best options. If we come up with anything for native to Redactor itself we’ll definitely let you know.
I did just have one thought. If the new Redactor API provides a hook that allows us to modify the content before it is sent to MODX to be saved in the database we may be able to add some sort of support that, based on a selector like a class name, does a find and replace for converting [[ and ]] pairs to entities. I’ll look into if the v11 API, which we will ship with Redactor for MODX 3.0 supports this.
Bah, on second thought that wouldn’t work. Redactor doesn’t send the data itself over XHR, it update the DOM in the MODX form. So, I think we’d have to do this on the server side by
- on save
- within a certain selector, or based on a RegEx, convert [[ and ]] to entities so they are saved that way in the DB
What I’m describing is basically already available as part of Garry’s plugin here and may be worth a shot:
Thanks, jp - will have a look at this