Alter the output of mutate_* actions via a plugin without hacking core

Hi All!

Wondering if there’s a way to alter the output of the mutate actions without hacking the core (Evolution).

I’m writing a plugin that pulls in an html/php/js/&more javascript syntax highlighter (CodeMirror) into the manager.

So when editing templates, plugins, snippets, etc, I’ll be able to have nice syntax highlighting. So far, I’ve got this thing working for editing templates, but I’ve had to hack some core files, specifically manager/actions/mutate_templates.dynamic.php. To show nice syntax highlighting on snippets, chunks, etc, I’ll have to hack the other appropriate mutate_* files.

I simply added an id="code" attribute to the textarea (name="post"). I needed an id to have CodeMIrror ’see’ the textarea to add its syntax highlighting.

I was hoping to use some javascript to force the id attribute to the textarea, but didn’t have much luck. Plus, using javascript to force the id doesn’t take care of everything; I also needed to remove the call to htmlentities() for the textarea’s value, so I’m pretty sure the only way to achieve what I want is to modify the literal code in the mutate file.

Any ideas on this one?

If I could get this worked out, it’d make a great plugin for all to use!

Thanks!

Maybe inspiring: http://modxcms.com/forums/index.php/topic,38607.0.html

Well gosh golly gee.

I’d found another post about a code syntax plugin, but it was from a few years ago and seemed to die out. Too bad I didn’t see this one before spending all that time last night at 3am!

Thanks!

The problem is that the original core files used PHP inline code in an HTML document. The forms are built line-by-line, with inline PHP getting data where needed and inserting it into the HTML. The two relevant events only trigger before the form is built and after it’s finished being built, but with no way to modify the form or the data being used in its construction.

If all the data it would need had been gathered and organized into an array before the form was built, then the first event could have been used to manipulate the data to be used. And if the form had been loaded into a string as it was being built, then the whole string echoed or returned (like the document parser’s documentOutput string), the second event could have been used to manipulate the finished form before it was displayed.

The way modules and plugins like ManagerManager work is to write javascript to the HTML to make changes to the DOM in the browser.

Thanks for the feedback, sottwell.

That’s pretty much the conclusion I’d reached, but I didn’t have much luck manipulating the textarea with javascript. No worries, though. I’ll try out the info from the EditArea post that mrhaw linked to.