Forum Replies Created

Viewing 15 replies - 1 through 15 (of 228 total)
  • Thread Starter Roy Tanck

    (@roytanck)

    Hi @mnttech . Thank you looking into this. I checked, and the WP Opcache page is not displayed anywhere in the network admin nor in the main site’s admin section.

    To get it to show, I think the call to ‘add_management_page’ in ‘class-flush-opcache-admin.php’ (line 62 to 68) should be replaced with something like this:

    add_menu_page(
    __( 'WP Opcache', 'flush-opcache' ),
    __( 'WP OPcache', 'flush-opcache' ),
    'manage_options',
    'flush-opcache',
    array( $this, 'flush_opcache_admin_page' ),
    'dashicons-admin-tools',
    21
    );

    This will create a top level menu in the network admin, since there is no tools menu there. You could also use ‘add_submenu_page’ to put it under one of the existing menu items, but I’m not sure which would be the best fit. In my testing, the snippet above worked well.

    Hope this helps.

    Plugin Contributor Roy Tanck

    (@roytanck)

    @rainer-r Sorry this is taking so long. I’ve created a Github issue to create a workaround for this issue. Plugin Report should not stop working when one of its AJAX calls fails due to a PHP fatal error. I’m not sure when I’ll be able to work on this though.

    The PHP error in this case is caused by another plugin, and in fact by 3rd party code in that plugin. There’s nothing I can do to prevent this from happening.

    Plugin Contributor Roy Tanck

    (@roytanck)

    Hi @rainer-r I’ve been trying to reproduce the issue, but both OMGF and OMGF Pro show up just fine in Plugin Report on my development machine. Could you perhaps see if there’s anything interesting in your site’s error logs (and if so post that here)?

    And how about your browser’s dev tools? Anything in the console and/or network tab?

    Plugin Contributor Roy Tanck

    (@roytanck)

    I’ve just released version 1.3.4 which adds the hook (and is properly tested with WP 1.3.4). Thanks for the suggestion!

    As for the login screen, I’m wondering whether that should be optional (which would require adding settings to the plugin), and I want to investigate different ways that could be displayed. Definitely something I’ll consider for a future version.

    Plugin Contributor Roy Tanck

    (@roytanck)

    I think I agree that adding the hook would increase the plugin’s flexibility. I’ll add it in the next release.

    Thanks for suggesting a notice on the login screen. I’ll definitely look into that.

    Plugin Contributor Roy Tanck

    (@roytanck)

    Hi Rainer. Is it possible for you to temporarily disable OMGF Pro, and then check if Plugin Report works as intended? Since this is a pro plugin, I do not have it available for testing. Obviously, you can reactivate OMGF Pro immediately after testing.

    Plugin Contributor Roy Tanck

    (@roytanck)

    Hi Rainer. I’ve not been able to update the compatibility info for this plugin, but I have used it successfully on 6.7.1.

    I’d guess the issue you’re experiencing has something to do with either plugin number 18 or 19. Can you please post which plugin is the last to be properly displayed, and which is the first(?) to fail? I’ll install them on my test environment and see if the same thing happens to me.

    Plugin Contributor Roy Tanck

    (@roytanck)

    Thank you for your suggestion. Support for custom environment types was explicitly removed in WP 5.5.1: https://make.ww.wp.xz.cn/core/2020/08/27/wordpress-environment-types/ . It appears that your code relies on the $env_type parameter being set to something other than the four officially allowed values? That could be problematic, considering that WP (according to the blog post) resets any other values to production.

    Hmm, this appears to be a little more complicated than I originally thought. I set up a brand new site, just WP 6.7 and Query Monitor. I set it to a non-default language and enabled WP_DEBUG, but got no errors.

    The dev site I initially noticed this happening on had another plugin (Gravity Perks) active that caused the same error message. When I disabled that plugin, it also stopped the Query Monitor error being logged. So it could be that the error is somehow triggered by another plugin loading translations too early?

    When the error does occur, I’m not getting a stack trace.

    I’m seeing these error on every page view on my development machine where Query Monitor 3.16.4 is active. This appears to be related to this: https://make.ww.wp.xz.cn/core/2024/10/21/i18n-improvements-6-7/ . That post, somewhat ironically, mentions Query Monitor as a tool to troubleshoot this :).

    Forum: Plugins
    In reply to: [WP-MQTT] Broken
    Plugin Author Roy Tanck

    (@roytanck)

    Thank you for reporting this. WP-MQTT has not been maintained for years, and was never tested with current versions of both PHP and WordPress.

    It is still available here in case someone wants to fork it or take over active development.

    Thread Starter Roy Tanck

    (@roytanck)

    Thanks for your answer. It might be complicated to determine what options are “content” in the case of this block. Making cell contents red, or adding an outline, could be seen as a way to mark them as more important, and that is a “content decision”. But that same option allows editors to create tables with all colors of the rainbow, which is what I’m trying to avoid.

    That being said, I quite like the idea of a “content-only” lock type, and I think it would help in my case.

    Plugin Contributor Roy Tanck

    (@roytanck)

    Thanks for posting the wp-config setting. That looks 100% okay to me. Since I’m unable to reproduce the error, I propose we see if the WPForms people have more luck. If not, I’ll look into this some more.

    Plugin Contributor Roy Tanck

    (@roytanck)

    Can you please check what the value of the WP_ENVIRONMENT_TYPE constant in your site’s wp-config.php is?

    There are only four possible values, and anything else will make it default to ‘production’, which could maybe explain what is happening.

    https://developer.ww.wp.xz.cn/reference/functions/wp_get_environment_type/

    If things are set up correctly on the sever, there also shouldn’t be a WP_ENVIRONMENT_TYPES (plural) constant, since that is no longer supported.

    Plugin Contributor Roy Tanck

    (@roytanck)

    I’ll try to look into this in more detail later this week. Have you reported this issue to WPForms as well? While the error manifests in my plugin’s output, I think their plugin introduces it.

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