MODx CMS and PHP Application Framework Bugtracker

This poses the question of do we want to force all queries through the DB API and do we want to address escaping things at the DB read/write time vs in the modules/snippets/etc.

What we need to do is look at the way template variable values are stored in the database and implement a way to determine the variable type and run the htmlentities function on the value for mainly text and textarea types before they are saved the database. I don't think richtext types need this since the RTE's should take care of entities on their own (or they should!!).

Might have a solution to this....need to test it though.

I've found a solution that will maintain HTML entities for template variables using the text, textarea, and textareamini types. These three seemed to be the most likely targets for this since the RTE's pretty much take care of any entities for richtext types. I'm assuming that's what we want. If other template variable types have this problem, we can always add them in.

I'm going to test this a little bit more and commit it for the 0.9.1 release.

I'm marking this as complete for now. Should other template types have problems, another bug report can always be submitted. :)

Actually guys, I think this should be handled outside of the saves to the DB. Making this happen at that level forces restrictions on the content and are dependent on too many conditions for my liking. It would be much better to address this at a content preparation level, when all html entities in URLs or tag content are replaced before being sent to the browser, based on validation standards. Great idea for a plugin, or if you prefer to have it happen on the DB saves, why not a plugin for that? ;-).

That said, I plan on implementing some new API methods associated with the DBAPI that will allow automatic handling of string escaping when querying, inserting or updating data, so the values returned by the API can be used without worry about this, but I don't think handling (X)HTML entities in this way is the proper approach.

Hmm...interesting idea. I'm all for it! Whatever works the best is fine by me! :)

After further thought on this, I agree with Jason that HTML entities will probably need to be handled differently. However, until we get a new solution out I think we should stick with the small changes I've made so far as a temporary solution. Keep in mind that the changes I made only effect plain textboxes and textareas only...other data types are uneffected (including richtext areas!). If a user creates a TV with a plain textbox then the resulting input would need characters like ampersands to be converted to proper HTML entities. For now, the changes I've made will work...but we'll definitely need to think about this upon rewriting the API for TV's.

Ok...after further testing, I'm reverting the code back to how it was before. Looks like the changes can screw up things pretty good at time and won't display properly for some things. Didn't hurt anything before so we can leave it be till we have a better solution.

Garry, make sure to take a peek at the related bugs... I suspect this is one of those that your earlier/other fixes addressed, and probably most of the others, too (except 244).