WPBot

Sorry, I’m not trying to be rude or anything, I know it’s a free plugin and I shouldn’t expect anything and I also can’t make you do anything, but you’re joking, right?

If you were using InnoDB everywhere I wouldn’t have been able to install the plugin in the first place (I added it to a brand new site, I still have the pre-2.0 version everywhere else). I said in my first post that I updated to 2.0 only because I’ve been using it in many other sites and a new install and update from older version aren’t too different in this case (at least for me), so sorry for the slightly misleading information, but it still doesn’t change anything related to the problem.
I just looked through src/Tasks/Meta.php and there was no mention of InnoDB in the create_table() function located there (and if there was my topic would’ve been completely different).

What you’re also telling me is that you’re planning on making the plugin unavailable on many shared hosts for no particular reason (considering you’re not using any InnoDB specific code in the events table) and also that the authors of every other plugin out there are completely wrong for not specifying the table engine in their code (even though the engine doesn’t matter in 99% of the cases because they’re not using any engine specific queries)?

Again, I’m not trying to be rude or anything, I’m just saying that not everyone out there has InnoDB enabled in their server config and you shouldn’t force it on people unless you actually use something specific to that engine.

Hello,

If changing that line is enough, then this means that there’s no specific reason for you to use InnoDB.
And if there’s no specific reason to use it – please remove it from the plugin code, so MySQL can create the table with whatever engine is set as the default one just like most other plugins work (your plugin and “WP Mail SMTP” are the only ones I’ve ever had this issue with and over the years I’ve worked on hundreds of different WP installs where InnoDB is not available).

As I’ve already mentioned – I have a lot of sites that use this plugin (most of which still haven’t been updated to 2.0) and editing them all is not exactly the most convenient solution, especially when this engine is not a requirement for the debug logs table to function.

InnoDB might be the default engine but that doesn’t mean that everyone runs their server install with all the defaults. Even many shared hostings have it disabled in order to save RAM.

Thank you!
lyte_parse() applied to the meta field content did the trick.

I have the same problem.
Reverting back to version 9.3 temporarily solved it.

Instead of the proposed check wouldn’t it be better to rename the condition variable to something with a prefix like mbCondition (and other vars later as well)?

That way the chance for a future collision gets significantly lower.

In that specific situation the authors of Slider Revolution aren’t entirely at fault as in my case I have a really old version of their plugin (a few years old), bundled with the theme and this variable has existed since then.
Yes it’s not great that they’ve loaded their scripts everywhere but they’re not the only ones doing so and it’s always a better solution to try and avoid such situations by using prefixes.

Hello,

I’ve managed to find the reason for the blank pages problem.
A plugin, I’ve written some time ago uses the pre_get_posts filter to target tags and categories and ‘nav_menu_item’ was one of post types inside…
That’s what makes your plugin to show blank pages on versions 4.1.8 and 4.1.9, and no menu on versions between 4.1.5 and 4.1.7
Not sure what you’ve changed but this code had no problems with versions 4.1.4 and below of your plugin.
I’ll disable the filter but you might still want to look into the problem as I’m pretty sure that other people might have similar problems with different plugins or themes that use pre_get_posts in combination with ‘nav_menu_item’

As for the other problem I’ve prepared 2 screenshots.
Sorry that they’re slightly edited but as I’ve already mentioned I can’t show the site.

View post on imgur.com

View post on imgur.com

The steps to reproduce the problem are really simple – just upgrade the plugin from version 4.1.4 or below.

I’ve played a bit with the browser’s web inspector and found out that the submenu arrows are located around 20px on the right of the menu and are invisible.

It seems that the menu editing interface has been completely revamped from version 4.1.5 and probably some of the old options haven’t been added or maybe some new options have been added that clash with the old settings.

Just a small update – I’ve changed the active theme to Twenty Fifteen, Twenty Twenty and Twenty Twenty-Two and the problem persisted with all of them, so I’ll guess that the Leaf theme should not be at fault.

I’ve also downgraded to version 4.1.4 – this is the last one that works as expected.
Everything from 4.1.5 until 4.1.7 loads the category pages extremely slow and doesn’t show a mobile menu on them.
4.1.8 and 4.1.9 just show a blank page when I open a category page.

