• Resolved balbert

    (@balbert)


    After activating the cache settings: define(‘WPP_CACHE_VIEWS’, true);
    we started seeing a PHP Warning with checking if a string is a timestamp or not.

    V 5.2.2

    here is the stack trace:

    E_WARNING: DateTime::__construct(): Failed to parse time string (@2020-08-11 18:26) at position 8 (-): Double timezone specification
    in DateTime::__construct called at /wp-content/plugins/wordpress-popular-posts/src/Helper.php (164)

    in WordPressPopularPosts\Helper::is_timestamp called at /wp-content/plugins/wordpress-popular-posts/src/Rest/Controller.php (207)
    in WordPressPopularPosts\Rest\Controller::update_views_count called at /wp-includes/rest-api/class-wp-rest-server.php (1015)
    in WP_REST_Server::dispatch called at /wp-includes/rest-api/class-wp-rest-server.php (342)
    in WP_REST_Server::serve_request called at /wp-includes/rest-api.php (312)
    in rest_api_loaded called at /wp-includes/class-wp-hook.php (287)
    in WP_Hook::apply_filters called at /wp-includes/class-wp-hook.php (311)
    in WP_Hook::do_action called at /wp-includes/plugin.php (544)
    in do_action_ref_array called at /wp-includes/class-wp.php (388)
    in WP::parse_request called at /wp-includes/class-wp.php (739)
    in WP::main called at /wp-includes/functions.php (1274)
    in wp called at /wp-blog-header.php (16)
    in require called at /index.php (17)

    it seems to be happening when calling the rest api:
    URL /wp-json/wordpress-popular-posts/v1/popular-posts

    of course this date is not a timestamp so it correctly errors somewhat but not sure if this format for checking is correct?

    Thoughts on eliminating the warning?

    Thanks,

    Bob

Viewing 11 replies - 1 through 11 (of 11 total)
  • Plugin Author Hector Cabrera

    (@hcabrera)

    Hi Bob,

    Any chance you could share more details about your setup? For example:

    • PHP version?
    • Are you using Redis, Memcached, something else?
    • Any other info you may consider useful so I can reproduce the issue.
    Plugin Author Hector Cabrera

    (@hcabrera)

    Also, do you know what time zone is configured on your server?

    Thread Starter balbert

    (@balbert)

    Thanks for getting back so quick. Here is some more information:

    – we are on PHP 7.3.17
    – we are using Redis in AWS via elasticache
    – we are running W3TC plugin Version 0.14.3

    let me know if you need more info.
    Bob

    Thread Starter balbert

    (@balbert)

    just saw your other question about time zone.

    our servers are set to UTC, but WP is set to Eastern/New York.

    Thread Starter balbert

    (@balbert)

    also forgot to mention running WP v 5.4.2 soon to update to 5.5.

    Plugin Author Hector Cabrera

    (@hcabrera)

    Thanks!

    Alright, I was able to reproduce the issue but to be honest I’m not entirely sure what causes it. I ran a loop using that exact same date (2020-08-11 18:26, the @ symbol is added by the function) and the is_timestamp() function sometimes returns the expected value (a boolean) and sometimes it triggers that PHP warning (which is likely the reason why I never noticed it in the first place.)

    It’s pretty late over here and my mind is just not fresh enough to go into full developer mode right now but couldn’t stop thinking about it so here I am with a quick & dirty workaround that after running it a couple of times in the same loop seems to do the job (and apparently way faster too, will need to do some more testing to confirm though):

    1. Go to Plugins > Plugin Editor and pick WordPress Popular Posts from the dropdown.
    2. Click on src/Helper.php to edit this file.
    3. Replace the is_timestamp() function (around line 161) with this version.
    4. Click on Update File to save changes.
    Thread Starter balbert

    (@balbert)

    I implemented the change and so far it looks to have eliminated the warning.

    is there anything else i should check to make sure no issues in functionality other than the widget appearing without issue?

    any way to make sure caching is working correctly?

    thanks,
    Bob

    Plugin Author Hector Cabrera

    (@hcabrera)

    Hey Bob,

    Thanks for reporting back. Glad to know that that workaround did its job.

    Regarding your question, you could either check the available keys in Redis (WPP’s contains the wpp string in in, an associate array with dates, post ID, and views count) and you should see the data there. Alternatively, you could also just check the database and verify that posts views are being stored in batches. For example, when the pageviews cache is disabled (default) WPP stores every pageview individually in the _popularpostssummary table (eg. Post ID 5413, 2020-08-13 13:42:35, 1, Post ID 5413, 2020-08-13 13:42:43, 1, and so on) and when enabled then you should see that records start showing multiple views by minute instead of multiple records per view (eg. Post ID 5413, 2020-08-13 13:42:35, 2).

    Thread Starter balbert

    (@balbert)

    great thanks for the info. I am seeing entries with pageviews column set to 2 or 3 or 4 etc…looks like this is all working.

    When do you think this update would be integrated in an official update? 5.2.3?

    thanks again for the quick response.
    Bob

    Plugin Author Hector Cabrera

    (@hcabrera)

    Hopefully, sometime soon (yeah I know, that’s a super vague answer haha.) I’m swamped with work at the moment so I’d rather not rush things. This upcoming weekend I’ll spend some time testing this and also will work on a couple of minor changes and if everything seems fine and nothing unexpected happens (it’s 2020 after all) then the release of version 5.2.3 should follow soon afterwards.

    Plugin Author Hector Cabrera

    (@hcabrera)

    Well, I had to release version 5.2.3 way sooner than expected due to a compat issue with WordPress 5.5 :/

    FYI I just created an issue here so that I don’t forget to look into this.

Viewing 11 replies - 1 through 11 (of 11 total)
  • The topic ‘Warning on Helper::is_timestamp() when cache activated’ is closed to new replies.