kbarncat

Dave is better than pig, huh? Here’s what I meant: when you write an address this way, /newmoonfarm/, in code, it’s shorthand. It means that what comes before the first slash describes the address of the file in which this address is written. Like, “https://www.ponymoon.com/(then would come the newmoonfarm part). Because of the nested position of the address code, you don’t need to write out the first part; the computer reads that as a given.

I’m not explaining this well. And frankly, I’m not that educated about all this and could be explaining incorrectly.

But what I’m saying is that the same coding flaw that stuck the colon after your .com in the wordpress address in general settings could have been sticking that colon there without my ever seeing because I had written the address in the shorthand. When I wrote the address out from the ground up, I – of course – did not stick in that colon, thus the address was correct and TinyMCE wasn’t interfered with.

And what I’m writing about here is my experience messing with the MySQL database that is the core of the blog functionality. When you use the General Settings interface, filling in the blanks there, you are actually making entries into that database, into the wp-options table. I don’t recommend playing with the database, because you can make mistakes you will never know how to fix – but once you realize that relationship between the blog dashboard interface and the functionality of the database, it’s kind of fun to be able to see all those options at once.

Anyway – that’s why I said that my problem might be the same problem you were talking about – because I was changing the cell that held the exact info the install program would have entered into the general settings if I’d been setting up a new blog – in the wordpress address cell – and using that shorthand that offered it the opportunity to stick in that colon without my knowing it.

This may not be the actual explanation. All I actually know is that when I entered the shorthand – which I did several times, alternating with the whole address to test the effect the two means of entry had on the functionality of the visual editor, every time I entered the shorthand, I lost the editor. And every time I entered the full address, the editor came back. Wish I’d known this months ago – would have saved me no end of hours of grief.

Now, if I can just figure out why the “return” in the visual editor when you use it after an image, sticks in that weird bit of non-breaking space code – and why, in just one of my blogs, the header upload protocol isn’t working.

Wow. Please accept my apologies for any impatience I’ve felt in the past – I can’t believe how many issues have gone up in the last hour.

I need to add here that my son’s 3.2.1 site also has this return problem. The return simply doesn’t function correctly after an image.

Okay. Okay. I’ve found something substantial. I’m having a couple of niggly problems that i listed above, and I started a new topic on the return/non-breaking space code. So I’m still messing around to try to understand all this.

In the course of this, I went back to the MySQL, trying to figure out why the header upload isn’t working – to see if there was some setting that could explain why. I looked at the old NewMoon MySQL wp- options, compared them to the new one (the one that had solved the problem) and found some discrepancies. Thinking these might be messing up the upload path – (admin email address was different than the admin email address in SQL wp-users, wordpress address name in old was truncated to /name/, and I had put the entire address – http: etc – into the new options table. And the site address was slightly different. So I changed the new entries to match the old, thinking the upload path might have something to do with it.

Went back to the blog – and – the VISUAL EDITOR was broken again. So I went back to the table and began to change those same entries back to what they had been, one at a time. The email addresses made no difference. In the end, it was the WORDPRESS ADDRESS entry that was affecting the visual editor.

When I entered the entire address, the editor worked. When I truncated the address, (allowing the program to fill in the rest), the editor broke.

Is this exactly what higltypig was talking about? Because it sounds exactly like it to me.

But it doesn’t explain the header problem.

It’s what I live for – having problems nobody’s ever heard of before.

Ipstenu –

Well, okay. This is worrisome – because I still have the plug-ins – and widgets. Now, I’m running a legitimate child (as opposed to the hacks I had done before – but only on the kstreet blog, not on the newmoonfarm one (new moon NOT as in vampire literature) for twenty ten. But I’ve changed all the same parameters, in all the same ways – so am I set up for a crash now everytime I upgrade, I wonder?

I am the poster child for BACKING UP more than periodically.

But the two blogs really had nothing in common – different themes. One hacked. One not. And I didn’t even use widgets till lately – I just sort of, ummm, inserted stuff. Only the plug-ins were alike, and they were just Askemet, wp-database-backup (which evidently works great), and maybe one other – but none of them extreme or unusual or ambitious.

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.

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.

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.

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.

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 – 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.

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.

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?

May I say again that I tried all the little tricks to no avail. When my hosting service moved to a whole new server array (and by that time, WordPress had gone 3.1.1) everything worked. So it may be that you can try everything under the sun, and you’ve got a server problem. Just sayin’ – so that you won’t eventually think you’re losing your mind.

rescogitans – I fought this across about eight of these forum threads – and got in trouble for it, even though I didn’t start the darn things. In the end, as I posted above, even though I tried every fix and even though I sounded like I must just be inept, the problem was with my host, not with the edits I’d done to my theme, or my permissions. Once I changed hosts, everything worked again. Now, I didn’t try again after I went back to WP 2.0 – because everything was working fine, and I couldn’t afford any more anxiety and frustration. So it may be that 3.1.1 could have cleared things up. All I know is that now it works, and I didn’t do a thing to make it work. After all those hours of messing with it. So it may be something beyond your control – try changing hosts and look for somebody good.