TinyMCE changing my image code!!!!

Which format is used won't affect how the editor behaves. Unless you're using TinyMCE and WYSIWYG Filter module since it implements hook_wysiwyg_editor_settings_alter(), but that's another story... Full HTML can still render things in strange ways if the filters on it have been changed. But if these odd character replacements actually get saved with the node and show up in the editor when editing it again, it's not a filter issue. Since this happens with all editors you've tried, I doubt it's a problem with them. More likely something happens either when the browser submits the data or when Drupal stores it.

Which exact version combination of modules/editors and browsers can you reproduce this with?

If you insert an image with an editor, click "Disable rich-text", and then submit, are the images rendered properly?does the

I think this is actually a duplicate of #1269440: Form submitting quote changes to slash quotes - possible workaround?. In short, the PHP feature "magic quotes" is enabled, which is not supported by Drupal. See that issue for further details.

That would make sense since the contents would get modified after being submitted by the editor/form, and before being stored in the database. That's why it's only showing up in the editor after a save.

I'm still having this issue with PHP 5.4 which is supposed to have magic quotes disabled. Magic quotes are disabled in the .htaccess as well and in php.ini.

I get this when I save a new node with wysiqyg + tinymce enabled:

<p>lost</p><p><img src="/sites/default/files/styles/large/public/images/news/body/17nm.jpg\" alt="\&quot;\&quot;" width="\&quot;218\&quot;" height="\&quot;174\&quot;" class="\&quot;image-large\&quot;" /></p><p>it</p><p><img src="\&quot;/sites/default/files/styles/large/public/images/news/body/adriana_lima_61200542046pm382.jpg&quot;" alt="" width="238" height="190" class="image-large" /></p><p>already</p>

This seems like slightly different from the magic quotes issue, because:

• Here the " is replaced with " in addition to backslashes being inserted
• Re-saving the node does not multiply the backslashes added as reported in the magic quotes case
• The problem occurs on creation of the node. If you go back and edit it and reinsert the images, then save, the problem no longer occurs.

To conclude, there seems to be a problem not with quotes simply being prefixed by a backslash, but replaced with their HTML escape code, during the creation (and not the editing) of a node.

I can reproduce this issue consistently on my home and hosted Drupal deployment. Please let me know if I can provide further information to help analysis.

Did some further digging. None of the following worked on my Drupal 7.16 test installation:

• Going back from wysiwyg 2.2 to 2.1
• Replacing tinymce version 3.5.7 (2012-09-20) with older version 3.5.4.1 (2012-06-24)

What's peculiar is that wysiwyg 2.1 + tinymce 3.5.4.1 work OK for me on another Drupal installation I have (albeit on Drupal 7.15, which shouldn't have anything to do with it though).

One main difference here is that I'm using the Insert module with "large" style assigned to the default Insert format.

Here's some example output:

Initial HTML prior to being saved (note the file location is not the final one...):

<p><img src="/sites/default/files/styles/large/public/ann3.jpg" alt="" width="243" height="307" class="image-large" /></p><p>&nbsp;</p><p>what?</p><p>&nbsp;</p><p><img src="/sites/default/files/styles/large/public/1259165414-annexhathaway017.jpg" alt="" width="290" height="424" class="image-large" /></p>

Problematic HTML after being saved - note that the files have relocated from their temporary location to their final location (as per the file path stored in the image field):

<p><img src="/sites/default/files/styles/large/public/images/news/body/ann3.jpg\&quot; alt=" width="\&quot;243\&quot;" height="\&quot;307\&quot;" class="\&quot;image-large\&quot;" /></p><p>&nbsp;</p><p>what?</p><p>&nbsp;</p><p><img src="\&quot;/sites/default/files/styles/large/public/images/news/body/1259165414-annexhathaway017.jpg&quot;" alt="" width="290" height="424" class="image-large" /></p>

Finally, when editing the node again, deleting the invalid images and Reinserting them via the Insert module I get the following working code:

<p><img src="/sites/default/files/styles/large/public/images/news/body/ann3.jpg" alt="" width="239" height="302" class="image-large" /></p><p>&nbsp;</p><p>what?</p><p>&nbsp;</p><p><img src="/sites/default/files/styles/large/public/images/news/body/1259165414-annexhathaway017.jpg" alt="" width="304" height="445" class="image-large" /></p>

It appears that something weird is happening when converting image paths from the public root to the actual subfolder in the files directory...

