Conditional output

There are a few issues I have with the output sent from MODx to clients (browsers) not logged into the manager (I don’t use the front end login and probably won’t). None of them are critical, but I find them undesirable, and would like to know if there is a way to parse the final output that MODx decides goes to the connected client before it actually sends it

Specifically:

1. When I enable quickedit, W3C will not validate any document on my MODx site. The opposite is true if I disable quickedit, but I like quickedit, so I don’t want to disable it.

The tag that is triggering errors with the W3C validator is:



I’m guessing the only time this tag is actually used is if I am logged into the manager. Why does this tag appear in the HTML source sent to clients that are not logged into the manager? I am assuming it’s stored along with the HTML content in MySQL, and then cached after the initial request, but how do I progmatically keep it if logged in and ditch it if not?

2. I modified some settings in the manager - I’m not sure which ones, but I’m almost certain it was manager user settings - and now this appears in the HTML source:



I would not like to reveal the vendor of any CMS to nasty little robots that search for vendor specific tags to later apply vendor specific exploits. Yes, I know MODx is tight and no known exploits exist (or do they?). But again, I am assuming this tag is only needed for users that are logged into the manager.

3. Whitespace is not evenly distributed based on tag depth and makes the source illegible for debugging purposes. (Having legible HTML source makes it easier for me to debug the output when needed.)

These are all very little things, but I would like to address them and solve them. I thought it prudent to come here and ask if some method already exists to accomplish what I want: Tidy code with no tags that identify the CMS as a security precaution, and to remove tags that offend the W3C validator, but only for users not logged into the manager.

I’m competent with PHP so if some one could point me in the right direction that would be great, and I’ll be glad to contribute any code that results in a solution.

Thanks,
Rich

Which version do you use?

When I enable quickedit, W3C will not validate any document on my MODx site. The opposite is true if I disable quickedit, but I like quickedit, so I don’t want to disable it.

The tag that is triggering errors with the W3C validator is:

Code:

<quickedit:content />


I’m guessing the only time this tag is actually used is if I am logged into the manager. Why does this tag appear in the HTML source sent to clients that are not logged into the manager? I am assuming it’s stored along with the HTML content in MySQL, and then cached after the initial request, but how do I progmatically keep it if logged in and ditch it if not?

This only occurs with the HTML-method. Use the tag method and you´ll be fine:

http://www.modxcms.com/quickedit.html

This is the simplest method of all and is therefore the recommended method.

To use the tag method, just replace the typical [*tv-name*] style tags with [*#tv-name*] style tags

Example: [*#content*] That’s all there is to it. The module will take care of the rest.

I have the same issue using tags. All the tags that are marked for quickedit [*#longtitle*] appear with the quickedit tags <quickedit:longtitle /> when logged out. I have emptied the cache and tried different browsers but the issue persists.

MOdx 0.9.6

Usually if the quickedit tag remains it is because the first time you view the site, is while being logged into the manager, and then it is cached that way. Make sure that you log into the manager, clear the cache, log out of the manager (do not hit the preview button), and then view your site.

Confirmed, followed Jester444’s tips and resolved the ghost tags. Thanks.

Thanks for the replies and the confirmation on quickedit. Much appreciated!

But the question remains: Is there an existing method for parsing the output from MODx before sending it to the client?

Depends on what you want to do with it. That’s what "plugins" are for, they let you hijack the normal parsing process and do whatever you want with the document at several points in its life. You would probably want to use the OnWebPagePrerender event, which if you take a look at the parser code, is called just before the finished content is "echo"ed off to the server. Actually, that final simple "echo $this->documentOutput;
" statement is kind of anticlimactic Anyway, then you can do whatever you want to the documentOutput in your plugin code.