3.2.1 Visual Editor broken PERSONAL TOPIC

i’ve had no visual editor for months now, hopefully this will point those more knowledgable than I towards a fix.

Kind regards

Dave Rich

We have taken this site apart component by component. We finally renamed the site, reinstalled a new site and began to import into it from the old site. Everything went perfectly. It was when we reconnected with the original database that we we lost the editor again. The problem is in the old wp-options file. We have not gone through it line by line yet, but there is no question but that the import of the old file kills the editor, turning the copy white, removing the tool bar, showing no WySIWIG.

This is what happened when I upgraded to wp 3 in the first place. I had to re-install an older version. Then my server migrated to a different company, different set-up and wp had issued updates to 3. When I upgraded then, everything worked, but I had no idea what had fixed it. That this should happen again with an upgrade to 3.2 is so strange. Why would the editor work under the last 3.1. update, only to quit in 3.2? What thing in the wp-options is being changed in the upgrade, or what conflict is suddenly happening with something in those options?

I’m wondering if you can migrate data base sections a few elements at a time?

Did you have this problem on 3.2 or did you skip it to 3.2.1?

The problem is in the old wp-options file. We have not gone through it line by line yet, but there is no question but that the import of the old file kills the editor, turning the copy white, removing the tool bar, showing no WySIWIG.

You mean the database table? That speaks to a plugin conflict.

Had the problem – now I can’t remember. I skipped. I didn’t upgrade to 3.2 as I recall. I came in at 3.2.1 – I can’t remember now for certain. With the netfirms migration and the rest of the chaos, it’s a mess. But I think my statement is accurate.

But we have found it with NO plug-ins installed (the new install). We’ve removed that file entirely and put it back again – no change. The change before the new install is as I said above: the second we put content into any file in the themes folder, the editor broke.

it’s the wp-options in the database table. Sorry, should have realized more than one wp-options. It’s the old database options. We have to run errands, then will go through that line by line.

The ‘old’ wp_options table could very well still have calls to plugins you’ve removed (a lot store data there), or it could have gotten corrupted. Do let us know what you find!

Okay – home now. Hot out there.
Plug-ins we were running:

Askemet
Facebook Like Box
Wp db backup
subscribe to comments reloaded
finally, wordpress importer, but that was after the fact.

Now going through the database, line by line.

A lot of people have had issues with Facebook like plugins recently.

I just activated all of these plug-ins in my sandbox and so far, the editor has not failed. Meanwhile, my partner here (the code-wiz son who works at Pixar from time to time) is messing with the database. The plug in code in the database wp-options was too specialized for us to catch anything that might have been irregular, so we are porting the values from the old into the new and checking as we go.

The Facebook plug-in doesn’t seem to be bothering the sandbox. It came with the .xml import from the old site. So it all came at once. The editor failed when we introduced WP 3.2.1 on top of the rest of the programming. With the sandbox, Wp 3.2.1 was the fresh install. The import of the .xml came in on top of that.

Okay. We’re exhausted. Ipstenu – I was wrong about the updating. I never did update THIS blog. I’d updated two others successfully. But I’d never tried to do this one. As it turns out, the others would have been find from the beginning. The problem that started with my first upgrade to 3.1 NEVER went away. I just never tried with this blog.

We have gone through the 500 lines of the old database. As I say, many of the lines were too software specific for us to be able to assess the info. So we started taking entries one at a time, looking for essential ones, and porting them into the new data base. On the way, we DID find calls to old plug-ins, like self-feeding blog roll, which had never actually been used. We did NOT port those.

As I said, we found that the problem happened when we exported the old the wp-options table and imported it into the new database. But there were SO MANY lines in it, we couldn’t analyze each line.

We managed to get almost 100 % of my data – entries, settings, links, etc. – without breaking the editor. I am back on line with it. I had to re-populate my twentyten menu, which was not a big deal. And some general settings. Not terrible things.

My conclusion is this: the problem was in the database, in the wp-options. But this blog has been up since 2007. Over that period of time, the basic theme was hacked, other themes auditioned, twentyten tried and hacked, plug-ins were tried, much content generated. I am absolutely SURE that some artifact from all those years must have lingered in the database, and the update to 3 had a conflict with that.

We haven’t found the line, but I’m sure it’s specific to this blog and not a problem with the WP code. Perhaps with 3.1 the code became more sensitive – and so my own site and others like it found themselves with this problem, perhaps caused by any number of tiny database lines conflicting with a stronger, more particular version of the program code. Thus, the proliferation of suggestions for a cure – some working for others, most not.

