Work in progress for context-specific settings #123
Conversation
…che to hold it all, and update the plugin to set context-specific values
|
Contributions to this work in progress would be very welcome... in particular I haven't figured out yet how to handle the interface without making things too complex. My current idea is that there should be a dropdown in the action bar (top right with the save configuration/to admin view buttons) where the user can select a context they have access to (per standard MODX ACLs). That would refresh the page, showing the context-specific values. An alternative approach and [was approached here]https://forums.modx.com/thread/81490/clientconfig-custom-configuration-cmp-for-clients?page=6#dis-post-490786) where each context becomes a tab in the component, which gets troublesome with a large amount of contexts. And this comment suggests moving the UI to the edit context panel, but I'm not sure if I like that as it gets too close to the real context settings which sounds confusing. On save, the system would check which values are identical to the default (system) values, and only create records for the ones that are different. This makes it easy to have an inheritance system, because values are assumed to be configured on the system, and overridden per context. There also needs to be a way to tell a field to revert back to the default (i.e. remove the context-specific record). This can't be "leave it empty", because an empty value can be a valid non-default value, and you may not know the default value either so setting it to that isn't practical either. Likely this means introducing some kind of button or link that resets to the default, but I don't know what yet. For people who wish to contribute in another way, here's a bountysource link to place a bounty that will help make this rise to the top of my to do list. :P |
|
Hi Mark, how are things going? I'm not able to contribute with anything technical I'm afraid, you're way ahead of me there, but at least I can share my thoughts when it comes to the UI, for what it's worth. I think putting the contexts in tabs at the top sounds like the way to go. If there's a large number of contexts, this could perhaps be solved in the same way as on resources. In the attached screengrab you can see that arrows appear at the sides to scroll through the tabs when they don't fit on the screen. Then the tabs you have in the current version of ClientConfig (groups in client view and settings/groups in admin view) could perhaps go vertically on the left, just like Categories do on the Template Variable tab in the screengrab?
|
|
Hi @lottaar - I don't have an update since my last post yet, but thanks for taking the time to comment. I've ruled out the tab approach because it wont scale. Even the modmore site has 7 contexts, which would cause those awkward scroll buttons to appear, and it's also not searchable. So selecting contexts will be done through a dropdown in the top right. The TV tabs you mention is already an option; there's a setting that allows you to set a horizontal or vertical layout for the setting groups. What I haven't figured out entirely UI-wise is how to handle each setting and the new features that need to be added to that, most importantly the ability to reset to the default value. TVs sorta have this so maybe I'll just copy that.. |
|
Spent a bit more time on this following another generous contribution to the bountysource. There's now a dropdown in the top right to select a context, which will dynamically update the values in the form. Doesn't work yet with rich text fields (the shown value doesn't get updated), and for some reason there's no spacing between the other buttons and the dropdown, so it looks weird. The next step would be to update the save processor to change where the values are stored, so they go into cgContextValue objects instead of the cgSetting one. Might also need to change the combo to use a custom processor so we have a bit more control over what gets returned, so there could be a "clientconfig.contexts" setting or something to control which ones are available. |
Conflicts: assets/components/clientconfig/js/mgr/sections/home.js
…nto the processor so events aren't duplicated needlessly
… settings later) with custom combo, add the context name to the header after selecting a context, and add &context url parameter to the controller to auto select said context
|
It's starting to look functional :D |
|
I've published a first dev build of ClientConfig 2.0 to modmore.com. For anyone looking to try out this new multi context feature, follow the instructions below. ImportantDo not install this on existing client sites or sites you aim to launch soon, as I don't know how fast I can fix issues. Time is limited, so keep using 1.4.x for anything that needs to work. If needed I can push out 1.4.x updates separately from the 2.0 builds. Be aware that I have not tested the 1.4 to 2.0 migration. I expect that to be fine, as the data model was added to what was already there, but perhaps testing will prove otherwise. This is a dev build, not a beta. Expect things to be broken. Don't install it if you're not happy with that :) Known issues
Installing via modmoreClientConfig 2.0.0-dev1 is available only to modmore users that opt-in to the If you don't have a modmore.com account yet: sign up and verify your account. If you don't have modmore set up in your MODX site yet as a package provider, create an api key and follow the instructions shown (also available here) to add it to your package manager. Next, again on the api keys page, find the api key you're using in the list, and click on Now you can go into the package manager by clicking on the small arrow on the Download Extras button, choosing the Select Package Provider menu item, and clicking modmore in the list. Search for ClientConfig, and it should say version 2.0.0-dev1. Finally, let me know how it works for you. Missing anything that's not yet on the known issues list earlier in this post? Ideas to make it better? Let me know. |
|
Will test it soon-ish and let you know! Thanks for the updates! :) |
|
I've fixed the issue with RTEs and added a setting to switch between global and context aware mode. That, for now, concludes the work on this I think. I'll prepare a test release shortly. Future enhancements can include the permissions set to control who can edit what, for now that is simply tied in with existing context ACLs. |
This is a work in progress pull request, the feature isn't ready yet.
What does it do?
[[++setting_placeholders]]and$modx->setOption/getOption.Why is it needed?
Would bring ClientConfig to a whole new level of usefulness.
Related issue(s)/PR(s)
#4 #112 #23