#2231 - Composr 10b2: custom page modules do not render properly

By PDStig
Added 28th Feb 2016, 2:02 AM
2 views

Identifier	#2231
Issue type	Minor issue (breaks specific functionality)
Title	Composr 10b2: custom page modules do not render properly
Status	Completed
Handling member	Chris Graham
Addon	core
Description	When making a custom modification of any modules found in site/pages/modules (perhaps other untested areas as well) and then saving to the site/pages/modules_custom folder, Composr does not properly render the module. ...in the case of warnings.php , it will render the form as HTML inside a string... so essentially instead of a form, you see bare HTML code.
Steps to reproduce	1. Modify site/pages/modules/warnings.php and save into site/pages/modules_custom/warnings.php (you can even just save an exact copy there). 2. Attempt to load warn/punish user screen. 3. You get bare HTML instead of a form.
Additional information	I have confirmed it is indeed an issue with rendering custom modules and not an issue with my code. Case 1: Original warnings.php with no modifications - form works. Case 2: Original warnings.php exists, custom warnings.php also exists - form does NOT work. Case 3: Original warnings.php deleted, custom warnings.php exists in the custom folder - form does NOT work. Case 4: Original warnings.php exists, exact copy made as custom warnings.php - form does NOT work. Case 5: Customized warnings.php exists in the original modules folder; no warnings.php in custom folder - form works!
Funded?	No

The system will post a comment when this issue is modified (e.g., status changes). To be notified of this, click "Enable comment notifications".

Rating

Unrated

Comments

By Guest posted 1st Mar 2016, 2:59 PM

This is the new "kid gloves" XSS security feature. It auto-escapes output components if no skills declaration is made in the override code. I'll take a look at this case and see how we can tune it to make it a bit better.

By Guest posted 1st Mar 2016, 3:33 PM

The issue specifically here was that the fields for the form get turned from Tempcode back to a string, prior to rendering, for performance reasons (carrying through Tempcode object structure for the whole form structure, used too much RAM). This made the system not know the form fields were part of the output assembly rather than based on some kind of possible user input, so they got auto-escaped.

I've now made it track the output of anything that gets internally evaluated, and know never to auto-escape that.