Viewing 15 replies - 16 through 30 (of 31 total)
  • I came to the same conclusion as Maltpress. I lean toward option #1…

    – in the instance of a normal post, it should scan single.php
    – in the instance of a normal page, it should scan page.php
    – in the instance of a custom type, it should scan single-customtypename.php

    I’ll probably file a patch in github this weekend

    timpan, I think it’s likely that your custom data is in your database, tied to an earlier revision of your post. If you know anything about databases, you could probably scan the wp_postmeta table and update the post_id to the correct revision.

    Plugin Author Trendwerk

    (@trendwerk)

    @maltpress:

    You’re right, that part is not a server problem. About your workarounds:

    1. This is how the plugin used to do this. Has alot of bugs because of different annotation, custom include functions, etcetera. Not very flexible.
    2. This is not as simple as I would like the plugin to be.

    Another options for this plugin
    Maybe another idea is to save for each template file which blocks are being used (when it’s just displaying a post or page or whatever). When a new page/post/whatever is made, it relies on the previous data to be correct.

    Ways it won’t work:

    • When you assign a new template
    • When you change the blocks on a template and then immediately create a new file without viewing it in the front-end or whatever.

    I thinks this way it could work. And I’d love to hear your opinions.

    @timpan: Can you try deleting ‘mcb-3.0-migration’ in wp_options?

    Hi:

    I absolutely love this plugin but I’m experiencing loss of content too. On two different sites in the last 2 weeks I’ve changed something, updated, and all the content in the blocks for that page disappeared. In one case it was a site that’s been up for a few years; in another it was a site still being developed.

    I’m using 3.5.1 WP, and custom themes. I also get the message on pages wp_remote_get doesn’t work. {Could that be a plugin conflict? I’ve implemented Better WordPress Security on all my sites recently and it has several options that that say “this is known to conflict with some plugins” — generally I don’t implement any of the options with that addendum, but I implement all the rest. )

    Although I’ve been getting the remote_get message the blocks have been working otherwise. I only got worried when content disappeared.

    I have a site under construction that you could go into if you want to try to recreate the problem. (A site where I lost content AND have the remote_get message.) Email directly if you want to take a look.

    Thank you!

    Plugin Author Trendwerk

    (@trendwerk)

    A loss of content really shouldn’t happen. I can only guess when someone is having these problems, so I’d like to have a look. However, I cannot e-mail you directly since I do not have an e-mail address. You can contact me through harold at trendwerk dot nl.

    It might be that the security plugin disables HTTP requests or it just might be your server settings. I’m still looking into that problem since I couldn’t recreate it yet myself.

    I just started trying to resolve this, all sites using the plugin broke during recent upgrades. (I obviously need to update our test scripts). I have tried downgrading WordPress but it didn’t fix the issue. I just installed the latest version (3.0.2) that was just pushed a few hours ago, but it looks like the only difference it the version numbers in the readme.txt.

    So I’ve tried 3.0.1 and 3.0.2 with WordPress 3.5 and 3.5.1 and I am getting the same issues.

    1) Almost all of the time, when editing the post, the Multiple Content Block fields just don’t show up, but sometimes they do.
    2) When they do show up, editing the content in the box and then hitting Update refreshes, but the changes never make it to the custom field, and when the admin page reloads, the MCB fields are missing again.

    Plugin Author Trendwerk

    (@trendwerk)

    @revsystems:

    The change from 3.0.1 to 3.0.2 is only in supporting private post types and fixing a small bug.

    Is your server really slow? Because when it sometimes does and sometimes doesn’t work, it seems that the HTTP requests aren’t making it on time (well, sometimes..).

    I’ve been using MCB on a load of different WP websites and servers and it seems to work at all times.

    Can you try commenting line 89 and 90 and visit the page in the front-end before checking the back-end?

    Commenting out those lines addressed the issue for me.

    As for server speed, the issue is present for me on multiple sites, including in my local development environment which is extremely fast, and on a Linode hosted site which has a way large than needed VM. I don’t think speed is the issue. Everything was working perfectly.

    I did standard WordPress upgrades and didn’t see any issues. When the first client complained, I noticed that the issue existed everywhere. I am on my fifth site applying the fix of commenting out those lines, and it is consistently fixing the issue in development and production, no data loss at all. I will report back if any of the remaining ten sites I am using MCB on have issues.

    Thanks for your help and sorry for the delay getting back to you.

    Plugin Author Trendwerk

    (@trendwerk)

    Thanks for the response. Something is going wrong with the HTTP request, but it’s hard to figure out what exactly. I’ll try to recreate the problem and continue to work on this.

    Hi,

    I like this plugin but I had this issue on only one of my sites. After update, the blocks are still appearing where they should in page templates, but are emptied of content. I restore DB and all is well after that.

    When I have time and new sandbox I will be happy to test.

    Plugin Author Trendwerk

    (@trendwerk)

    Hi Tinozee,

    That’s strange. Did you update from pre-3.0? Maybe you can try removing mcb-3.0-migration from the wp_options table.

    Oh wait, did you restore your old database? Because that probably re-trigger the migration as well (it must have failed before).

    Hope you won’t encouter it again.

    Regards,
    Harold

    Hi,

    I also ran into the ‘Click update and MCB blocks disappear’ issue, but I have tracked the fault down to a different root cause.

    In my case, I was editing my home page template ‘front-page.php’ which had blocks. Viewing the page would recognise the MCB blocks.

    When saving, the blocks disappear.

    On debugging a little, I discovered that your “get_blocks” function loads data from the post permalink. Clearly since my homepage content was currently set as the default blog, my permalink was to the single page for that post.

    Here’s the punchline, my single post template doesn’t have all of my MCB blocks, because they are only needed for the homepage.

    Changing the source content to a static page fixes this for me.

    I would suggest that MCB’s housekeeping is trying to be too helpful – perhaps block deletion should be manual.

    Still though, a great plugin, WordPress wouldn’t be as useful without it.

    Thanks,

    Mark Rabjohn
    Integrated Arts Ltd

    Plugin Author Trendwerk

    (@trendwerk)

    Hi Mark,

    Thanks for your work! I actually really like how the plugin detects stuff automatically.

    In previous versions this was done by actually reading the template files programmatically, but now it visits the page in the front-end and initializes them from there. However, when it’s not possible to programmatically visit this page, errors will occur (which I have not yet reproduced).

    I’ll look into the bug for homepages.

    Regards,
    Harold

    Hi Harold,

    I’m not up to speed on how much a plugin can modify the admin page, but given that MCB sometimes doesn’t “see” the right template, I would suggest something a little less extreme than deletion of the orphaned data or indeed the presence of previously detected block names.

    Clearly removal of the ELSE clause in “save_blocks” would result in a less dangerous scenario, but wouldn’t help with the block names list.

    My suggestion for a future version would be to treat MCB blocks as necessary unless manually deleted (based on the logic that they must have got there somehow) but make the editor on the admin page fold-away to nothing if MCB subsequently detects that the block doesn’t exist.

    The update procedure would then store the data away regardless of whether the block now exists or not.

    Generally, “get_blocks” would have to compile a list of blocks that used to be present but can’t be detected and store that back to the database.

    I think that this approach would be way simpler than accurately determining which template you should be examining. Just an Idea ??

    What do you think? If I ever get any time to look at this I might tackle it myself if you think it’s a reasonable solution.

    Kind Regards,

    Mark Rabjohn
    Integrated Arts Ltd

    Plugin Author Trendwerk

    (@trendwerk)

    I’d like not to have an admin page for this, because that will cause alot of maintenance OR the functionality will be alot less flexible (now each page/post can have their own blocks).

    However, I agree that the current plugin uses quite a dangerous scenario for the blocks. I think having an ‘inactive blocks’ widget where you can see the old content is a great idea (like inactive widgets). First thing on my list for this plugin, so I’ll let you know.

    I would also like to build in caches for the different templates so you will see the right blocks even though they can’t be retrieved automatically at that specific moment (https://www.ads-software.com/support/topic/multiple-content-block-dissapeared-after-update?replies=30#post-3963813).

    Thanks alot for your ideas and work on this!

    Regards,
    Harold

Viewing 15 replies - 16 through 30 (of 31 total)
  • The topic ‘Multiple content block dissapeared after update’ is closed to new replies.