aaribaud

The /api/v1/accounts/:id/statuses endpoint would be fine for my purpose, as it honors min_id and max_id and would thus allow fetching the messages from a whole month period, and the most I would fetch would be 31 posts (1 per day).

But you’re right that it would then fetch ~30 posts every time the page is read (and it would not be read frequently enough for caching to be efficient).

The embeds plugin might be part of a solution, though. Thanks for pointing this to me!

Hi Wolfgang,

My need would be to fetch posts from the public timeline of my own account, filtering by some hashtag (or the hashtag’s public timeline, filtering by author) between two dates.

This should be doable with the /statuses endpoint, using min_id and max_id in the request, as these seem to be the only way to specify a timestamp interval.

I’ll try and create (and test) a PoC branch.

• This reply was modified 1 year, 4 months ago by aaribaud.

For the record, I have reported the issue on the French WP forum at https://wpfr.net/support/sujet/wp5-6-empeche-lui-meme-son-wp_version_check-de-fonctionner/ where a core developer could reproduce the issue. I am closing the issue here in order to avoid duplicates.

I’ve gone on looking into the plugins’ code. The only line in any of them which mentions wp_version_check only calls wp_next_scheduled(), which finds out when wp_version_check() is next scheduled; it does not *disable* wp_version_check().

Next I’ve traced whether wp-include/update.php did in fact set up the filter for wp_version_check that wp-admin/includes/class-wp-site-health-auto-updates.php expects to find, and no, it does not set it up.

More precisely, at line 878 of wp-includes/update.php, there is a test which, if sucessful, will exit before setting any filters. Exit is performed if ((not on the main site) and (not the admin)) or doing ajax).

As I am looking at the main site’s health as the admin, the only reason for the test to succeed is wp_doing ajax() returning true.

I have added debug code and checked that indeed wp_doing ajax() returns true at line 878.

So since wp_doing ajax() returns true, wp-include/update.php will not set up the filter, and therefore wp-admin/includes/class-wp-site-health-auto-updates.php will not find the filter, not because some plugin prevented the call to wp_version_check() but because WP prevented itself from setting up the call in the first place.

Can someone now confirm the issue?

• This reply was modified 3 years, 11 months ago by aaribaud.
• This reply was modified 3 years, 11 months ago by aaribaud.
• This reply was modified 3 years, 11 months ago by aaribaud.

Hello,

I realize I have not expressed myself clearly enough.

I already have grepped in my site’s plugins’ code and none of them adds a filter or action for ‘wp_version_check’.

I am not looking for the root cause of the ‘A plugin has prevented updates by disabling wp_version_check()’ message; I have traced execution of my site’s code and found the root cause.

In fact, if you just download the wordpress install archive, untar it and grep it for “add_action.*wp_version_check”, you will see the hit for wp-includes/update.php where it does the “add_action( ‘wp_version_check’, ‘wp_version_check’ );”.

My question is not “help me find what the problem is”, it is “can someone please confirm if what I think is a problem indeed is one or not”.

Regards,
Albert.

EDIT: I have looked at the git repo, and it seems the check was recently changed, in commit 039ce3f16f1 (https://github.com/WordPress/WordPress/commit/039ce3f16f1).

Previous code did not have the call to has_filter().

• This reply was modified 3 years, 11 months ago by aaribaud.