Seeing 404 errors after updating to 1.6.3

Those resources are done using WordPress rewrites and no files should exist. I plan on looking into this issue today.

Can you let me know which web server you are using?

Our setup (from back to front) is:

MySQL 5.6.23 (on AWS RDS)
PHP 5.5.9-1ubuntu4.14
NGINX 1.4.6
AWS ELB
CloudFlare CDN

Here is a phpinfo() page: https://staging.yourdailydish.com/debug_info_62351623.php

I have upgraded the AdBlade plugin to 1.6.3 on this same staging server so you can see the 404 errors for yourself:

https://staging.yourdailydish.com/

It might go without saying, but I really appreciate any help you can give me. ??

That is very similar to my setup, with the exception of CloudFare. Is there any setting in that CDN that might cause a problem?

I was able to replicate the issue on my server, but only after I removed a live from my nginx configuration. Did you use https://codex.www.ads-software.com/Nginx#General_WordPress_rules when you initially setup your web server? Specifically, do you have a lines like:

location / {
	try_files $uri $uri/ /index.php?$args;
}

When I removed that from my confiration, I started to get 404 errors too.

My staging environment bypasses the CloudFlare CDN, so the issue is present both with and without the Content Delivery Caching in place.

My url rewrite line in NGINX is currently:

location / {
     try_files $uri $uri/ /index.php?q=$uri&$args;
}

I tried removing the ‘q=$uri&’ portion of the string to match your rewrite rule, but I’m still seeing the same 404 error.

To test some alternatives, I fired up a new EC2 instance and setup an Apache host ( https://ec2-54-210-222-137.compute-1.amazonaws.com/ ). URL Rewrites for “pretty URLs” are working ( https://ec2-54-210-222-137.compute-1.amazonaws.com/spruce-up-your-thanksgiving-snack-table-with-these-fun-danish-pastries/ ), the plugin resources are still 404’ing. I tried swapping from our customized Braxton theme to the Twenty Fourteen theme, same issue.

I guess my last option is to try to install the plugin in a fresh bare-bones install of WP 4.3.1 without any posts, theme or plugins, then add my assets back in 1 by 1.

I guess my last option is to try to install the plugin in a fresh bare-bones install of WP 4.3.1 without any posts, theme or plugins, then add my assets back in 1 by 1.

Let’s hope we can avoid that. I’m still looking into what might be causing this for you even though we have such a similar setup.

Did you, by any chance, try uninstalling the plugin and reinstalling it so the settings refresh? Maybe the rewrite rules are not saved properly. I’d try that without then ‘q=$uri&’ first to see if it works.

Also, turn on the WP_DEBUG flag (https://codex.www.ads-software.com/Debugging_in_WordPress) and let me know if anything from the plugin shows up. Maybe it has some information we can use to find the issue.

If that fails, can you let me know what other plugins you have installed? If you want to move this information off of the support page, I can contact you via the email address on your account.

So I have had some luck debugging. I was able to get things working (with all my plugins activated) on my test Apache box by:

1.) Deactivating & Uninstalling AdBlade 1.6.3
2.) Reinstalling & Activating AdBlade 1.6.3
3.) In the Admin, navigating to Settings -> AdBlade
4.) Check-box “Attempt to bypass ad blockers”

Following the above, things are working as expected in my Apache test environment. It is worth pointing out one quirk here: if I have the AdBlade Plugin activated, but “Attempt to bypass ad blockers” not checked, then I see errors related to:

/module/js/bootstrap.js
/module/js/main.js

When the “Attempt to bypass ad blockers” setting is not checked in the admin, the above resources return a sort of modified category page (HTML content-type instead of the expected JS content). In this case, Chrome then throws the error:

Uncaught SyntaxError: Unexpected token <

Returning to my original setup (Nginx), there was one additional caveat. I have a rule in my Nginx config that causes nginx to throw a 404 versus passing the .js requests through to WP (where the add_rewrite_rule will kick in). In my test environment, I had to remove ‘js’ from the following rewrite rule:

location ~*  \.(jpg|jpeg|png|gif|ico|css|js)$ { expires max; }

I am tempted to remove this rule altogether, but if I do that then 404’s for static files of the above listed types will be passed thru to the main WP controller, which can potentially result in a lot of additional load on my origin (WP obvs uses a lot more resources to generate a 404 compared to a bare-bones Nginx 404 page).

Please reach out to me over email when you have a chance to follow up.

Please reach out to me over email when you have a chance to follow up.

I emailed the address I have on file. Let me know if it is not received.