Dave Liske

Since I haven’t been able to duplicate the issue, I really have no way of knowing. It seems as though the data stream for the block content might be getting corrupted but I really don’t quite know why it’s happening or how far it might go.

Unfortunately the ID isn’t an editable field within the record, and is actually write-protected. It’s auto-generated when you create a new block and isn’t something that can be controlled. This is why I’m building a secondary editable ID field into the new version, one that follows the auto-generated ID but can be changed if necessary when a replacement block has to be created. Building such a thing into the current version isn’t something practical right now, as I’m still determining how to build the migration to the secondary ID into verson 3.0.0. Unfortunately (again, I’m sorry) changing the pages is the only thing that makes sense for now.

Hi Grzegorz, I know there was a similar issue a couple months ago, before I took the plugin over. I was never quite able to solve it. Something to know about how the data is stored is that the ID is actually the data table’s automatically-generated record ID. As the issue always seems to start with ID-1, and the data can still be found in the wp-options table, it’s not an issue I’ve been able to solve yet.

Hving said that, for various reasons (one being a security issue for some users) I’m working on a complete rebuild of the plugin. In the new version there will be a secondary ID field that users can change (with safeguards against duplications, of course). This will allow for recreation of IDs regardless of the record ID (the previous ID will be blocked via the safeguards), and also solve the issue of IDs changing during export/import operations.

There might be performance issues with using names via the IDs, it’s not something I’ve measured. I’d believe they be minimal though as the code snippets for the two types is almost identical.

I apologize for not having a better answer. This is just something that has to be a slightly longer-term solution via the current rebuild.

Hi Grzegorz … I’m adding your solution and a couple other things to the FAQ for the next release. Thanks for the suggestion!

Hi Dean … I’m adding this and a couple other things to the FAQ for the next release. Thanks for the suggestion!

Hi Grzegorz … Line 248 in global-content-blocks.php is the third line in this code:


246: //execute the php code
247: ob_start();
248: $result = eval(" ".$content);
249: $output = ob_get_contents();
250: ob_end_clean();
251:
252: return apply_filters('gcb_block_output', do_shortcode($output . $result));//run the shortcodes as well


The eval function in PHP evaluates a string as PHP code. What it’s doing in this case is evaluating your own code that you placed in the Content Block. Are you possibly declaring image_url() more than once, in separate blocks on a single page?

Dean, I did an update a bit ago to 2.1.5, showing compatability for WP 4.4 and implementing your requested change. Please let me know how that works for you.

Hi Dean, I apologize for the delay in responding, I’ve been laptopless for a couple days … Go ahead and make that change in your version, beginning with line 520 in the Class file:

array(<br />
     "wpautop"	=>	false,//we do not need auto paragraphs<br />
)

This is how the code reads now for the next update, so you’re safe to implement this. The comment in that code has me wondering if this property was set to False at some point.

I’ll tell you what though, the use of TinyMCE in the plugin has always bothered me. I was unaware of the thread you pointed to, having only taken over the plugin a couple months back, and have gotten into the habit of editing in text and then switching to a browser tab displaying the result. Apparently the plugin needs a complete rebuild for security reasons (see Editors cannot edit blocks). Once I get to working on a version 3.0 update to solve that issue, I’m seriously considering removing TinyMCE altogether. There are too many autocorrect issues with it for my liking, so I would add my recommended workflow to the FAQ for use with a simple textarea.

ittws I think I can work this out, maybe maxing out at a dozen or so blocks at a time. I’ll do some tests and hopefully have a solution soon.

Hi hexified … I hadn’t tested this myself, having only recently taken over this plugin. But I’ll be blunt, this isn’t an easy fix. What it’s going to entail is reworking the plugin from the ground up, as it’s built on links to options-general.php. This isn’t really acceptable, but it’s going to be a lot of work, and would end up being the update to version 3.0.0. I’ll plan on doing this, the issue is I don’t know how long it’s going to take. That’s really the best and most open response I have for this problem. Wish I could be of more help at the moment, hopefully I can get it going in a reasonable amount of time.

Hi ittws … That’s something we might be able to try to work out. I imagine the edit area(s) for such a page would only need to be a text area vs TinyMCE, correct? All the other fields would only need to be displayed to identify the blocks. I’ll think on this for a bit and see what comes out.

Thank you for checking it out. Please let me know if there are any other issues.

imagineds thanks for getting Chris Jean involved, I only had one cup of coffee earlier today and never would have found that bug. Happy Thanksgiving.

Hi pwit, version 2.1.4 should be available momentarily. I’ve still been unable to reproduce what you’re seeing, but I’m suspecting the CSS code needs more work, so I’ve removed it for now. Please let me know if this solves your issue.

Chris Jean, many thanks for the assist. It always seems to be the simplest things that can trip one up …

imagineds version 2.1.4 should be available shortly with Chris Jean’s modification included. Again, my apologies.