Fix issue with custom style getting unset on form settings update#2139
Conversation
WalkthroughThe changes in this pull request involve the addition of a new hidden input field for custom styles in the Changes
Possibly related PRs
Suggested labels
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (2)
💤 Files with no reviewable changes (1)
🔇 Additional comments (2)classes/views/frm-forms/settings-advanced.php (2)
The hidden input field is properly implemented with appropriate escaping and follows the existing pattern for options storage.
Since this field was moved from settings-buttons.php, we should ensure existing custom styles are properly migrated. ✅ Verification successfulNo migration needed - custom_style field is properly handled Based on the code analysis, the
🏁 Scripts executedThe following scripts were executed for the analysis: Script: #!/bin/bash
# Description: Check for any remaining references to custom_style in settings-buttons.php
# and verify the migration path
# Check for any remaining references to custom_style
rg -l "custom_style" classes/views/frm-forms/settings-buttons.php
# Look for any migration code or hooks that might handle the transition
rg -B 3 -A 3 "custom_style.*migration" classes/
Length of output: 115 Script: #!/bin/bash
# Let's broaden our search to understand the migration context better
# Check git history for changes related to custom_style
git log -p --all -- "**/settings-buttons.php" "**/settings-advanced.php" | grep -A 10 -B 10 "custom_style"
# Search for any migration-related files or functions
fd migration classes/
# Look for any database upgrade scripts or migration utilities
rg -l "upgrade|migration" classes/
# Check for any references to custom_style across the codebase
rg -l "custom_style" classes/
# Look specifically at the form settings handling code
ast-grep --pattern 'function $_($$$ custom_style $$$)'
Length of output: 3642 Script: #!/bin/bash
# Let's examine how custom_style is handled in the codebase
# Check the form model and controller for custom_style handling
rg -A 5 -B 5 "custom_style" classes/models/FrmForm.php classes/controllers/FrmFormsController.php
# Look at the settings handling in advanced settings
rg -A 5 -B 5 "custom_style" classes/views/frm-forms/settings-advanced.php
# Check for any database or settings migration code
rg -A 5 -B 5 "custom_style" classes/models/FrmMigrate.php classes/models/FrmFormMigrator.php
# Look at the XML helper for import/export handling of custom_style
rg -A 5 -B 5 "custom_style" classes/helpers/FrmXMLHelper.php
# Check styles helper for any custom style handling
rg -A 5 -B 5 "custom_style" classes/helpers/FrmStylesHelper.php
Length of output: 8277 Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
This input is on a page that is now getting unset.
I noticed my styles would get disabled after saving form settings after merging https://github.com/Strategy11/formidable-forms/pull/2115/files