jarad.secco

I believe the above warnings are non-fatal (they won’t crash the page render), and as such can just be ignored. Hopefully in the future the author(s) of the plugin will put in an is_null() check before the loadHTML() call to stop the warnings from being thrown.

In the case of the 5XX server-side errors we were seeing at the time, we came to the conclusion that they were coming from a memory limit. PHP was set to a 128M limit, and in some cases certain pages were exceeding that limit (at which point they would die and throw a 500 error). The fix for that issue was to increase the value of memory_limit in the php.ini configuration file. If you are seeing 500 errors client-side, I suggest you dig deeper into your error logs to see if there are other errors (and not just warnings) buried in there.

• This reply was modified 8 years, 4 months ago by jarad.secco.

In case anyone is experiencing the same issue, as a work around I was able to add the following rewrite rule to my theme’s functions.php file to get pagination working for gallery URLs ending in /1/ :

function gallery_cpt_custom_rewrite_rule() {
        add_rewrite_rule('^galleries/([^/]*)/([^/]*)/?','index.php?gallery=$matches[1]&gal_page=$matches[2]','top');
        flush_rewrite_rules();
}
add_action('init', 'gallery_cpt_custom_rewrite_rule', 10, 0);

The above rewrite rule will stop WP from automatically dropping the trailing /1/ from the URL. Then in the gallery template file, I am able to access the gallery name and page number using $_GET[“gallery”] & $_GET[“gal_page”] params.

Thanks for the quick follow up. Which feature specifically are you adding support for? The ability to auto-publish posts in a given category or external access to a custom function within your plugin to allow programmatic Publishing to Apple News within a theme’s functions.php file?

And I guess the next question would be, do you have an ETA for 1.0.9? ?? Thnx again.

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.

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.

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. ??