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.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Harmonize module options #1158
Harmonize module options #1158
Changes from 1 commit
b69c128
580ddb6
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure new named option should always have the priority.
Maybe we could test also module activation state (test above
AND
module is active) though maybe involves a too remote scenario to complicate the function...There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The idea of the import is a one-shot action at activation, the goal is that QT-XT cares of its own options (modules).
The normal scenario is that new options don't exist yet. If we can import a value such as ACF or slugs legacy settings (coming from original plugins) the new option is created from these values to ensure the transition from the old plugins. But from that point we want to remain with the QT-XT setup and ignore the legacy stuff once we have all set in QT-XT.
The most tricky case is when the QT-XT options are reset, we don't really want to import again but in that case we expect the admin to save a new set of options right after the reset. If this is not done, a new import can happen again.
This patch is only valid for the modules as it's a new feature in QT-XT but this will be expanded to all other options later once we cut completely the links with QT-X (not XT).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These would look better somewhere in modules source files to make things cleaner, maybe a new function to be called from here.
It would be better to segregate code which depends on module list from core files.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also thought this, but this belongs more to general admin functionalities for the whole QT-XT plugin. For the same reason as for the option names, better keep those with the rest and not split them to avoid the risks of missing updates/deletions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These definitions would look better in modules source files.
It would be better to segregate code which depends on module list from core files.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The idea is that all options definitions should be kept consistent in a unique place (the options names are used both for front and admin). Currently it's hard to to understand where a general option is set or read in the code because the values are spread everywhere and most of the settings are generated from intermediate strings (with
qtranslate_
prefix). The modules should not be fundamentally different regarding the options interface. The other options should also converge to something more comprehensive.