We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
MODX Community Forums Archive

ClientConfig: Custom configuration CMP for clients

  • Mark Hamstra Reply #31, 10 years, 5 months ago
    Added to the list: https://github.com/Mark-H/ClientConfig/issues/61

    And 1.2 is now also available from MODX.com: http://modx.com/extras/package/clientconfig [ed. note: markh last edited this post 10 years, 5 months ago.]
      Mark Hamstra • Developer spending his days working on Premium Extras and a MODX Site Dashboard with the ability to remotely upgrade MODX and extras to make the MODX world a little better.

      Tweet me @mark_hamstra, check my infrequent blog at markhamstra.com, my slightly more frequent ramblings at MODX.today or see code at Github.
      • 36686
      • 165 Posts
      sketchi Reply #32, 10 years, 5 months ago
      Fab!
      • rx2 Reply #33, 10 years, 5 months ago
        Is it context sensitive now?
          • 36686
          • 165 Posts
          sketchi Reply #34, 10 years, 5 months ago
          Quote from: rx2 at Nov 15, 2013, 12:23 AM
          Is it context sensitive now?

          I would be interested in this too, to be able to use ClientConfig for multi-language sites. If it's NOT context sensitive though, I guess one could create separate configuration settings for the various languages and name them things like en.footerText, se.footerText etc., and put this in the templates:

          [[++[[++cultureKey]].footerText]]


          It would be a bit of a hassle having to duplicate the configuration settings for all languages if you have lots of them, but as a workaround it should work, shouldn't it?
          • Mangesh Reply #35, 10 years, 5 months ago
            Hey Mark,

            Thanx for the fantabolous extra. I really like it.

            I have a feature request:

            1) If else conditional TV.

            Eg: A logo can be text or image. So a primary tv with select dropdown list: Image or Text. If its image, it sould add another child tv with imagetv, and texttv for text.

            2) Import/Expert settings.

            Regards,
            Mangesh
              Developing Themes/Templates for MODx Revo. Visit http://mdxthemes.com
            • Mark Hamstra Reply #36, 10 years, 5 months ago
              Quote from: rx2 at Nov 15, 2013, 12:23 AM
              Is it context sensitive now?

              Nope, though I'll gladly review pull requests if someone has a clear idea of how that should be implemented. I think it would add a lot more complexity.



              Quote from: sketchi at Nov 15, 2013, 09:45 AM
              Quote from: rx2 at Nov 15, 2013, 12:23 AM
              Is it context sensitive now?

              I would be interested in this too, to be able to use ClientConfig for multi-language sites. If it's NOT context sensitive though, I guess one could create separate configuration settings for the various languages and name them things like en.footerText, se.footerText etc., and put this in the templates:

              [[++[[++cultureKey]].footerText]]


              It would be a bit of a hassle having to duplicate the configuration settings for all languages if you have lots of them, but as a workaround it should work, shouldn't it?

              That would definitely work.
                Mark Hamstra • Developer spending his days working on Premium Extras and a MODX Site Dashboard with the ability to remotely upgrade MODX and extras to make the MODX world a little better.

                Tweet me @mark_hamstra, check my infrequent blog at markhamstra.com, my slightly more frequent ramblings at MODX.today or see code at Github.
              • rx2 Reply #37, 10 years, 5 months ago
                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.
                  • 36686
                  • 165 Posts
                  sketchi Reply #38, 10 years, 5 months ago
                  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)? [ed. note: sketchi last edited this post 10 years, 5 months ago.]
                  • Mark Hamstra Reply #39, 10 years, 5 months ago
                    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?
                      Mark Hamstra • Developer spending his days working on Premium Extras and a MODX Site Dashboard with the ability to remotely upgrade MODX and extras to make the MODX world a little better.

                      Tweet me @mark_hamstra, check my infrequent blog at markhamstra.com, my slightly more frequent ramblings at MODX.today or see code at Github.
                    • sottwell Reply #40, 10 years, 3 months ago
                      You could also avoid the situation altogether for multi-language sites by using migxMultiLang instead of contexts.
                        Studying MODX in the desert - http://sottwell.com
                        Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
                        Join the Slack Community - http://modx.org