cache imagify user response even in case of error

[MathieuLamiot]

Description

Fixes the increase of requests to the Imagify API after release of 2.2.3

Users might be impacted as the fetching of information about their subscription from the API will now be delayed by 5 minutes in case of error on the first try. As a result, some data might not be available for 5 minutes initially if there was an issue when fetching the user data. It will be automatically retried after 5 minutes.

Type of change

• New feature (non-breaking change which adds functionality).
• Bug fix (non-breaking change which fixes an issue).
• Enhancement (non-breaking change which improves an existing functionality).
• Breaking change (fix or feature that would cause existing functionality to not work as before).
• Sub-task of #(issue number)
• Release
• Hotfix

Detailed scenario

If you don't have a valid API key for instance, Imagify plugin currently tries to fetch user data on each admin page opening. After this fix, the call should happen only once every 5 minutes.

Technical description

Documentation

We now store the result of get_imagify_user even in case of error, so that this result can be reused next time it is needed without doing again a call to the API.

New dependencies

List any new dependencies that are required for this change.

Risks

If a user fixes the issue, some part of the admin dashboard might take 5 minutes to get updated. For instance, after setting up the API key, the account information might not be available immediately.

Mandatory Checklist

Code validation

• I validated all the Acceptance Criteria. If possible, provide screenshots or videos.
• I triggered all changed lines of code at least once without new errors/warnings/notices.
• I implemented built-in tests to cover the new/changed code.

Code style

• I wrote a self-explanatory code about what it does.
• I protected entry points against unexpected inputs.
• I did not introduce unnecessary complexity.
• Output messages (errors, notices, logs) are explicit enough for users to understand the issue and are actionnable.

Additional Checks

• In the case of complex code, I wrote comments to explain it.
• When possible, I prepared ways to observe the implemented system (logs, data, etc.).
• I added error handling logic when using functions that could throw errors (HTTP/API request, filesystem, etc.)

[MathieuLamiot]

After testing a bit, the only impact I could see is when someone enters a wrong API key, navigates a bit the admin, then enters a valid key. After this, it takes a few minutes for the admin bar to display the license and quota.
I would need someone to validate that this reduced the number of API calls, maybe by adding a log and comparing before/after the fix.

[MathieuLamiot]

@wordpressfan confirmed it should be working to reduce 401: https://wp-media.slack.com/archives/CU0F6EGQ1/p1731051235420369?thread_ts=1730995819.928759&cid=CU0F6EGQ1

I played a bit with the version and it seems working on my end.

[Mai-Saad]

@wordpressfan Thanks for the PR.

• We have the 401 with the following case:
  0- remove existing imagify + delete any existing transients
  1- fresh install of PR , activate plugin and use right key
  2- edit the key to be wrong and save=> 401 is there
  3- refresh admin => another 401 ====> this will happen with
• We have a possible scenario to have empty account data (same on 2.2.3) => will add separate GH for that
  in this case we have [08-Nov-2024 12:17:47 UTC] PHP Deprecated: strtotime(): Passing null to parameter #1 ($datetime) of type string is deprecated in /var/www/new.rocketlabsqa.ovh/htdocs/wp-content/plugins/imagify-plugin/inc/functions/admin.php on line 415

Note: initial test plan is here as per requirements from discussions https://wpmediaqa.testrail.io/index.php?/runs/view/927&group_by=cases:section_id&group_order=asc

[hanna-meda]

testrail-report-659.pdf