Closes #6715

[Miraeld]

Description

Fixes #6715

Documentation

User documentation

Explain how this code impacts users.

Technical documentation

Explain how this code works. Diagram & drawings are welcomed.

Type of change

Delete options that are not relevant.

• 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).

New dependencies

List any new dependencies that are required for this change.

Risks

List possible performance & security issues or risks, and explain how they have been mitigated.

Checklists

Feature validation

• I validated all the Acceptance Criteria. If possible, provide sreenshots 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.

Documentation

• I prepared the user documentation for the feature/enhancement and shared it in the PR or the GitHub issue.
• The user documentation covers new/changed entry points (endpoints, WP hooks, configuration files, ...).
• I prepared the technical documentation if needed, and shared it in the PR or the GitHub issue.

Code style

• I wrote self-explanatory code about what it does.
• I wrote comments to explain why it does it.
• I named variables and functions explicitely.
• I protected entry points against unexpected inputs.
• I did not introduce unecessary complexity.
• I listed the introduced external dependencies explicitely on the PR.
• I validated the repo-specific guidelines from CONTRIBUTING.md.

Observability

• I handled errors when needed.
•  I wrote user-facing messages that are understandable and provide actionable feedbacks.
• I prepared ways to observe the implemented system (logs, data, etc.).

Risks

•  I explicitely mentioned performance risks in the PR.
• I explicitely mentioned security risks in the PR.

[codacy-production]

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation	Diff coverage
Report missing for a8da7ae1	✅ 82.46% (target: 50.00%)

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (a8da7ae)	Report Missing	Report Missing	Report Missing
Head commit (4fa6b9c)	37317	14500	38.86%

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#6739)	57	47	82.46%

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

See your quality gate settings    Change summary preferences

---

_{🚀 Don’t miss a bit, follow what’s new on Codacy.}

_{Codacy stopped sending the deprecated coverage status on June 5th, 2024. Learn more}

Footnotes

1. Codacy didn't receive coverage data for the commit, or there was an error processing the received data. Check your integration for errors and validate that your coverage setup is correct. ↩

[MathieuLamiot]

Early review to provide some guidance and speed up the process.
There is still 1 failing integration test.

[Mai-Saad]

Working as expected

[thinkjarvisdesignandmarketing]

@Mai-Saad
Following the DDOS attack and impact it had on all licensed websites:
For your more professional users please can we get an explanation as to what has changed about license calls?
For my own sanity as an agency owner - I need to know what has changed.

Is WP-Rocket still running license checks on the front end?
Is it just running checks when the admin screen opens?
Any other calls to WP-Rocket servers that we should be aware of that cause the connection to fail or repeatedly time out?

[MathieuLamiot]

@thinkjarvisdesignandmarketing, Hello

Here are some details about the fix:
First of all, there are no repeated license validations: the calls to wp-rocket.me that have been slowing down user websites during the downtime are designed to retrieve the latest information about your wp-rocket.me account, from our server to your plugin (license type, license expiration date, etc.) so that, for instance, the information displayed on the plugin dashboard in wp-admin are accurate, among other things.
Once the call succeeds, the data is kept as a transient for a few hours. A new call only happens once the transient is expired.

The root cause of the issue was that, in case the transient expires, the call was retried on each load of the plugin until it succeeded. Since the website was not responding, this happened up until we were back online, and each plugin load had to wait for the timeout to be reached to continue. Note that this timeout is not enforced by our plugin but the default value (configurable in WordPress) is used.

To mitigate this type of issue, we already had exponential retry mechanisms implemented (if a call fails, don't retry at every plugin load, but wait a bit before retrying, and so on). This is the standard state-of-the-art approach for this. Unfortunately, such a strategy was not implemented for this specific call. In the upcoming version, we apply this retry strategy to the problematic call as well, so that, in case wp-rocket.me does not respond, your websites won't keep trying to reach it systematically.

[thinkjarvisdesignandmarketing]

@MathieuLamiot
Please can you confirm with a simple statement below:
License checks no longer run on the front end of your customers websites
This was the main concern - Essentially if the WP-Rocket server was not available uncached pages were not serving.
If I am correct in this assumption - This means our TTFB scores are actually tied to how fast the license check or ping to wp-rockets servers take.

Can you please confirm that the license checks are no longer tied directly to cache generation, RUCSS and preload?

Otherwise the proposed solution does not solve the problem

Why is the transient lifespan not tied to the expiry date of the clients subscription to WP-Rocket?
If you just use the expiry date on your server - It only needs to be checked once - At the start/end of their fixed term license. Not periodically.