Also on versions above 4.1.4 there are no arrows for the submenus.

To be honest I’m perfectly fine if the Debug Events functionality doesn’t work for me, I just wanted to mention that not everyone uses InnoDB in case you’re planning on moving some of the tables related to the core functionality of the plugin to InnoDB.

Hello,

Personally I’m using MariaDB with MyISAM but I think there are people that use the Aria engine that comes with MariaDB as well.

Hello again and thank you for the reply.

I was able to replicate the problem, we reported it to our developers so we can improve this module.

I’ll be waiting for a fix in that case, and as for the second problem I was in a hurry and didn’t describe it properly.

I was talking about the comments meta box that can be enabled through the “Screen Options” menu while one is editing a post (not sure if that is available in Gutenberg, I’m using the Classic Editor). I’ve created a custom user role and don’t want them to be able to see anything related to comments other than what’s publicly available at the frontend.

Here are the screenshots you asked for:

View post on imgur.com

View post on imgur.com

Turns out that the metabox in question can be easily disabled through a few lines of code (which could be further improved to be executed only for a specific user role):

function remove_comments_meta_boxes() {
    remove_meta_box( 'commentsdiv', 'post', 'normal' );
    remove_meta_box( 'commentsdiv', 'page', 'normal' );
}
add_action( 'admin_init', 'remove_comments_meta_boxes' );

Might be a good idea if you include a module that disables metaboxes in the future versions of the plugin. At least so far that’s the only missing thing I can think of.

Thank you!

Thank you, it was actually my fault… I have no idea where I got this apply_filters from…

The code works now, here’s the final piece in case someone else needs it:

function preload_css( $css_tag ) {
    $preload_css_tag = $css_tag;
    $preload_css_tag = str_replace( 'rel="stylesheet"', 'rel="preload" as="style"', $preload_css_tag );
    $css_tag = $preload_css_tag . $css_tag;

    return $css_tag;
}
add_filters( 'autoptimize_filter_css_bodyreplacementpayload', 'preload_css' );

btw, I’m not sure if this is a known problem or I’ve stumbled onto something new but for some reason AO was adding WPBakery Visual Composer’s CSS to the cache even though the plugin (which came with the theme and I’ve forgotten to disable) wasn’t used on any page or post on the site.

Thank you but for some reason nothing happens when I use this filter.

I’ve tried the following code but nothing is added to the HTML and the error log is always empty (the path to the file is correct and the permissions too).

function preload_css( $css_tag ) {
    $preload_css_tag = $css_tag;
    $preload_css_tag = str_replace( 'rel="stylesheet"', 'rel="preload" as="style"', $preload_css_tag );
    $css_tag = $preload_css_tag . $css_tag;

    error_log("test message to confirm the function works\n", 3, '/var/www/css.log');

    return $css_tag;
}
apply_filters( 'autoptimize_filter_css_bodyreplacementpayload', 'preload_css' );

Sorry, but I’m a bit confused.

I couldn’t find anything about it on Google and managed to find it used in only 4 lines in autoptimizeStyles.php and all of them were in combination with $this->inject_in_html (which I doubt I can use from the theme’s functions.php), so I have no idea how to use it.

Could you give me an example or at least let me know if using it like below is correct and what argument(s) will the function preload_css get?

function preload_css($arguments???){
//link tags get generated here 
}
apply_filters('autoptimize_filter_css_bodyreplacementpayload','preload_css');

I’ve already tried it a few days ago but for some reason the results were actually worse.
The CSS wasn’t render-blocking anymore but FCP and LCP were higher on mobile.

On the other hand when I tried using the “HTTP2 push content” plugin (which also supports preload in <head> but isn’t compatible with AO’s generated files) with disabled AO caching I got better results, so I figured if I preload only 2 or 3 files instead of 15 it might be even better.

I managed to remove the files through this code, but I’m not sure it’s the best possible solution, so I’m still open for alternatives.

add_filter( 'style_loader_src', function($href){

    if( (strpos($href, "frontend.min.css") !== false) || (strpos($href, "hidedefault.min.css") !== false) ) {
        return false;
    }else {
        return $href;
    }

});

add_filter( 'script_loader_src', function($href){
    if(strpos($href, "frontend.min.js") !== false) {
        return false;
    }
    return $href;
});