mslade

Yes – thank you.

Oh okay, thanks a lot. I’ll see about sending in a patch to them, although seeing your 14 month old patch with no updates doesn’t bode well for me ??

Unfortunately, the $post global is not available during cron publishing, either. It’s null. In fact, get_the_ID() uses get_post() and get_post() relies on the $post global, so any time get_the_ID() doesn’t work then the $post global will not work, either.

Are you a maintainer? If I submitted a patch to add the post context to s2_custom_keywords, would you be open to merging it into the plugin?

Thanks for the quick response.

The simplest way to demonstrate is with an s2_custom_keywords hook that does nothing other than probe for get_the_ID() and the $post global. If you’re using a debugger you can pause it at the return statement to see what $post and $id are set to; otherwise toss in a var_dump or error_log.

https://pastebin.com/M6UTZmDP

You’re right that the actions that WP fires are passing the $post variable to S2’s publish(), but WP does not set them up as a global. As a result publish() knows which post triggered the email but since it doesn’t pass it along the value dies there.

Sorry to resurrect, but I just bumped into this problem again and found a new use case where not receiving an explicit post ID is limiting.

When a post publish is triggered via WP cron, there is no global $post and get_the_ID() returns null. In this case S2 follows the logic path for publishing a single post, which fires s2_custom_keywords with only the content, but unless I’ve overlooked something there’s no way for me to see what post is being acted on.

Hi bcworkz, thanks for your response.

search_terms is referenced in the documentation parse_query():

* @type array $search_terms Array of search terms.

…which the doc block for get_posts says to refer to for a full list of available arguments.

From your explanation and from reading the code, I think the doc block is incorrect and search_terms is ignored as an argument to parse_query or get_posts.

That works in some cases (including the one above, so thanks for the suggestion), but what if mail() were called via subscribe2_cron()? I believe in that case there’s a list of posts in context, but I don’t think there’s any way to get at them.

Note: when I first upgraded to 4.3.1 from 4.2, for some reason I had to go into Screen Options > “Show on page” and activate “Post Type Archives” to make the option show up in the menu editor. Was this the issue for you, too?

I’m running the plugin (1.3.1) with WordPress 4.3.1 and it’s working fine for me. Can you elaborate on “not working”?

On further review it looks like WP_Query‘s internal $queried_object can be set in two places:

• During parse_query() if a pagename is provided; that page is used.
• In get_queried_object():

• if a category, tag, or custom taxonomy term is provided, that term is used
• else if this is an archive request, the archive post type is used.
• else if this is the posts page, that posts page is used.
• else if this is any single post, that post is used.
• else if this is an author page, that author is used.

Based on that, and because a query can satisfy both is_tax and is_post_type_archive, it appears that get_queried_object cannot be reliably used to determine the post type of an archive page.

amath,

I don’t have answers, but am wondering if you discovered anything with this. I’m facing precisely the same problem. That is, I have cloned a blog and restored it under another domain, and as soon as I attempt to update a page on the destination blog I encounter a lengthy delay followed by a max execution time error. It appears to be triggering clean_post_cache and clean_object_term_cache repeatedly.