Fix/necessary Category Readonly Settings#28
Merged
Conversation
The necessary category's readonly checkbox was rendered with disabled in the admin, but form.serialize() silently drops disabled fields. This caused readonly (and potentially enabled) to be overwritten as false every time settings were saved, making the Strictly Necessary toggle interactive on the frontend. Force enabled=true and readonly=true for the necessary category in warder_validate_options regardless of form input, and disable both checkboxes in the admin UI so they are visually consistent with their enforced values. All other categories continue to use the submitted checkbox values normally.
Hidden is_regex inputs used value="" for false. PHP's isset() returns true for an empty string, so every non-regex cookie (_gid, _gat) was silently saved as is_regex:true on every admin save, corrupting the autoClear cookie list and masking real changes as "no changes detected". Fix: hidden input now outputs '0' for false. Validation uses !empty() and checks for literal '0' so only the string '1' is treated as true. Also remove the "No changes detected" branch in the AJAX handler. update_option() already runs, so always respond with "Settings saved" to avoid misleading admins who toggle a setting back to its current DB value.
Non-necessary categories were appearing as locked and pre-selected in the frontend because enabled/readonly were read from DB values rather than being enforced by policy. - settings.php: always save enabled=false, readonly=false for non-necessary (was: isset check returned true whenever the key existed in the DB) - index.js: hardcode enabled/readOnly based on category id, ignore DB values - admin.php: replace confusing enabled/readonly checkboxes with clear info text — lock icon + explanation for necessary, unlock icon for others - docs: add cookie-category-rules.md documenting the enforcement rules
The version bump commit only captured the first fix. Two more were landed afterwards: is_regex always saving as true, and non-necessary categories appearing locked in the frontend modal. Upgrade notice updated to summarise all three data-corruption issues.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This release delivers version 2.0.1, a focused patch addressing three data-integrity bugs in the cookie consent settings management layer. The primary issue was that the
necessarycookie category'senabledandreadonlyflags were not being preserved correctly across the full settings lifecycle — from form submission through PHP validation, AJAX handling, and JavaScript initialization. A secondary bug caused theis_regexboolean field to save astrueregardless of its actual value due to a missing falsy-value check, and a third issue caused the admin UI to display a misleading "no changes detected" message even when changes had been saved. Together, these fixes ensure that the necessary category remains locked as enabled and non-editable across all layers of the plugin, and that all other category fields serialize and persist correctly.Bug Fixes and Data Integrity:
inc/settings.php,inc/ajax.php, andwarder-cookie-consent.phpwere updated to explicitly re-enforceenabled = trueandreadonly = trueon the necessary category during validation and save, preventing user-submitted values from overriding the hardcoded constraint.is_regexserialization bug in the cookie rules form handler was corrected by explicitly checking for the presence of the checkbox field rather than relying on a truthy cast, which previously defaulted absent checkboxes totrue.JavaScript and Build:
src/index.jswas updated to mirror the PHP-side constraint, ensuringcreateConfigFromSettings()always appliesenabled: trueandreadOnly: trueto the necessary category regardless of whatwindow.sccSettingscontains, anddist/cookieconsent.bundle.jswas rebuilt accordingly.Documentation:
CHANGELOG.mdandreadme.txtwere expanded to document all three bug fixes under the 2.0.1 release entry, and a newdocs/cookie-category-rules.mdfile was added to explain the cookie category configuration rules and constraints for developers integrating or extending the plugin.Files Changed:
CHANGELOG.md(Modified)dist/cookieconsent.bundle.js(Modified)inc/admin.php(Modified)inc/ajax.php(Modified)inc/settings.php(Modified)package.json(Modified)readme.txt(Modified)src/index.js(Modified)warder-cookie-consent.php(Modified)docs/cookie-category-rules.md(Added)