Technical summary
How many custom rules can Free and Pro save in Aegisify WAF 1.20.13, and is there a five-rule runtime evaluation cap? controls deterministic request inspection and matching for common web-attack techniques, custom rules, managed signatures, and heuristics. This article is grounded in the supplied Aegisify WAF 1.20.13 plugin package. It documents current behavior and defaults rather than relying on older FAQ wording.
Current-version correction
The old wording is incorrect as an engine-level “evaluate only the first five” cap. In WAF 1.20.13 the wp-admin custom-rule save path accepts up to 5 rows for Free and 50 rows for Pro. The runtime rule engine then orders the stored enabled rules by numeric priority and selects the first rule whose method, path, and configured predicates match; it does not apply a second per-request “first five only” evaluation gate. Pro rule import is separately limited to 512 KB and the first 100 imported rows.
Custom-rule mechanics and limits
Custom rules use explicit numeric priority; lower values run first. The current UI accepts priorities from 1 through 9,999 and uses 100 as the base/default when a priority is absent. HTTP method defaults to ANY and can be narrowed to GET, POST, PUT, PATCH, DELETE, HEAD, or OPTIONS. The safe action default is Log; Block terminates validated matches, while Skip Core WAF inspection is a narrow compatibility exclusion that bypasses the remaining Core WAF layers for that matching request. Regex conditions are Pro-only in the current editor; invalid regular expressions prevent the ruleset from being saved/imported. Root-wide or global Core WAF exclusions are rejected. Free save is bounded to 5 rows; Pro save to 50 rows. Pro JSON import is bounded to 512 KB and the first 100 rows.
Where administrators configure or verify it
Primary wp-admin path: wp-admin → Aegisify WAF → WAF Rules / Settings. Exact controls can be distributed across the related tab/page when the feature is composed of multiple engines.
Current 1.20.13 defaults and related controls
The table below lists settings in the supplied current source that are directly related to this topic. The current default/bound/status shown is code-derived. Where the product does not define a named Medium preset, the shipped default is documented as the baseline operating point rather than inventing a value.
| Setting | Current default / bound / status | Why this default | How to tune safely |
|---|---|---|---|
custom_rules.free_max_rows |
Maximum: 5 | 5 is the current code-enforced maximum/capacity boundary for this control, not a normal operating default. | Do not treat this cap as a target. Operate below it unless the legitimate site requirement needs more capacity; reaching the cap means the current implementation will clamp, truncate, stop adding rows, or reject additional input depending on the control. |
custom_rules.pro_max_rows |
Maximum: 50 | 50 is the current code-enforced maximum/capacity boundary for this control, not a normal operating default. | Do not treat this cap as a target. Operate below it unless the legitimate site requirement needs more capacity; reaching the cap means the current implementation will clamp, truncate, stop adding rows, or reject additional input depending on the control. |
custom_rules.import_max_bytes |
Maximum: 524288 | 524288 is the current code-enforced maximum/capacity boundary for this control, not a normal operating default. | Do not treat this cap as a target. Operate below it unless the legitimate site requirement needs more capacity; reaching the cap means the current implementation will clamp, truncate, stop adding rows, or reject additional input depending on the control. |
custom_rules.import_max_rules |
Maximum: 100 | 100 is the current code-enforced maximum/capacity boundary for this control, not a normal operating default. | Do not treat this cap as a target. Operate below it unless the legitimate site requirement needs more capacity; reaching the cap means the current implementation will clamp, truncate, stop adding rows, or reject additional input depending on the control. |
custom_rules.priority_default |
100 | The shipped value of 100 is the exact current default encoded by the plugin and should be treated as the baseline unless site evidence supports a change. | Treat this numeric value as the shipped baseline. Adjust one step at a time, document the reason, and verify the operational effect before making the setting more extreme. |
custom_rules.method_default |
ANY | “ANY” is the exact shipped value in the current version. It is preserved as the baseline because the plugin code defines it as the default rather than deriving it from the old FAQ text. | Keep the shipped value unless a documented site requirement calls for a different mode or identifier. Validate the change in the feature’s logs/status view and roll back if behavior becomes less reliable. |
custom_rules.action_default |
log | “log” is the shipped baseline so administrators can collect evidence and verify normal traffic or behavior before moving to stronger enforcement where applicable. | Use the shipped observation mode while establishing a baseline. Move toward enforcement only when logs show the signal is reliable. Returning to monitor/observe is preferable to disabling a control entirely during false-positive tuning. |
custom_rules.regex_requires_pro |
PRO required | The current UI/save path makes this capability license-gated rather than a site-tuning default. | This row documents fixed current-version behavior or a capability boundary. Change the related user-facing setting rather than attempting to tune this reference value. |
Adjustment strategy
Change one control at a time, save it through the product UI, reproduce the legitimate and malicious/test flow, and review the product log/status surface. For enforcement controls, use Monitor/Observe first when normal behavior is uncertain; move to Block only after the signal is reliable. For thresholds, do not jump directly from the default to an extreme unless an active incident requires emergency containment and a recovery path exists.
Operational guidance
On a production WordPress site, a sudden block spike after a plugin/API deployment should first be investigated in WAF logs. Narrow the issue to the exact route, rule family, client identity, or payload characteristic. Prefer a precise exclusion/allowlist or threshold adjustment over disabling broad protection.
Technical keywords
Aegisify WAF, 1.20.13, cap, custom, enabled, enforcement, engine, evaluated, first, hard, managed, only, rule, rules, signature, custom_rules
Source baseline
Verified package: Aegisify WAF 1.20.13. Primary source files: includes/class-aegiswaf-storage.php; includes/class-aegiswaf-ai-security.php; includes/class-aegiswaf-api-security.php; includes/class-aegiswaf-managed-rules.php; includes/ddos/class-aegiswaf-ddos-storage.php; includes/admin/pages/class-aegiswaf-page-waf-rules.php; includes/admin/pages/class-aegiswaf-page-logs.php; includes/admin/pages/class-aegiswaf-page-access.php. If a future plugin version changes these settings, support should re-read the installed version rather than carry these defaults forward automatically.