The only thing I can recommend to others is a quiet, slow, systematic testing of each component of their coding. Ultimately, every blog needs to be backed up regularly – and a totally clean install, generating a new, clean database – then an import – may be the only way of allowing WordPress to operate as it should.

Not much help, I know. But after two days, that is what we learned.

would it be possible for someone to hack tiny MCE and make it less sensitive?

Kind regards

Dave Rich

I haven’t closed this because I’m not finished. IN the course of setting up my new blog(s), I managed to dump my NewMoonFarm blog entirely. I still can’t remember tossing that file – but the point is, the database was still intact. So yesterday, I installed a brand new download of WP manually and connected it to the old database. Which worked beautifully, once I figured out the secret keys biz.

When I got into the dash and found all my posts preserved, I was dancing. THEN I WENT TO THE EDITOR. And the SAME problem hit me: again, no VISUAL editor. Copy in that datafield was, at first, the usual gray, but all html. After a few minutes’ working with it, the font went to white. Just the problem I had upgrading kstreetjournal from – and now I can’t remember – was it 2.8? in the first place. The only fix that worked was going back to the old version. And the problem I just dealt with again, setting up my kstreetjournal blog with an upgrade from that old version to 3.2.1.

As outlined above, in the Kstreetjournal case, we isolated the problem to the wp-options MySQL file. So we replaced it with a fresh one. I had to rebuild the options, and did so by manually importing settings, carefully copying them one line at a time into the new database wp-options. In doing this, we circumvented whatever was in the rest of that file that was conflicting with TinyMCE.

Armed with that, I replaced the same part of the old NewMoonFarm MySQL wp-options with fresher version. Actually, I have to admit that I exported the kstreetjournal MySQL options bit and imported it into NewMoon. Which, of course, taught me a number of things. I re-wrote the basic stuff – the blog name and URL – and was pleased to have everything else just pretty much the way I wanted it.

SO – for me, this is TWICE that the VISUAL EDITOR problem has been solved by replacing an older wp-options section of my database. The interesting thing here is that NewMoon was already running 3.1 – And I’m pretty sure that I had checked the editor, finding no problem with it. So why would that problem show up suddenly when I applied the old database to 3.2.1???

My messing here isn’t methodical enough to draw intelligent conclusions. I mean, the visual editor MIGHT have been working fine – or maybe I just thought it was. I am useless. But again – whatever – changing the options database solved the problem.

just so you know i found a fix. the 123-reg wordpress install app caused the wordpress url in general settings to have an extra colon in it which when removed fixed all this. ??

SO – for me, this is TWICE that the VISUAL EDITOR problem has been solved by replacing an older wp-options section of my database. The interesting thing here is that NewMoon was already running 3.1 – And I’m pretty sure that I had checked the editor, finding no problem with it. So why would that problem show up suddenly when I applied the old database to 3.2.1???

The best guess I can make is that you’ve got a plugin, widget, or theme setting that has gone rogue and is corrupting the table in a way that needs a force kick in the pants.

And here is another problem I had in both cases:

When the new blogs were connected to the old database, in both cases – after the Visual EDITOR problem was solved – I found that many of the posts (but not all – for reasons I fail to fathom) suddenly included ASCII symbols in place of certain punctuation – apostrophes, hyphens, quotation marks. I had to go through NewMoon post by post to find and replace those characters – it’s a small blog, so I could do that.

With Kstreetjournal, which is fairly huge, our strategy was to import the latest back-up – the one we’d made just previous to the upgrade. The import worked, and the blog was almost totally restored. We had only to re-populate the menus and some of the widgets.

I’m hoping I’ve got my ducks in a row now.

Oh – one more thing – and maybe I should start a new topic for this – and maybe I ought to search the forum first – but in the new, manually installed WP set up for NewMoon, when I try to replace the header in either 2010 or 2011, there seems to be no java script for the upload and substitution of a new header.

It all seems to work till the “upload” is finished – then you get a white field instead of a header with a broken image indicator floating in the middle of it. I looked at Kstreetjournal and found the “uploads” file I had remembered seeing the “themes” file – in which all of my custom headers are presently kept. But there was no such file generated in NewMoon when I used the header protocol – none of the uploaded headers can be found anywhere in the theme files.

I’ll search for this later.

You know, pig – I remembered that you’d posted something about that in the middle of all this chaos. And then I never did look. But the second time, I didn’t use an installer. I just moved the files by hand.