ClientConfig: Custom configuration CMP for clients

Do these settings affect the manager at all? For example, if I use it to set friendly_alias_lowercase_only should it affect the alias when editing resources? Or automatic_alias?

Since the rtfm says

...while using settings in templates or in code.

does this mean these are for information or front-end use only? For example, changing 'emailsender' won't have any effect on system-generated email, such as user emails for new passwords set via the User editor in the Manager?

Looking at the plugin code, it appears that this emulates system settings by setting placeholders, using '+' as a prefix, thus generating [[++key]] placeholders. So I guess that answers this question. [ed. note: sottwell last edited this post 10 years, 3 months ago.]

What relationship do ClientConfig groups have to user groups?

Hi Susan,

You could also avoid the situation altogether for multi-language sites by using migxMultiLang instead of contexts.

Actually what people want is different settings (essentially context settings manageable through ClientConfig) per context - getting rid of contexts does not answer that need.

Quote from: sottwell at Jan 29, 2014, 04:19 AM

Do these settings affect the manager at all? For example, if I use it to set friendly_alias_lowercase_only should it affect the alias when editing resources? Or automatic_alias?

Since the rtfm says

...while using settings in templates or in code.

does this mean these are for information or front-end use only? For example, changing 'emailsender' won't have any effect on system-generated email, such as user emails for new passwords set via the User editor in the Manager?

Looking at the plugin code, it appears that this emulates system settings by setting placeholders, using '+' as a prefix, thus generating [[++key]] placeholders. So I guess that answers this question.

Settings are loaded in both frontend ([[++setting]]) and in the manager as well, however as connectors do not trigger the necessary event (OnHandleRequest), they are not available on ajax actions. Your examples of friendly_alias_lowercase_only or automatic_alias are things that are processed through the connector, so in that case the answer is no. If however you would create a client config setting site_name that will be reflected in the manager also. One way to make it also work across processors would be adjusting the connector to call $modx->invokeEvent('OnHandleRequest') but other plugins using the same event could get confused, so need to be careful with core hacks like that.

Quote from: sottwell at Jan 29, 2014, 04:48 AM

What relationship do ClientConfig groups have to user groups?

None. A CC Group is simply a categorisation (into tabs) for the end-user managing the settings through the component. Some people however have suggested features to be able of locking down certain CC groups to certain user groups, but that's not in the current version.

Quote from: rx2 at Aug 13, 2013, 06:02 PM

I have an odd issue where I moved a site from one server to another using Vapor and at the new server there are now 2 ClientConfig interfaces, one on top of the other instead of just one. It all still works and you can edit in either one of them but it's odd and a bit confusing to the client.

The host is such that I have not yet been able to reinstall it. They lock down everything and I have to make special requests to unlock things to do updates (the client insisted on using this host). When (and if) it actually happens I'll let you know.

Quote from: markh at Nov 19, 2013, 08:36 PM

Would anyone dare to make a mockup/spec of how CC could be made context sensitive, without losing the current features and breaking backwards compatibility?

I am unfortunately just a "user" rather than a programmer so I have no idea.

Quote from: sketchi at Nov 18, 2013, 01:30 PM

Quote from: rx2 at Nov 16, 2013, 05:30 AM

We do a lot of work with multiple contexts so we do what I suspect many people do.

We create an admin document and through the use of categories, template variables, and Forms Customization, make the things that can be different per context (an easy example are social media settings) client accessible.

Then, we use FastField in combination with a custom snippet (we are planning to release next week), and context settings, to retrieve the values of the TVs in the appropriate spots.

<h2>[[#[[doclookup?alias=`[[++admin_page_alias]]`]].tv.footerSocialTitle]]</h2>

Our custom snippet gets the resource id of a resource in the tree. So the context setting admin_page_alias might be administration.html.

That way we avoid duplicating settings for every context.

That's similar to what I do, but instead of fastField I use getResourceField and instead of a custom snippet I use a context setting to specify which resource holds the settings for each language/context.

[[getResourceField? &id=`[[++mySettings]]` &field=`settingFacebook` &isTV=`1`]]

Would replacing getResourceField with fastField improve performance noticeably if I have a a bunch of calls per page?

[[#[[++mySettings]].settingFacebook]]

Also, there's pdoField, which does the same thing:

[[pdoField? &id=`[[++mySettings]]` &field=`settingFacebook`]]

I wonder which would be the best option (whilst waiting for ClientConfig to be made context sensitve of course)?

It would be interesting to know which one performs the best. I have no idea.

Quote from: sottwell at Jan 29, 2014, 03:20 AM

You could also avoid the situation altogether for multi-language sites by using migxMultiLang instead of contexts.

We like using contexts for different languages as we have abstracted interfaces elements in lexicon files and all of our templates use these extractions. Furthermore, each context has a bunch on unique settings as well as unique URLs, not to mention being isolated so that content publishers can only edit their site.

There are advantages to both systems. It all depends on your requirements. For just a basic multi-language site, migxMultiLang will be by far quicker and easier to implement and manage for most cases. If you need all the features you've mentioned, which actually sounds more like distinct sites for each language, then of course the context method is best for you. Having more choices, as well as knowing what your options are, is always good.

Since migxMultiLang is based on TVs, they can be assigned to groups, thus providing a means of restricting editors to their own languages.

Yes, I understood that different ways for different requirements. Moving to a single context model would be more work than it's worth given how we've structured things. We have significant regional differences (i.e. certain things appear for certain regions, certain backgrounds are different, etc) which is easily done with context settings.

Well, as far as ClientConfig being context-sensitive, for now the only thing that comes to mind is to use CC groups, or if you're already using groups us a naming convention for the groups to indicate which context a group is for.

Context-aware CC would be difficult. While it does load the key->value pairs into the $modx->cofig array for using in code, it only emulates system settings tags by using + as the prefix for its own placeholders, thus allowing the use of [[++value]] as if it were really a system settings tag.

It wouldn't be too difficult to set up a tabbed interface by context, allowing only users with permissions to a context to see a tab, nor adding an extra "context" field to the database table so the plugin would know which context's config array to add values to. But getting the ordinary placeholders to be context-aware would be quite a bit more complicated.