Forums

I'm seeing the problem described earlier here:
http://www.chronoengine.com/forums/index.php?option=com_chronoforums&cont=posts&f=17&t=12151&start=0&hilit=dollar+sign

I think this was fixed in the older version, but I'm seeing it in the latest V4 RC 2.0.

Here's how to reproduce:

Create a form
Add a text area
Add a submit
Add a db save
In the area, enter some text and include something with a dollar sign followed by 2 digits. For example $10. This problem doesn't happen with alpha chars, only digits.
Submit the form (so it saves to the database)

At this point, look at the data in the database. It's still there and appears correctly.

Load the form information (using another form that loads in the db row via the token).

If you enable debugging you'll see that the field still has the correct information - but the $10 is missing from the text in the text area. If you entered 3 digits, then the last one will still be there. For example $100 -> 0.

Now if you save the form again then the $10 will be missing from the database as well.

See the screenshot and look for the Quote data.

Hi lowrykun,

This may be happening because the code is being evaluated as PHP at some point (and PHP thinks $ signs denote variables) :-(

Try pre-processing the result to replace the $ with the equivalent HTML entity. That should be preserved better.

Bob

I've tried that already. It works until the form is reopened. Then the HTML entity is rendered as dollar sign and then when it's saved again then the problem reoccurs.

It's definitely being read by PHP at some point. There's a piece of code that's looking for a two-digit variable. Probably a $$var (PHP Double Dollar Sign variable).

Hi lowrykun,

I think I have a fix for this. Open components/com_chronoforms/libraries/includes/data_republish.php and find this code block around line 125 and insert the marked line. This should escape any occurrences of $0 - $9 in the text area and stop the preg-replace swallowing them.

		//textarea fields
		$pattern_textarea = '/<textarea([^>]*?)>(.*?)<\/textarea>/is';
		$matches = array();

		preg_match_all($pattern_textarea, $html_code, $matches);
		$namematch = '';
		foreach ( $matches[0] as $match ) {
			$pattern_value = '/value=("|\')(.*?)("|\')/i';
			$pattern_name = '/name=("|\')(.*?)("|\')/i';
			preg_match($pattern_name, $match, $matches_name);
			$field_value = $this->fieldValue($matches_name[2], $data);
			if(!in_array($matches_name[2], $skippedarray) && !empty($field_value)){
				$pattern_textarea2 = '/(<textarea(.*?)>)(.*?)(<\/textarea>)/is';
				// :: START FIX :: insert the following line
				$field_value = preg_replace('/\$(\d)/', '\\\$$1', $field_value);
				// :: END FIX :: 
				$newtextarea_match = preg_replace($pattern_textarea2, '${1}'.$field_value.'${4}', $match);
				$html_code = str_replace($match, $newtextarea_match, $html_code);
			}
		}

Bob

Thanks for the fix. I tested it and it worked great.

Just FYI for anyone else that had this problem... On the front end, when you read this back out to display then you may also have to escape it - for example in a Joomla Module.

Something like this in the module php file:

$content = modModuleNameHelper::getContent($params); //Module Class and Function
$content = preg_replace('/\$(\d)/', '$$1', $content); //Change the dollar to an HTML entity
require JModuleHelper::getLayoutPath('mod_modulename'); //call the tmpl/default.php for rendering the module