TinyMCE Visual/HTML toggle doesn't work on WP3.1 Magic Fields 1.5.3

I have the same problems that @figureone, specially that it cleans all line breaks of the text… :\

Well at least for me, while commenting out line 1198 might sometimes fix data loss if you don’t click the Visual/HTML buttons, when if I go back and edit the same post/etc again, the act of going back and loading that post automatically triggers the loss of paragraphs and linebreaks again.

These disappearing line breaks are killing me (like on this page, for instance). Anyone who can come up with a solution will have my heartfelt thanks.

i just gave Britney 1 star because of that wall of text!

I also gave 1 star to Britney…
Who would have thought it? xD

Ok, so I fixed this problem. In short, it was caused by orphaned field entries in the wp_mf_panel_custom_field table. If you delete the orphaned entries (be careful!), the Visual/HTML buttons will once again work properly.

If you’re interested in the details:
Basically, since I have a WP Multisite setup, I initially was creating write panels and fields for each site, before I realized that Magic Fields currently has a set of write panels that are shared across all sites (I believe this is a bug that’s on the developers’ list). When I realized I was duplicating write panels, I deleted the extra panels, but somehow the fields I had created got left in wp_mf_panel_custom_field. So I ended up with several custom fields that had the duplicate names in wp_mf_panel_custom_field. This, in turn, was causing the bug with TinyMCE and the Visual/HTML buttons–basically, because there were multiple custom field entries in the database with the same name, when I went to edit one of those fields on a page, multiple spans would be created that contained the TinyMCE iframe (the span ids were based on the custom field name, like so: magicfields_FIELDNAME_1_1_parent). So the TinyMCE javascript code to switch between the HTML view (textarea) and Visual view (TinyMCE iframe) was showing/hiding only one of these spans, and the other one was staying visible on top and blocking the HTML view from ever showing.

So, if you are having this problem and want to fix it, you’ll have to jump into your database and delete some table rows by hand. This is dangerous, so only do this if you are comfortable doing so!

First make a list of the custom fields that are in use (not orphaned):
* In the WordPress dashboard, go to the Magic Fields Write Panels page: /wp-admin/admin.php?page=MagicFieldsMenu
* For each of your write panels, click on Edit Fields/Groups
* For every “Group Name / Field Label,” hover over the link and look at the custom-field-id querystring variable
* Keep track of all these IDs.

Now, in your favorite database editor/view (I use phpmyadmin for MySQL):
* Open up your WordPress database and browse the wp_mf_panel_custom_field table
* The “id” column contains the custom-field-ids that you recorded earlier. If you see IDs that aren’t in the list you made, they are orphaned. If they have the same “name” as ones that aren’t orphaned, it will cause the problem outlined in this thread.
* At this point, if you’re comfortable, delete the rows that contain the orphaned fields. I’d strongly suggest first backing up your database, or at least recording the info for the rows you are deleting so you can restore them if you did something wrong.

Good luck!

Thanks for the thorough writeup, figureone. It doesn’t look like that’s a universal fix, though – the DB for the site we’re having problems on has no dupes. (It’s also not a multisite, but I checked anyway just in case.)

@hotgluemedia, are there any repeated names in the wp_mf_panel_custom_field table?
Even if you’re not running multisite, and even if none of the fields are orphaned, if two have the same name then there will be collision (I think).

Nope – everything’s unique. ??

I haven’t been able to narrow it down any further than my original post –

Every once in a while, but not all the time, the content in a multi-line widget will not save unless the “HTML” button is toggled. When this happens, even though the “HTML” button is toggled, the content is still shown as if it were using the visual editor.

I’ve been able to replicate the issue in several browsers (Chrome 9, FF 3.6, and IE8) and on pages with multiple multi-line MFs and single-line MFs, with different types of content. There doesn’t appear to be any way to determine when the issue will happen.

Yes – I rolled back the patch. Since this is happening on a live (and heavily-used) client site, the missing media buttons was unacceptable, so we immediately rolled it back. For now, I just have them always clicking the HTML button.

Thanks for the offer – I’ll get that sent over to you today. ??

Alas, I also had no orphaned fields in my wp_mf_panel_custom_field table. Two of my fields in different custom panels had the same name, so I adjusted them to be different. Unfortunately, I still have the same problem with linebreaks and paragraphs being removed.

For me, this happens every single time I load a post that previously had content containing <p> or <br>. The post will save with the line/paragraph breaks but upon loading the post again for editing, the tags are removed.

Ok, 2 issues here:

1) Visual/HTML toggle buttons don’t work on some magic fields.
2) TinyMCE is stripping out paragraph and break tags.

The 1st issue is unresolved (still looking into it, @hotgluemedia).

For the 2nd issue, two questions for @autumnmist:
* Does this problem only happen to magic field write panels, or does it also happen to the page’s main editable content area (the TinyMCE panel at the top of the edit page)?
* Do you have any other TinyMCE-related plugins installed? I have the TinyMCE Advanced plugin installed, and it has an option to “Stop removing the p and br tags when saving and show them in the HTML editor.” It works well for me.

All my Magic Field custom panels are set to hide the main editable content area, so I’m not sure if it happens only to the main content area. However certainly the other parts of my site (regular non-MF posts and pages) don’t have problems with the stripping of paragraphs and break tags.

I don’t have any other TinyMCE plugins installed.

@autumnmist, did you apply the temporary fix @hunk suggested at the top of this thread (commenting out the tinymce init line)? When I did that, I had problems with p and br tags.

I tried it and then undid it and I still have problems with p and br tags no matter whether it’s commented out or not.