Version 2.0 has previously implemented widget showing as missing

  • I have a site using SiteOrigin Page Builder (just in case it’s limited to this, but it might be all/additional situations where the previous widget was placed), and the previously placed widget on a page is now saying “Missing Widget” (with it then not outputting anything on the webpage where it previously showed the widget) after updating to version 2.0.

    Meanwhile, there’s now a new “Recent Posts Extended” widget that can be placed. Whereas the previous widget was called “Recent Posts Widget Extended” & now shows as missing in the spots it was previously being used.

    Also, there seemed to not really be any time for deprecation/migration regarding this vital change. It kinda just went from working one way with the original widget to needing it to be re-implemented with a different widget with it simply being broken until addressed. There was no time (that I’m aware of) where the new widget was offered alongside the old one so people could transition over (not instantly going from one or the other), and the old widget was never really labelled as deprecated (that I’m aware of) to have people know they should look to use the new widget instead (this part then not really being possible without both being available for a period of time per the previous item I mentioned.)

    I have my sites set to auto-update plugins so it was rather surprising to see this new version effectively break all of the spots I had this widget being used (then assuming this is also happening on any number of the 100+ sites I manage.)

    – Possible Fix/Consideration –
    The first thing I think of is having it so this plugin gets a new version release to address this to help make it so those with automatic plugin updates have time to migrate from the old widget to the new one more gracefully/seamlessly (rather than just finding their existing widget[s] no longer work unless manually addressed after updating this plugin to version 2.0.)

    Here are a couple of approaches to consider:

    1. This could include having it where the old widget is simply still included alongside the new widget/block setup in the new version. The old widget could then have the widget name mention it’s deprecated with the additional widget details mentioning the new widget should be used instead (this then doesn’t break the old setup, lets people know they should move over to the new one, and also serves up the new setup all the same for those implementing this fresh.)
    2. If having the code, CSS, etc. for the old widget alongside the new widget as mentioned in approach #1 is problematic, I wonder if there could be some way where the old widget serves as somewhat of a shim for the new widget. The old widget would still be found for the places it was previously used, but the widget is labeled as deprecated & actually just takes the settings it previously offered & hands them off to the new widget where possible instead of trying to actually use the old widget setup (then denoting any setting that is no longer available per the new widget not offering it, when appropriate, but still showing what that setting was previously set to.) The old widget code & assets don’t actually exist, but it does keep the old widget settings (again, marking ones that aren’t actually doing anything anymore when appropriate [still showing what the setting previously was for reference]) & implementations and simply hands it off to the new widget to then have it show as closely as possible to the previous setup.

    After that, version 3.0 could come out where it has then fully removed the old widget, but not without a good number of months where the people managing sites are able to get things migrated over. This does seem to be a more expected deprecation & migration approach that other plugins do when there’s a potentially major functionality-breaking update to things (go from old setup, have a major release that offers both [or at least doesn’t have the old setup break; ex. a shim for the old setup could be fine] so sites have time to migrate over to the new setup, and then finally have another major release a fair amount of time later to then remove the old setup.)

    There might be other options to consider. The main goal here is to make it so there’s a deprecation/migration period so it doesn’t instantly go from needing one widget to needing a different widget (almost as if this is a whole new plugin or something) with many sites out there wanting to auto-update plugins.

    Definitely feel free to let me know your thoughts/concerns, if I should provide any additional info, and if there’s actually a quick fix for something like this that could be done on my end.

    Thanks,
    Kurt

