We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 28042 ☆ A M B ☆
    • 24,524 Posts
    If front-end editors were coded to use runProcessor() I do believe the usual system events are triggered (or they can be triggered explicitly in the editor's code), in which case a plugin could be used to strip the tags if the user does not belong to a Manager group or some other specified group for allowing them.
      Studying MODX in the desert - http://sottwell.com
      Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
      Join the Slack Community - http://modx.org
      • 3749
      • 24,544 Posts
      Rather than building the granularity into MODX, maybe we could allow a method for extras to bypass the setting temporarily, or a way to register themselves as exempt in a resolver on installation (much like extension_packages are registered).

      I've been meaning to try modifying NewsPublsher to work around this, but haven't had the time. I don't know if using setOption('allow_tags_in_post', true) in NewsPublsher would override the System Setting temporarily and allow the tags in the $_POST, but someone with more time might give it a try. NewsPublisher has its own permission for allowing or disallowing the editing of tags and it does sanitize all user input. The setOption() call should only be made if the user has the required permission (allow_modx_tags).

      I suspect that it won't work, in which case, the solution might be to modify the tags with some JS code on submit so they don't look like tags and decode them in the NP class.
        Did I help you? Buy me a beer
        Get my Book: MODX:The Official Guide
        MODX info for everyone: http://bobsguides.com/modx.html
        My MODX Extras
        Bob's Guides is now hosted at A2 MODX Hosting