NewsPublisher and MODX 2.2.6 major problem

I upgraded several sites to MODX 2.2.6, and now whenever I edit a page through the front end with NewsPublisher, ALL page links by id (e.g., "[[~47]]") disappear!! The value is there after inserting with the Link popup; when the data is saved the value is wiped out. The URL field gets just an empty value (href=""). I even tried installing an older version of NewsPublisher (1.3.0) and the problem is still there, so it looks like it is some sort of incompatibility with MODX 2.2.6 rather than a bug introduced in the latest update to NewsPublisher. I'm having to disable NewsPublisher on my sites until this is fixed. Reverting to 2.2.5 does not solve the problem. [ed. note: rainbowtiger last edited this post 13 years, 9 months ago.]

Are any other MODx tags in the content preserved? This sounds like something is being a bit too zealous with something like a NoTags setting.

Quote from: sottwell at Dec 17, 2012, 03:53 AM

Are any other MODx tags in the content preserved? This sounds like something is being a bit too zealous with something like a NoTags setting.

Yes, I thought to check that this morning. ALL tags are stripped out. The Manager works fine; tags are retained there. Upgrading the 2.2.6 messed with some manager settings, leaving me with a blank screen after logging in. I reset the settings through phpMyAdmin so I could get in.

I checked system settings for tags and saw that "allow_tags_in_post" was set to "no". I checked a site I haven't upgraded to 2.2.6 yet, and allow_tags_in_posts is set to "yes". I changed the setting to "yes" in my 2.2.6 installation and NewsPublisher is working properly now. So, MODX is treating NewsPublisher like a blog post?? If I leave this setting on so that NewsPublisher will work, there is no way for me to disallow HTML tags in blog sections of my websites.

So it seems upgrading to 2.2.6 changes system settings without warning. [ed. note: rainbowtiger last edited this post 13 years, 9 months ago.]

Looks like it was done in fixing bug #9080; this setting apparently is applied to all front-end form posts, which certainly would complicate front-end resource management.

This setting turns On/Off sanitization of MODX tags, HTML script tags, and HTML numeric entities in POST variables, and is very important if you accept user input on your site. Unless you are specifically wanting to allow MODX tags in form POSTs in a front-end Context, this Setting should be Off. If you must turn it on to allow this for authorized users, make sure that any user input on your site is properly sanitized and filtered for the specific usage you are allowing.

Allowing anonymous users to POST MODX tags to forms is a vector for attacks on your site. The are high-risk vectors that could potentially execute any Snippet in your site, reveal sensitive data in any un-sanitized output, or allow attackers to inject markup into the response. So yes, this Setting should NEVER have been set On globally in a MODX site; that is why it is set On explicitly in the Context Settings for the mgr Context, and why we are forcing it back to Off globally in System Settings. It should only be enabled if you are sure any user input being accepted on your site is being properly cleansed manually, and you only allow MODX tags where you specifically need to allow them.

What would be the way to force it to allow such tags in something like NewsPublisher, while leaving it to block them in something like Quip?

There should be some way to allow it if someone is logged in as an admin person, as in the case of Newspublisher, even when that person is using the front end (web). [ed. note: rainbowtiger last edited this post 13 years, 9 months ago.]

In the meantime, have you looked into using QuickBar? It provides a front-end menu (menu is in a chunk and so is customizable) that opens the appropriate Manager pages for creating/editing a resource. http://modx.com/extras/package/quickbar

Quote from: sottwell at Dec 17, 2012, 09:59 AM

What would be the way to force it to allow such tags in something like NewsPublisher, while leaving it to block them in something like Quip?

That is exactly what needs to be determined. The answer should be that you can enable it per Context and rely on each component on your site that accepts user input to handle sanitization according to it's needs. Likely though, there needs to be a permission related to this filtering, so more granular control can be achieved per user.

At first I thought it was my standalone Tinymce doing the killing of my [[ and ]] symbols.
Then I thought it was only NewsPublisher .... then to find out that this setting Allow Tags in POST did exist.

I am simply trying to present source code in a blog, the way this Forum does in BBCode:


It would be grand if Extras were allowed to override the main setting and Allow Tags in POST, at least tags surrounded by <code>

And/or allow a secret prefix or parameter to tell MODx to run this or that element specified within the tags


And/or run the element tags only if createdby or editedby or publishedby has something like admin status.