Viewing 15 replies - 1 through 15 (of 31 total)

  • Version 2 also broke my site with previous posts no longer showing.
    WordPress 6.0.2 running Panoramic theme, Server running PHP version: 7.3.5 with SiteOrigin Widgets Bundle Version 1.42.0.

    https://www.nmbmwcca.org/

    Not sure how to regress the update – will request hosting company restore the site and await fix or migration instructions.

    Plugin Author Ga Satrya

    (@satrya)

    Hi, I am sorry I was not aware of the compatibility with page builder. Give me some time to test it with Siteorigin Page Builder. Meanwhile, you can download the version 1.1.0 https://downloads.www.ads-software.com/plugin/recent-posts-widget-extended.1.1.0.zip then upload the zip file to your website, then use the uploaded version.

    I will get back as soon as possible.

    Thanks! Working again.

    Plugin Author Ga Satrya

    (@satrya)

    To you, who also using Siteorigin Page Builder, please give me times to fix the issue. Meanwhile, I just opened a support post on the Siteorigin Page Builder support https://www.ads-software.com/support/topic/change-widget-class-name-affecting-the-widget-inside-the-builder/, I am waiting for their answer.

    I am so sorry for the inconvenience.

    Regards,
    Ga Satrya

    Thread Starter KZeni

    (@kzeni)

    Okay, so the fact this looks to be isolated to SiteOrigin Page Builder kinda throws out my suggestions. Just wanted to propose some ideas just in case it was more widespread.

    Curious to see what the fix might be for SO Page Builder.

    Plugin Author Ga Satrya

    (@satrya)

    By the way, @kzeni I am sorry I was not answer you, I was too focus on the issue. By the way, there is no new widget/block, it is the same widget with the same functionality and the same code. I was just added support for the block widget.

    But, as I mentioned on the Siteorigin support post, I did change the class name and the file name, this is because I tried to follow WordPress coding standard. Let’s wait for their answer, but my plan B is to bring the ‘old’ widget with the old file name and class name to the new version of this plugin and add the ‘Deprecated’ word as you suggested.

    Thread Starter KZeni

    (@kzeni)

    I appreciate the quick response on the matter ??

    Hopefully, things don’t end up being too complex/involved.

    Hello, I am currently running version 1.0. If I update will any settings change? I like the way everything looks right now, but I am always nervous to update any plugin because sometimes it can cause unforeseen issues. I realize your widget selections may have changed, but I do not plan of making any changes to the way my page looks so I am not concerned about any learning curve associated to update/ changes. Hope that makes sense. BTW, I am on php 7.4 so we should be good there.

    Hi Satrya

    Had the same problem.
    Downloaded the new version and issue solved.

    Thanks for the update.

    I’ve updated the new plugin but only some of the instances seem to of resolved . Others remain missing.

    Thread Starter KZeni

    (@kzeni)

    In a couple of cases above, saying “new version” is a bit confusing as it’s actually a matter of rolling things back to the old version (1.1.0) until there is an actual new version that resolves things.

    @kevinmccourt Did you happen to make any updates to those other widgets (and/or the page/content the widget is included in) once it was using version 2.0 and then roll things back to 1.1.0? I imagine updating things to work with 2.0 and then rolling it back to pre-2.x will have a similar class name disconnect for the widget that we’re seeing when going from 1.x to 2.0… just going in the other direction. I can’t think of anything else that would make it where simply rolling back to the version it was previously working perfectly fine on would have issues present on your site (outside of some caching oddity or something.) It should just go back to working how it previously did, one would think (and definitely not a situation where it’s inconsistent to the point that some are working while others aren’t.) Kinda need more info on what’s going on for your stuff, specifically, as that does seem extra odd & beyond the core issue others are having.

    Plugin Author Ga Satrya

    (@satrya)

    Hello all, I am sorry for late reply.

    There is an update for this issue. The Siteorigin provide a snippet to fix this issue here, I’ll try that and I will let you know where to download the the updated version, so you can test it out.

    Plugin Author Ga Satrya

    (@satrya)

    Hello,
    If you are using Siteorigin page builder, can you help me to try the new version? You can download it here https://github.com/gasatrya/recent-posts-widget-extended/releases/tag/2.0.1

    Please let me know if this version fix the issue.

    Cheers

    Thread Starter KZeni

    (@kzeni)

    Alright! I just installed this as a new version for a site that previously had the “Missing Widget” issue, and it went back to displaying properly!

    No further action was required. I simply updated to this new 2.0.1 version and it went back to working just as it did before.

    Now, I did have some edits made to the page with the widget (and this might be the case even if you didn’t make any edits to the page & simply viewed it to some degree to have it trigger it being “Missing Widget”) so the widget label was still left as “Missing Widget” in SiteOrigin Page Builder for that page, but that can be edited as needed & doesn’t alter the output of the page (it’s a label within the editor). Also, I’m doubtful that there’s a good way to have widgets that were previously affected by this avoid this behavior.

    Tried to install 2.0.1 and received message “Plugin could not be activated because it triggered a fatal error.”

    Warning: require_once(/users/abqzscca/public_html/abqzscca.com/wp-content/plugins/recent-posts-widget-extended/includes//defaults.php): failed to open stream: No such file or directory in /users/abqzscca/public_html/abqzscca.com/wp-content/plugins/recent-posts-widget-extended-2.0.1/rpwe.php on line 31

Fatal error: require_once(): Failed opening required '/users/abqzscca/public_html/abqzscca.com/wp-content/plugins/recent-posts-widget-extended/includes//defaults.php' (include_path='.:/usr/local/lib/php') in /users/abqzscca/public_html/abqzscca.com/wp-content/plugins/recent-posts-widget-extended-2.0.1/rpwe.php on line 31
Viewing 15 replies - 1 through 15 (of 31 total)
  • The topic ‘Version 2.0 has previously implemented widget showing as missing’ is closed to new replies.