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 - 16 through 30 (of 31 total)

  • @kzeni think mine was a caching issue.

    I also tried to install 2.0.1 on another site and received message “Plugin could not be activated because it triggered a fatal error.”

    Plugin Author Ga Satrya

    (@satrya)

    Oh, that’s new, let me check again. Thank you for letting me know about the error.

    Plugin Author Ga Satrya

    (@satrya)

    @abqdanj are you using any cache plugin? please also share your php version.

    Thread Starter KZeni

    (@kzeni)

    I see a new version of 2.0.1 was created on GitHub (added display:inline-block; and some other updates) after the version 2.0.1 I had tested (which had fixed the primary issue with SO Page Builder.)

    I’ve replaced the version on the site I had previously tested with, and that looks to be working, too.

    Going over to the issues encountered by others here…
    I’m definitely curious what the missing file notice that @abqdanj encountered (and might’ve been encountered with @kevinmccourt as well) since it totally worked fine for me (and I’m assuming the plugin dev.)

    Also, the error @abqdanj provided showed it couldn’t open includes/defaults.php when called via the main plugin file even though it effectively has the following code to try and load that file (I removed some extra spacing & unrelated stuff for clarity):

    
define( 'RPWE_CLASSES', plugin_dir_path( __FILE__ ) . 'classes' );
define( 'RPWE_INCLUDES', plugin_dir_path( __FILE__ ) . 'includes' );
require_once RPWE_CLASSES . '/class-image-resizer.php';
require_once RPWE_INCLUDES . '/defaults.php';

    where it should have an issue loading classes/class-image-resizer.php (since it comes before it tries to load includes/defaults.php) if it were an issue with the path (I was curious about it having double slashes in the provided error message) so it seems like the plugin might not have extracted properly upon upload/install or the plugin files that were downloaded were oddly missing something (why else would it not be able to load includes/defaults.php when the file is otherwise very much there in everything I’ve tried [while then also not having this issue myself in the 2 separate iterations of 2.0.1 provided thus far.])

    Also, I’m curious what @kevinmccourt is referring to when it comes to caching being involved. The SO Page Builder issue was very much its own compatibility thing where it needed code to accommodate things (so caching wasn’t the issue) while… what is then the issue encountered with caching that was hinted at?

    Yes, I am using WP Fastest Cache Version 1.0.5 and WP Fastest Cache Premium Version 1.6.5

    I am running PHP version 7.4.24.

    Plugin Author Ga Satrya

    (@satrya)

    @abqdanj @kzeni I am about to push new version 2.0.2, please give it a try. I hope it will fix the double slash issue/the error message.

    Thread Starter KZeni

    (@kzeni)

    @satrya I was mostly aiming to help with someone else’s error output & how it appeared to be some issue extracting/installing the plugin where files appeared to be missing for them. I suppose it is good that the double slashes are no longer there, though!

    That said, I did install 2.0.2 from the GitHub master branch (did a quick swap of the version in the main plugin file so it’s 2.0.1.1 so I can still get the official 2.0.2 when it’s available) and it looks to be working well here.

    @satrya I’m ready to try it on two sites with Page Builder and WP Fastest Cash, but lack the skills of @kzeni to cleverly get it installed. Please let me know when it’s available and I’ll get it installed and tested

    Thanks for your effort on this!

    Thread Starter KZeni

    (@kzeni)

    @abqdanj I would provide what I used, but WP.org support forums frown upon providing direct downloads (especially when not from the plugin dev directly) as that can be a security concern.

    However, here are the steps I took if you wanna take a shot at it (it really isn’t all that bad):

    1. Go to https://github.com/gasatrya/recent-posts-widget-extended
    2. Click on the green “Code” button above the file listing.
    3. Choose “Download ZIP” from that dropdown.
    4. Unzip the the .zip you downloaded.
    5. Rename that folder to no longer have “-master” at the end of it.
    6. (Optionally) Edit rpwe.php in that folder so that “Version” at the top (as part of the main PHP comment block) has “2.0.1.1” instead of “2.0.2” (so you can get the official 2.0.2 release once that’s published)
    7. Zip up that now-renamed folder.
    8. Upload that .zip via the site’s Upload Plugin option in the plugin installer page of the site admin & let it overwrite the existing plugin.

    *You can also just upload the files via (S)FTP or your hosting’s file manager tool instead of zipping it back up & using the plugin uploader in the site admin… the key thing in all of this is that the GitHub download will want to add “-master” at the end of the folder’s name which could throw things off if left intact (might otherwise leave you with two copies of the plugin on your site [if “-master” wasn’t removed from the folder name] since the folder names being different could have WordPress consider it as a different plugin.)

    Of course, you need to be prepared for whatever issue you previously had still being present & being able to address it accordingly as you did last time (fingers crossed that it just works as expected now, of course.)

    Plugin Author Ga Satrya

    (@satrya)

    @abqdanj @kzeni here’s the new update, please download here https://github.com/gasatrya/recent-posts-widget-extended/archive/refs/tags/2.0.2.zip

    There is also a CSS tweak update in this version.

    By the way, please remove the plugin from your website first, then upload this new version. Just in case, you see a conflict error message.

    • This reply was modified 2 years, 1 month ago by Ga Satrya.

    @kzeni Thanks for the detailed instructions. I think I will continue veryfing updates from the author.

    @satrya I installed 2.0.2, but the Plugin could not be activated because it triggered a fatal error with message:

    Fatal error: Cannot redeclare rpwe_get_default_args() (previously declared in /users/abqzscca/public_html/abqzscca.com/wp-content/plugins/recent-posts-widget-extended/includes/functions.php:17) in /users/abqzscca/public_html/abqzscca.com/wp-content/plugins/recent-posts-widget-extended-2.0.2/includes/defaults.php on line 11

    Plugin Author Ga Satrya

    (@satrya)

    @abqdanj you must remove the old plugin from your website first, the error indicate that there are two plugins with the same function.

    @satrya I removed the old plugin and successfully activated 2.0.2, however there is a significant change in behavior with this release. With Version 1.1.0, the recent posts display in nicely in three columns, but with Version 2.0.2 the columns are lost and display inline with slightly larger featured images.

    To see what I’m talking about, I have two similar Page Builder sites with identically configured Recent Posts Widget Extended plugin.

    Version 1.1.0: https://www.nmbmwcca.org/
    Version 2.0.2: https://www.abqzscca.org/

    Please advise. Thanks!

    Thread Starter KZeni

    (@kzeni)

    Just a heads up that this new setup appears to not recall the category checkbox selection when editing the widget.

    I used SiteOrigin Page Builder to add the RPWE widget and have it set to show a specific category. However, going to edit that widget has the categories left as unchecked (rather than remembering the previous category selection[s] and having them set accordingly.) After saving, it then no longer has the category in the query unless any time an edit is made to the widget the categories are re-checked.

    Other aspects seem to remember their settings. It’s just the category checkboxes that always show as nothing checked when editing the widget, it seems.

    Also, it does still show “missing widget” & doesn’t really honor the settings for previously added RPWE widgets (before the 2.0 version overhaul) in SiteOrigin Page Builder until a new widget is added. I suppose that might be something regarding the old method having the settings in a now-incompatible way and adding the widget fresh seems to avoid that issue so the transition isn’t quite seamless (while then having that category checkbox bug which is probably more important & likely has a quicker fix.)

    We’re almost to having this work without issue, but it’s not there yet.

    Thread Starter KZeni

    (@kzeni)

    I’m kinda wondering if the widget settings mismatch (needing to recreate the widget since the old one from before the version 2.0 update just doesn’t save/restore its settings properly) and/or the category (“Limit to Category”) checkboxes not recalling their setting (simply always showing no categories as checked when editing the widget even though one may have been checked previously) is more widespread as a separate issue (potentially affecting more than what came about from the version 2.0 SiteOrigin Page Builder issues.)

    I can provide more details as needed since it does seem like there might be 2 bugs still happening here.

Viewing 15 replies - 16 through 30 (of 31 total)
  • The topic ‘Version 2.0 has previously implemented widget showing as missing’ is closed to new replies.