besson3c

I forgot to add that if any of you are interested in a beta invite, please contact me through the site or Tweet me @ezdeebee so that we can arrange providing me with an email address I can send your invite code to.

Your help/feedback/testing/suggestions/comments will all be truly appreciated, I’m really looking forward to hearing from you guys!

As a follow up, this was a PITA to have to work through. As was said, I don’t think this was a problem with this widget unless it is responsible for the skipped indexes, so what I’m about to say is not asserting any blame or fault, but damn, serialized data sucks. Stuffing HTML into serialized data is very difficult to work with.

I will rejoice the day that the WordPress team gives up on all of this silly serialized data crap. Maybe their intent is to prevent littering the database with custom tables which might conflict with each other, but working with debugging serialized data parsing is about the least fun I can think of ??

Okay, I came up with a fix for this, for others experiencing this issue…

For some reason the version of WordPress I upgraded to seemed sensitive to skipped widget IDs buried in the serialized data. The indexes are represented by i:2, i:3, etc. I was missing an i:3 and a bunch of other entries, so this was one of the problem – the indexes have to in order without skipping any numbers.

The other problem was that some of the character counts were wrong in some of the longer HTML fields.

The fixes for this were as follows (here are the key lines of programming):

1) grab the serialized data from the database:

$query = mysql_query('SELECT option_value FROM wp_' . $blog_id . '_options WHERE option_name = "widget_black-studio-tinymce"');

2) remove all newlines from the data, otherwise the regular expression matching in step 3 will not work:

$row->option_value = trim(preg_replace('/\s\s+/', ' ', $row->option_value));

3) fix the character counts (you’ll find this regular expression on a number of sites detailing serialized data repair):

$serializeddata = preg_replace('!s:(\d+):"(.*?)";!e',"'s:'.strlen('$2').':\"$2\";'", $row->option_value);

4) there might be better ways to do this, but this works to reorder all of the indexes (i:integer):

preg_match_all('/i:(\d+);/', $serializeddata, $matches);
$i=2;
for ($x=0;$x < (count($matches[0]) - 1);$x++) {
	$serializeddata = str_replace('i:' . $matches[1][$x] . ';', 'i:' . $i . ';', $serializeddata);
	$i++;
}

5) save $serializeddata back to the database

Disregard that, get_option unserializes… I need something more direct.

I’ve been trying to find the right get_option() argument to be able to retrieve this serialized data so that I can attempt the following on it:

maybe_unserialize(preg_replace(‘!s:(\d+):”(.*?)”;!e’,”‘s:’.strlen(‘$2′).’:\”$2\”;'”, $data));

I’m unable to return the data with:

get_option(‘widget_black-studio-tinymce’);

should this work?

Unfortunately, no. I ended up coming up with a system where I used the WP custom headers for uploading banners, and then automatically pulled those images into the wp_bannerize tables.

Anybody?

You got the version with my patches? It works for me…

A slight modification to the latest Domain Mapping plugin was necessary, I’ve sent the authors a pull request for those anxious to get this working in the meantime:

https://github.com/joeauty/wordpress-mu-domain-mapping

Aha, it looks like this was fixed in this commit:

https://github.com/WordPress-Plugins-Themes/wordpress-mu-domain-mapping/commit/9eb2485638080cdf9d509659cd4629a4dbf5e20a

Adding:

Header set Access-Control-Allow-Origin *

To my .htaccess file suppresses the error message above, I’m no longer getting any Javascript console error messages, but I’m also not getting a theme preview at all. Looking at my web server logs I’m seeing the 301 redirects, which makes me think that the Domain Mapping plugin might need some tweaking to not redirect with theme preview requests?

mysqldump has the ability to create insert statements only without creating the database and possibly modifying the schema. WordPress probably recommends using PMA because it is easier to not obliterate the WordPress DB schema.

At any rate, like I said, whether I dump or PMA export, my problem is *not* with getting the data into WordPress. I’ve been doing that for years, I’m cool with that.

Cool, that’s good to know. I usually just use mysqldump because I find it faster, but some of my users in the past have used PMA.

Really? Where is that option? PMA config file?

It’s actually inferior, because last I checked you can’t set a default character set using phpMyAdmin.

Anyway, the issue is not central to my main question…