What to expect when migrating from older versions
Cloudflare Add-On 2.5 changes how WP Cerber keeps track of the Cloudflare IP Access Rules it manages. When you update from an older version, the add-on rebuilds those existing rules automatically from the current state of WP Cerber instead of trying to migrate each historical rule record in place.
For most websites, no manual rule recreation is required.
Before updating
Cloudflare Add-On 2.5 requires:
- WP Cerber 9.8.3 or newer
- PHP 7.4 or newer
If your website runs an older WP Cerber version, update WP Cerber before updating the Cloudflare Add-On.
Make sure your Cloudflare email address and Global API Key are saved in the add-on settings. The automatic rebuild does not start until those credentials are present.
Diagnostic logging is optional, but enabling it before the update gives you a detailed record of the rebuild in the WP Cerber Diagnostic Log.
What happens after the update
Rules created by older add-on versions are not converted one by one. Older records do not always contain enough information to reliably determine whether a Cloudflare rule originally belonged to a lockout or to an IP Access List entry.
Version 2.5 therefore uses the current WP Cerber state as the source of truth. It rebuilds the Cloudflare rules that should exist now for:
- the Allowed IP Access List
- the Blocked IP Access List
- active WP Cerber lockouts that the add-on normally synchronizes
The rebuild follows your current add-on settings. If synchronization for one of those categories is disabled, rules in that category are not recreated.
The process does not modify your WP Cerber IP Access Lists or active lockouts. Cloudflare rules that are not managed by the WP Cerber Cloudflare Add-On are not part of the rebuild.
When the rebuild starts
The rebuild starts automatically when the add-on processes the next relevant WP Cerber IP event, such as a lockout, an unlock, or a change to an IP Access List.
That means it may not start at the exact moment you update the add-on. On a quiet website, the next relevant event may happen later. Until then, the existing Cloudflare rules remain in place and the add-on continues working as before.
If you want to trigger the rebuild without waiting for normal activity, you can add an entry to a WP Cerber IP Access List and remove it again.
What you may notice in Cloudflare
The rebuild replaces the old Cloudflare rule objects rather than preserving them. As a result, rule IDs change and the number of visible rules can temporarily change while the rebuild is in progress.
Large Access Lists or a large number of active lockouts may require several requests to complete. The add-on processes the rebuild gradually instead of trying to recreate every rule during one website request.
The add-on normally removes an old rule before creating its replacement because Cloudflare does not allow another IP Access Rule for a target already covered by an existing rule. If Cloudflare rejects an old-rule deletion, that rule remains tracked for another attempt and may temporarily prevent its replacement from being created.
WP Cerber itself continues to enforce its existing IP Access Lists and lockouts throughout the process. Temporary changes in the Cloudflare rule set are expected while the rebuild is running.
Some WP Cerber entries cannot be mirrored to Cloudflare
WP Cerber supports a broader range of IP address and network definitions than Cloudflare IP Access Rules.
If an IP Access List entry or lockout target is valid in WP Cerber but cannot be represented by Cloudflare, the add-on leaves it unchanged in WP Cerber and does not create a Cloudflare rule for it.
The rebuild never rewrites or removes a WP Cerber entry merely to make it compatible with Cloudflare. Cloudflare’s own restrictions on rule targets also continue to apply after the update.
If the rebuild is interrupted
The rebuild is designed to continue across multiple WP Cerber IP events. If it cannot finish during one request, its state is preserved and processing resumes later.
A failed database read also keeps the affected phase pending. If an old Cloudflare rule cannot be deleted, its legacy record remains available for another attempt.
An individual replacement rule that Cloudflare rejects does not keep the entire rebuild open. That failure can be reported to an administrator or written to the Diagnostic Log when logging is enabled, and the corresponding Cloudflare rule may remain missing after the rebuild finishes.
If the final Cloudflare rule set does not look as expected, check the WordPress admin notices first. If diagnostic logging was enabled, check the WP Cerber Diagnostic Log for rejected Cloudflare operations or unsupported targets.
If nothing appears to have started, confirm that the Cloudflare email address and Global API Key are saved in the add-on settings, then trigger a relevant IP event by adding and removing an IP Access List entry.
After the rebuild
Once the rebuild finishes, Cloudflare contains the rules the add-on was able to create from the current WP Cerber state and the targets Cloudflare can represent. The add-on then continues normal synchronization for later IP Access List changes, lockouts, and unlocks.
You do not normally need to recreate Cloudflare rules manually after updating to version 2.5.
Have any questions?
If you have a question regarding WordPress security or WP Cerber, ask it in the comments below or find answers on the community forum.
Spotted a bug or glitch?
We’d love to fix it! Share your bug discoveries with us here: Bug Report.




