Plugin Compatibility: Postman SMTP Mailer/Email Log

[raamdev]

A user reports on WordPress.org an issue between Comet Cache and Postman (he confirmed it was Postman by finding that other sites without Postman installed were not throwing this error):

[13-Nov-2016 00:41:18 UTC] PHP Fatal error: Uncaught Error: Call to a member function get_feed_permastruct() on null in /home/wp-includes/link-template.php:588
Stack trace:
#0 /home/wp-content/plugins/comet-cache/src/includes/classes/FeedUtils.php(68): get_feed_link(‘rss2’)
#1 /home/wp-content/plugins/comet-cache/src/includes/traits/Plugin/WcpFeedUtils.php(55): WebSharks\CometCache\Classes\FeedUtils->feedLinkVariations()
#2 /home/wp-content/plugins/comet-cache/src/includes/traits/Plugin/WcpPostUtils.php(95): WebSharks\CometCache\Classes\Plugin->autoClearXmlFeedsCache(‘blog’)
#3 /home/wp-includes/plugin.php(524): WebSharks\CometCache\Classes\Plugin->autoClearPostCache(734)
#4 /home/wp-includes/post.php(5594): do_action(‘clean_post_cach…’, 734, Object(WP_Post))
#5 /home/wp-includes/post.php(3306): clean_post_cache(Object(WP_Post))
#6 /home/wp-content/plugins/postman-smtp/Postman/Postman-Email-Lo in /home/valuema/example.com/wp-includes/link-template.php on line 588

We need to run some tests to try and reproduce this issue. It seems related to Feed Caching.

[raamdev]

Possibly related to a previously fixed bug that had similar symptoms; see https://github.com/websharks/comet-cache/issues/739

[renzms]

@raamdev

Unable to reproduce error

WordPress Version: 4.6.1 Current WordPress Theme: Twenty Sixteen version 1.3 Theme Author: the WordPress team - https://wordpress.org/ Theme URI: https://wordpress.org/themes/twentysixteen/ Active Plugins: Comet Cache Pro v161119 || Postman SMTP v 1.7.2 PHP Version: 7.0.10-2+deb.sury.org~xenial+1

Please note for Postman SMTP v 1.7.2 Compatible up to: 4.4.5 Last Updated: 9 months ago

Step Taken:

• Installed Comet Cache Pro v161119 || Postman SMTP v 1.7.2
• Enabled Comet Cache Feed Caching (Comet Cache → Plugin Options → Feeds Caching, choose Yes to enable)
• Configured Postman SMTP settings and test email
• Create a cache and then clear it

No error was produced. Possible conflict may be with another plugin/theme file.

[raamdev]

@renzms writes...

Create a cache and then clear it

Did you cache an RSS feed?

[raamdev]

@jaswsinc Looking at the error log above, are you seeing anything that might be a bug with Comet Cache that needs further investigation?

[jaswrks]

Just beginning research on this...

Call to a member function get_feed_permastruct() on null

Appears this can happen as a result of calling get_feed_link() too early; i.e., before $wp_rewrite is set, as seen here: https://github.com/WordPress/WordPress/blob/33b8bb3cf32718248d193e3831d6bfd61b527f75/wp-includes/link-template.php#L590

[jaswrks]

are you seeing anything that might be a bug with Comet Cache

Yes. It seems we need to take a closer look at hook priorities in Comet Cache following a recent change where we started using plugins_loaded here instead of after_setup_theme.

[jaswrks]

@raamdev Do you remember why we moved to plugins_loaded?

[raamdev]

@jaswsinc See https://github.com/websharks/comet-cache-pro/commit/d2dd26d30963972cf68d67617931de191b4977d3

[raamdev]

See also the associated GitHub issue: https://github.com/websharks/comet-cache/issues/716

[jaswrks]

I see. Thanks! :-)

Looks like we'll need to move back to after_setup_theme. I can see now that many API calls in Comet Cache are likely to depend on $wp_rewrite, and the first hook that is available after $wp_rewrite is set, is setup_theme. Next, there is after_setup_theme, which comes after templating constants. Those are also important. In short, plugins_loaded is too early for the full instantiation of Comet Cache. My bad for agreeing to this before. Just didn't think about it from this angle.

Solution

Move to after_setup_theme

[raamdev]

@jaswsinc writes...

Looks like we'll need to move back to after_setup_theme.

Not an option right now, at least not without further research and probably a workaround for #716. Issue https://github.com/websharks/comet-cache/issues/716 specifically fixed an issue that Autoptimize (200k+ active installs) was having using the Comet Cache API... see this W.org forum thread where @futtta reported the issue.

[raamdev]

@jaswsinc At the very least, I think we need to consider the repercussions of another plugin assuming that the Comet Cache API is ready to be used after plugins_loaded, as that seems like an obvious assumption to make. @futtta discovered a while back that such an assumption generated fatal errors. If we move back to after_setup_theme, what can we do to prevent fatal errors when another plugin, or a site owner, tries to use the Comet Cache API after plugins_loaded?

[jaswrks]

The Comet Cache plugin API should not be called upon until wp_loaded. That's typical for most WordPress plugin APIs. Otherwise, if you call API methods earlier than wp_loaded, you risk doing things before the plugin (or others it depends on) are loaded and fully initialized.

To improve this, what we could do is load the API earlier than everything else so it's available on plugins_loaded (as it already is now), but then create our own flavor of _doing_it_wrong() to notify developers that they are doing it wrong when they make calls too early.

In addition, we could automatically defer the action itself until Comet Cache is ready. For example, if you call comet_cache::clear(), and you've called it too early, we can produce a debug warning, but then defer the action and process it on wp_loaded as it should have been done.

Do you see any problems with this?

[raamdev]

Do you see any problems with this?

I don't see any problems with that. Creating our own flavor of _doing_it_wrong() and deferring actions automatically sounds great to me.