@marktheshark, Does the same thing happen if you click "Disable rich-text" before saving a new node? (Not sure if that's how you extracted the initial HTML you posted, or if you used an inspection tool like Firebug.)

The HTML after being saved, is that what gets rendered to the page, or what it looks like if you're on the node edit form and inspect the editor or click "Disable rich-text"? Just want to make sure I understand exactly when the invalid code shows up.

Are there any errors in the browser's JavaScript console when inserting images or saving the node?

Insert module actually bypasses Wysiwyg and interacts directly with TinyMCE's API, even if Wysiwyg module's abstracted API is available (because of the order in which it checks which editor/module APIs are available).
Therefore I don't think we can do much about this in Wysiwyg if the problem appears at the time the image is inserted.
If it happens when the editor is detached by clicking "Disable rich-text" or submitting the form, maybe the DOM structure inside the editing area has been corrupted somehow, or it gets misinterpreted when serialized.

If you have the Teaser Break module enabled, try disabling it, insert an image in a new node and see if the problem is the same.

Does the same thing happen if you click "Disable rich-text" before saving a new node?

Yes, the same thing happens and yes, this is how I extracted the HTML to post it here. When inspecting the tiny mce box contents with Firebug, the HTML appears to be the same.

The HTML after being saved, is that what gets rendered to the page, or what it looks like if you're on the node edit form and inspect the editor or click "Disable rich-text"?

It's the latter. Now that I grabbed output from another new node via Firebug (after saving) I get:

<div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even" property="content:encoded"><p><img src="http://aiolikos-fans.localhost/sites/default/files/styles/large/public/images/news/body/03d_vikykagiabackstage_10122005cap_5.jpg" width="704" height="490" /></p>
<p>&nbsp;</p>
<p>dfsds</p>
<p>&nbsp;</p>
<p><img src=\"http://aiolikos-fans.localhost/sites/default/files/styles/large/public/images/news/body/d2e_vikykagiabackstage_10122005cap_1.jpg" alt="" width="238" height="165" class="image-large" /></p>
</div>

Perhaps this is the magic quotes problem after all, but the " is inserted by the editor upon editing the node again. Note that the resized dimensions for the first image were completely lost and replaced with the original dimensions (704x490)...

Are there any errors in the browser's JavaScript console when inserting images or saving the node?

"too much recursion", just after ajax is done uploading the images (prior to me inserting them in the body).

If you have the Teaser Break module enabled

I don't have this module.

I'll try again with wysiwyg totally disabled.

Oops, I meant the Teaser Break cross-editor plugin bundled with Wysiwyg. It's known to mess a bit with the markup, especially in IE.

It does look like the editor is having issues parsing existing markup when loading up the WYSIWYG mode. I wonder where the backslash before the quote in the last src attribute comes from...

Since the initial HTML after disabling the editor and before saving the node looks good, could you save a node like that, then either disable the editor by defaul or rename/move the editor library so Wysiwyg can't find it and see if the contents are the same when editing the node again? This should leave you with the original textarea and the markup would be untouched by the editor.

Just trying to rule out that something is happening to the contents either just before it gets saved on the server (Drupal should always save input to the database as it was entered), or just before it's grabbed by the editor.
If it looks ok then, it's likely that any markup problems seen when viewing the node are caused by a broken or misconfigured text filter, since they only run during rendering. But, the fact that the markup also seems corrupted when editing speaks against that.

Oops, I meant the Teaser Break cross-editor plugin bundled with Wysiwyg. It's known to mess a bit with the markup, especially in IE.

I'm at work with no access to my system right now, but I believe I don't have the teaser break plugin enabled. Using latest Firefox by the way.

Since the initial HTML after disabling the editor and before saving the node looks good, could you save a node like that, then either disable the editor by defaul or rename/move the editor library so Wysiwyg can't find it and see if the contents are the same when editing the node again? This should leave you with the original textarea and the markup would be untouched by the editor.

I suspect as well that the inserted backslash is the original issue and that the conversion of quotes to " is a side-effect from re-editing the node with the JS editor enabled.

I will try your suggestion. Do you know which module handles conversion of initial (temp) file paths to their final paths? And why the uploaded files are not immediately copied to their final destination for that matter?

Do you know which module handles conversion of initial (temp) file paths to their final paths? And why the uploaded files are not immediately copied to their final destination for that matter?

I don't know, never seen files being moved after upload before.

To me it looked like it's using the path to a derivative image generated by the core image styles module. So, there's no actual file there until it's needed, at which point it's automatically derived from the original image, still in its own place.
Possibly, that could also override the height/width set by resizing the image in-editor, when it's finally rendered on the viewed node. I have not verified that though.

I just tried with wysiwyg off. It worked... :-S

Initial HTML:

<p>p1</p>
<img src="/sites/default/files/styles/large/public/2005-ultima-gtr-640-open-1600x1200.jpg" width="200" height="150" alt=""  class="image-large" />
<p>p2</p>
<img src="/sites/default/files/styles/large/public/2006-ultima-gtr-qtr_mile_manu-04.jpg" width="40" height="30" alt=""  class="image-large" />
<p>p2</p>

Final HTML:

<p>p1</p>
<img src="/sites/default/files/styles/large/public/images/news/body/2005-ultima-gtr-640-open-1600x1200.jpg" width="200" height="150" alt=""  class="image-large" />
<p>p2</p>
<img src="/sites/default/files/styles/large/public/images/news/body/2006-ultima-gtr-qtr_mile_manu-04.jpg" width="40" height="30" alt=""  class="image-large" />
<p>p2</p>

File paths were updated properly without any impact to quotes in the markup.

For the time being I have instructed the content editors on my site to only insert images on editing a node, not upon creation.

I may try to set up an Eclipse environment for debugging.

In the mean time, if there's any more info I can provide, please let me know, thanks.

Have you made any progress on this? I'm not able to reproduce it locally so it'd be very interesting to see what's going on on your site.

I have instructed the site users to upload images first, save, then edit and add them.

Otherwise the conversion from the initial public path to the final path somehow screws up the markup.

I have yet to overcome this issue.

I'll try to do it again and get back to you.

Without further details about the problem I can only close this issue.
Please do report back if you're able to find out more about what could be going wrong and why URLs are getting mangled, it would be very interesting to hear about it.