phpmyadmin "corrupts" blocks

  • When browsing a table’s contents in phpMyAdmin (say, the wp_options table where global content blocks are stored), one can double-click into a cell to see the complete contents, which are contained in an editable textarea. When one clicks out of this pop-out window, a SQL UPDATE statement is executed, even if (apparently) no changes have been made. This is what I did in the option_value column of several content blocks. I didn’t change anything; I just expanded the contents to view them and then clicked out of the pop-out (did not press Esc), which fired a SQL UPDATE statement affecting that row.

    It seems that doing this corrupts the global content block record, or possibly produces an error reading from the database that the plugin cannot resolve. The block in question will disappear from the WP Admin > Settings > Global Content Blocks list of blocks, and its shortcode stops working.

    I’m baffled about what to do. The gcb_# record is still there in the database, but the plugin is unable to retrieve it, even though all I did was examine its options_value in phpMyAdmin and then click out of the expanded textarea.

    Any thoughts? Many thanks.

    https://www.ads-software.com/plugins/global-content-blocks/

Viewing 2 replies - 1 through 2 (of 2 total)

  • Hello,
    This is quite strange behaviour, as the update should only be triggered by changes done in the field.
    Also, it is not directly related to the plugin, since it looks like more of a phpMyAdmin issue.
    I use the phpMyAdmin tool as well and tested this and cannot replicate the mentioned behaviour.
    Could you maybe get a list of difference between the strings before and after the update ?
    The string itself is a serialized form of a standard object (StdClass) and that means that breaking the string itself might lead to the plugin inability to read the data back again.
    Good luck!

    Thread Starter diekunstderfuge

    (@diekunstderfuge)

    I wonder too about the serialization, so I tried to re-serialize the data by doing something like:

    $global wpdb;
$data = $wpdb->get_var('SELECT option_value FROM wp_options WHERE option_name = \'gcb_#\'');
$updated = update_option('gcb_#', serialize($data));

// Verify.
($updated) ? echo 'Updated!' : echo 'Not updated!';

    GCB class has a method which is just a wrapper for the same update_option() call.

    Here are the string data values for two of the content blocks that stopped being recognized by GCB after the phpMyAdmin action I described in the original post. The first is from “before” the update (I had to grab the values from the copy of the db on my testing server), and the second is from after the update triggered by phpMyAdmin.

    Array
(
    [0] => Array
        (
            [option_name] => gcb_1
            [option_value] => s:400:"a:6:{s:4:"name";s:14:"Mailchimp Form";s:11:"description";s:85:"Basic Mailchimp signup form with only required fields (first name, last name, email).";s:5:"value";s:150:"<aside id=\"mailing-list-block\" class=\"large-4 columns\"><h4>Stay Connected</h4>[mc4wp_form]</aside>

";s:9:"custom_id";s:18:"mailing_list_block";s:4:"type";s:5:"other";s:2:"id";i:1;}";
        )

    [1] => Array
        (
            [option_name] => gcb_3
            [option_value] => s:384:"a:6:{s:4:"name";s:11:"Other Block";s:11:"description";s:0:"";s:5:"value";s:230:"<aside id=\"other-block\" class=\"large-4 columns\">
<h4>Some Other Block</h4>
[contentblock id=newsfeed]
[contentblock id=donation_block]
[contentblock id=socialfeedblock]
</aside>";s:9:"custom_id";s:11:"other_block";s:4:"type";s:5:"other";s:2:"id";i:3;}";
        )

    After:

    Array
(
    [0] => Array
        (
            [option_name] => gcb_1
            [option_value] => s:400:"a:6:{s:4:"name";s:14:"Mailchimp Form";s:11:"description";s:85:"Basic Mailchimp signup form with only required fields (first name, last name, email).";s:5:"value";s:150:"<aside id=\"mailing-list-block\" class=\"large-4 columns\"><h4>Stay Connected</h4>[mc4wp_form]</aside>

";s:9:"custom_id";s:18:"mailing_list_block";s:4:"type";s:5:"other";s:2:"id";i:1;}";
        )

    [1] => Array
        (
            [option_name] => gcb_3
            [option_value] => s:384:"a:6:{s:4:"name";s:11:"Other Block";s:11:"description";s:0:"";s:5:"value";s:230:"<aside id=\"other-block\" class=\"large-4 columns\">
<h4>Some Other Block</h4>
[contentblock id=newsfeed]
[contentblock id=donation_block]
[contentblock id=socialfeedblock]
</aside>";s:9:"custom_id";s:11:"other_block";s:4:"type";s:5:"other";s:2:"id";i:3;}";
        )

    At this point I’m considering uninstalling GCB from my local environment, then reinstalling and importing the “clean” version of the content blocks that I exported from my testing server. Any other thoughts though are greatly appreciated!

Viewing 2 replies - 1 through 2 (of 2 total)
  • The topic ‘phpmyadmin "corrupts" blocks’ is closed to new replies.