Weird saving problem when text contains  

In my (unfinished) newsletter system I have the following code:



As soon as $myMessage contains a ’&nbsp’ (non-breaking-space-character) this code breaks. It does save, but only the part before the  . Is this a XPDO bug?

Schema:

Quote from: jkenters at Oct 08, 2010, 09:30 AM

In my (unfinished) newsletter system I have the following code:

<?php
$queueItem = $this->modx->newObject('nwQueue');
$queueItem->set('newsletter',   $nwl->get('id'));
$queueItem->set('to', 		$subscriber->get('email'));
$queueItem->set('message', 	$myMessage);
$queueItem->set('sent',		0);
$queueItem->save();
?>

As soon as $myMessage contains a ’&nbsp’ (non-breaking-space-character) this code breaks. It does save, but only the part before the  . Is this a XPDO bug?

Schema:

<object class="nwQueue" table="newsletters_queue" extends="xPDOSimpleObject">
        <aggregate alias="Newsletter" class="nwNewsletter" local="newsletter" foreign="id" cardinality="one" owner="foreign" />
        <field key="newsletter" dbtype="int" precision="10" attributes="unsigned" phptype="integer" null="false" default="0" index="index" />
        <field key="to" dbtype="varchar" precision="255" phptype="string" null="false" default="" />
        <field key="message" dbtype="text" phptype="string" null="false" default="" />
	<field key="sent" dbtype="tinyint" precision="1" attributes="unsigned" phptype="integer" null="false" default="0" />
    </object>
[/code[



 

<br />[/quote]<br />I highly doubt it as xPDO is used to save thousands of non-breaking spaces and other HTML entities inside Revolution itself. It must be however you are getting the string to your code; inspect the variable before you call set(’message’, $myMessage)...

Is this using TinyMCE for editing the message? This sounds like something it might be responsible for.

The &nbsp; is in de template (no tinymce there) of the resource. Displays fine on the page (correct source), but when I save the processed html the code breaks. &amp; works, &nbsp; does not. The content of the $myMessage var is equal to the html of the resource. Only the paths and some CSS are fixed for the news letter, but that’s not te cause of the problem.

Guess I found the source of the problem in some of my cleanup code. It seems to be converting to the wrong charset. Maybe this creates some invalid characters I can’t see on my display, but do break the SQL.