George Pattichis

Well, adding a simple check on that function before you start hiding essential functionality from the admin is definitely a wise thing to do.

We are talking about a 2-line conditional check:

public function remove_menu_page() {

	if( current_user_can('administrator') ) {
		return;
	}
	
	// Rest of your function
}

If I am my site’s admin I can get any role I want to test how the frontend looks but none of those roles should take precedence over my administration capabilities. That’s the recommended, WordPress way.

Thank you for your time, have a nice day as well.

I am glad you like it! If you have any ideas to improve it or any feature requests feel free to share, thank you!

Hello @nickdesignz,

I am very sorry you are having problems but I am pretty sure there is nothing wrong with the plugin since I’ve tested it thoroughly in several different setups. This not a BETA version.

However, I am very willing to help you resolve your issue if you would share more information about it. What exactly happened when you say “it breaks everything“?

If you could share a link, a test site or even screenshots, we can troubleshoot it, thank you.

• This reply was modified 3 years, 5 months ago by George Pattichis.
• This reply was modified 3 years, 5 months ago by George Pattichis.

Hello @srpatterson,

I’ve just uploaded v2.0.1 and you should be able to (auto)update now.

Thank you for your feedback!

Hello @lroczniewski,

Thank you for reporting this problem.

It should be resolved now. Please uninstall the plugin, re-download it and let me know if this is still an issue on your side. Thanks!

• This reply was modified 3 years, 5 months ago by George Pattichis.

Looks good, you are almost there. Here’s my take, it would not allow the function to fire again, for at least 5 minutes, thus reducing that log of yours tremendously. Also, flushing rewrite rules (permalinks reset) affects all your links so this is not something to check per URL and definitely not something to do every 20s. One transient as a flag would be enough imo:

function do_stuff_on_404(){
    if( is_404() ){
        global $wp;
        $check = get_transient( 'permalinks_flushed_recently' );
        if ( $check === false ) {
            flush_rewrite_rules();
	    set_transient( 'permalinks_flushed_recently', 'yes', 5 * MINUTE_IN_SECONDS );
	    error_log('['.date("F j, Y, g:i a e O").']'.home_url( $wp->request )."\n", 3, "/var/www/html/404-demon-bug.log");
            wp_redirect(home_url( $wp->request ));
            exit;
        }
    }
}
add_action( 'template_redirect', 'do_stuff_on_404' );

If you are having many 404 errors maybe you should look at a plugin like this one to help you keep track of them and hopefully reduce them.

As for the trailing slash missing you would need a redirect fix to always append it to your links. Check this out, it has the snippet for Apache and NGINX.

• This reply was modified 3 years, 6 months ago by George Pattichis.

I am glad you like it! If you have any ideas to improve it or any feature requests feel free to share, thank you!

1. Of course and that would be a smart thing to do. You can get as much info about the incident as possible and, just before the wp_redirect, save it to a text file or email it to yourself.
2. The first person that is about to land to a 404 will not, there will be a permalinks reset and a refresh without him even noticing. Some ms on loading time will be added of course but better than a 404. The template_redirect is what does the trick, it fires before a template is loaded so user does not see all these happening.
3. As I explained we set a cookie to only do this function once. So if a user visits a real 404, a non-existent page, he will go through our quick function and if the 404 status is still there then he will see 404. The function will not run twice because of the cookie check. If we didn’t have this flag, then the user would get locked up in a constant refresh (redirect loop).

Alternatively if you don’t want to rely on cookies you can use transients. Set a transient as soon as you run this function so on refresh it won’t run again. The transient is great for storing temporary data by giving it a custom name and a timeframe after which it will expire and be deleted.

Let us know if it works, thanx!

Hi @zee300,

Finding the actual source of your problem is more complicated than checking your nginx configuration since there could be a lot more rewrites in your WP, especially if you are registering CPTs or custom taxonomies.

However, you could add a workaround and patch your problem in two ways:

• You can add a cron job to reset your permalinks (e.g every 6-8 hours), since you’ve already identified the frequency of the issue to 1-2 days. According to the docs, this is an expensive operation so it should only be used when necessary, so
• You can add a small function that would detect a 404 before the template is loaded, flush rewrite rules and reload. This way you will reset permalinks only when actually needed.

The first patch is quite simple, here’s an untested example for the second solution to get you going:

function wpd_do_stuff_on_404(){
    if( is_404() ){
        global $wp;
        if (!$_COOKIE["rewrite_rules"]) {
            flush_rewrite_rules();
            setcookie('rewrite_rules', 'done', time()+20, '/');
            wp_redirect(home_url( $wp->request ));
            exit;
        }
    }
}
add_action( 'template_redirect', 'wpd_do_stuff_on_404' );

template_redirect would be an appropriate hook for intercepting a 404 before the template is loaded. Setting a cookie acts as a flag, for the case a visitor has landed on a real 404, otherwise we would cause a redirect loop.

Hopes this helps!

Wordpress 5.6 has replaced that select dropdown with a Combobox, where you can now search for the page you want as a Parent.

Lightning fast support too!

Updated, tested and confirm it works. Very much appreciated!

Thank you @wp_media, that’s exactly what I needed. With some small adjustment I can now view the real root of my app and the full file tree to select the exact custom folders. Cheers!

I am having a similar issue, on a multisite WP install with https://roots.io/bedrock/ that has a different file structure. Imagify can not create the backup folder nor it can find the right path so that I can select custom folders to be included in optimizations.

Exactly what I was looking for. Worked like a charm, thank you!

Did you ever find a solution for this? I am having the same issue…