• Resolved seezee

    (@seezee)


    A recent update to WPSSO breaks the Content Views Pro (CVP) plugin. Since the update, the act of enabling or disabling any plugin while WPSSO is installed changes the order in which all plugins load. This causes CVP to load before Content Views (free version) and stops it working.

    The responsible code is:

    /**
     * Re-sort the active plugins array to load WPSSO Core before its add-ons.
     */
    add_filter( 'pre_update_option_active_plugins', array( $this, 
    'pre_update_active_plugins' ), PHP_INT_MAX, 3 );
    • This topic was modified 4 months, 1 week ago by seezee.

    The page I need help with: [log in to see the link]

Viewing 13 replies - 1 through 13 (of 13 total)
  • Plugin Author JS Morisset

    (@jsmoriss)

    The filter sorts ‘wpsso/’ before ‘wpsso-‘, leaving everything else as-is.

    See the WpssoAdmin::sort_active_plugins() callback for details.

    js.

    Thread Starter seezee

    (@seezee)

    Apparently, it’s doing more than that. Here’s the database entry for the active_plugins option:

    WPSSO disabled.

    WPSSO enabled.

    Plugin Author JS Morisset

    (@jsmoriss)

    You linked images that cannot be viewed.

    I am not denying the issue you observed – I stated what WPSSO does.

    WordPress uses the sort() function before saving the plugin array. WPSSO uses the usort() function to move the wpsso plugin before its add-ons. It does not change the order of any other element in the array.

    Note that both WordPress and WPSSO keep a properly ordered array index by using PHP sorting functions. It is possible to move elements within an array without keeping a correct index order, which may create some unexpected results. It sounds like you may be using a plugin that hooks the ‘pre_update_option_active_plugins’ filter and may be re-ordering the active plugins array without re-indexing it (as the PHP sort functions do).

    See here for the specific code: https://github.com/SurniaUlula/wpsso/blob/master/lib/admin.php#L2666,L2710

    js.

    Plugin Author JS Morisset

    (@jsmoriss)

    If you link the section of code from Content Views Pro that is re-sorting the plugins array, I’m happy to have a look at their code. Meanwhile, I’ve lowered the priority of the active plugins filter in WPSSO (to the default of 10), allowing other plugins to re-sort the array after WPSSO. Hopefully that will fix your Content Views Pro issue. I’ll mark the thread as resolved, but please follow-up if you believe the filter in WPSSO can be improved. It’s a rather simple filter, and usort() is a rather common function to use, so I’m not sure there’s anything to improve, but I’m always open to suggestions. πŸ™‚

    js.

    Thread Starter seezee

    (@seezee)

    Not sure why you can’t see the images. They open just fine for me. Tested in 4 browsers.

    Maybe you can see this one.

    I ran grep -rnw 'plugins' -e 'pre_update_option_active_plugins' and grep -rnw 'themes' -e 'pre_update_option_active_plugins'. The only file to return a result was WPSSO’s admin.php.

    I’ve been testing the problem on a local server with a much smaller number of plugins, new installation, default 2021 theme. The only consistent behavior is that the error occurs only when WPSSO is activated or when it has just been deactivated.

    Thread Starter seezee

    (@seezee)

    JS, CV and CVP don’t resort the plugins array. The slug for CVP is “pt-content-views-pro” so normally it loads after CV (slug = “content-views-query-and-display-post-page”).

    Plugin Author JS Morisset

    (@jsmoriss)

    Error 1011 Ray ID: 5ffa605a9fed13c2 β€’ 2020-12-10 22:24:29 UTC
    Access denied
    What happened?

    The owner of this website (mercury.photo) does not allow hotlinking to that resource (/wp-content/uploads/2020/12/before.jpg).

    • This reply was modified 4 months, 1 week ago by JS Morisset.
    Thread Starter seezee

    (@seezee)

    Hm. Cloudflare. I’ll temporarily disable that.

    FWIW I’m using the latest version of WPSSO you posted today.

    Plugin Author JS Morisset

    (@jsmoriss)

    Since the image you linked, and your site HTML, shows that you are only using the WPSSO Core plugin, and no add-ons, then the input and output arrays would be the same – this is how it works on my test sites – WordPress sorts the array, WPSSO Core filters the array, and the only change to the array is that the ‘wpsso/’ element is moved before any ‘wpsso-‘ element. If there are no add-ons, then the input and output arrays are the same – no change.

    So, why isn’t it working like that on your site? Either your PHP usort() function is broken, or something else is messing with the active plugins array. Using the ‘pre_update_option_active_plugins’ filter is the most efficient way to modify the array, but there are lots of other inefficient ways too. πŸ™‚ You could try looking for something like “egrep ‘update_option.*active_plugins’ plugins/”, which might lead you in the right direction.

    In WPSSO Core v8.17.0-b.3, instead of returning 0 for no match, the filter now uses strcmp(), which emulates the default sort() behavior used by WordPress.

    https://github.com/SurniaUlula/wpsso/blob/master/lib/admin.php#L2712

    js.

    Hi @jsmoriss,
    We’re from Content Views and Content Views Pro.

    Our plugins don’t hook ‘pre_update_option_active_plugins’ and don’t change the option ‘active_plugins’.
    But there are other plugins on the site of @seezee that update the option ‘active_plugins’, so it is possible that the combination of WPSSO and those plugins cause the issue.

    Best regards,

    Plugin Author JS Morisset

    (@jsmoriss)

    @pt-guy Thanks for your feedback. WPSSO Core v8.16.0 would run the ‘pre_update_option_active_plugins’ filter last, and by default would return 0 to usort() if no change in the sort order was required, but although 0 is fine for a correctly indexed array, if the original index numbering has been corrupted, then 0 might create an unpredictable result.

    WPSSO Core v8.17.0 now runs at priority 10 and instead of returning 0 to usort() for no change, WPSSO Core now emulates the default WordPress behavior and sorts the array.

    As a side note – WPSSO Core uses the ‘pre_update_option_active_plugins’ filter to run before its add-ons, which allows it to load two common add-on classes first. Obviously these common classes are included with each add-on, but by having WPSSO Core load them first, prevents older add-ons from loading older common classes.

    @pt-guy This situation may have raised a design issue with your Pro add-on. WordPress uses actions and filters for much of its load process, and when plugins are loaded, they should hook later actions and filters to run all / most of their code (the ‘init’ action, for example, is a popular one to use). And if a plugin has add-ons, it’s a good idea for that plugin to create its own actions and filters that add-ons can hook into, which prevents a chicken-and-egg situation, as we saw here (ie. add-ons simply hook the plugin actions / filters when loaded, and when the main plugin runs those actions / filters, then those add-ons execute, so their load order no longer matters – no more chicken-and-egg situation). πŸ™‚

    To illustrate:

    – WordPress loads an add-on.
    – The add-on hooks the main plugin actions and filters.
    – WordPress loads the main plugin.
    – The main plugin hooks WordPress actions and filters.
    – WordPress runs its actions and filters (that the main plugin hooked).
    – The main plugin runs its own actions and filters (that the add-on hooked).
    – The add-on runs.

    js.

    Thread Starter seezee

    (@seezee)

    I don’t know if it’s because of the latest update to WPSSO (8.17.0) or something else, but the bug has mysteriously gone away on both my local debugging site and my live site. I’ll keep you updated if the bug reappears, but for now, I think it’s sorted.

    Plugin Author JS Morisset

    (@jsmoriss)

    @seezee The bug on your site has not been fixed – the latest version of WPSSO is simply not triggering it since it re-sorts the active plugins array instead of leaving it as-is (ie. with a broken index). You should definitely find the source of that bug and report it to the plugin / theme author.

    js.

Viewing 13 replies - 1 through 13 (of 13 total)
  • You must be logged in to reply to this topic.