We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 577
    • 132 Posts
    Can anyone explain line 70? Why do we preg match between {….} . What is the significants of the { }

    Maybe I am just using the system in a way that it was not intended. However I know I have not been the only one plagued by this.

    Issue is on line 70

    if (preg_match_all('~\{(.*?)\}~', $v, $matches, PREG_SET_ORDER)) {
    


    I am sure there must be a reason for the {..} , however this causes a json string that is all on a single line to get messed up when written to cache array because the { MATCHING } implodes the json string (for lack of a better definition). If the match was on [[ .. ]] I get it but not {..}

    The only solution thus far has been to make sure the json string is fully formatted with \n so that { is always followed by \n. However this is not an option when the json is created by encoding an array.

    I have tested a confirmed a working solution .. though I am sure a regExpert would know how to write but not I.

    My solution is to skip if json , but not knowing the significants of the whole preg_match {} I am not sure if I am breaking anything

    
    $v= $setting->get('value');
    if(!json_decode($v)){  /* <-- ADDED JSON CHECK */
        $matches = array();
        if (preg_match_all('~\{(.*?)\}~', $v, $matches, PREG_SET_ORDER)) {
            foreach ($matches as $match) {
                if (array_key_exists("{$match[1]}", $contextConfig)) {
                    $matchValue= $contextConfig["{$match[1]}"];
                } else {
                    $matchValue= '';
                }
                $v= str_replace($match[0], $matchValue, $v);
           }
        }
    } else { /*its json string do nothing */ } 
    $results['config'][$k]= $v;
    
    
    [ed. note: aesmith last edited this post 12 years, 6 months ago.]
      "One of these days I will get around to my own website... Its only been about 12 years... maybe tomorrow smiley"
      • 3749
      • 24,544 Posts
      Would you please report that as a bug here: https://github.com/modxcms/revolution/issues
        Did I help you? Buy me a beer
        Get my Book: MODX:The Official Guide
        MODX info for everyone: http://bobsguides.com/modx.html
        My MODX Extras
        Bob's Guides is now hosted at A2 MODX Hosting
        • 577
        • 132 Posts
        So I have found out the usage and purpose behind the {}. There are not so well know tags in MODX for at cache replace. I got a reply back from Jason Coward on Twitter on this and he reminded me of it. You don't see if used much but in places like namespace and stuff you will see {base_url} and {asset_url} ... thats what this logic is for. But it means JSON can not be properly used safely as a value for a Context or System Setting.

        So do we call this a bug or a byproduct of the {} that just is.

        Shall I log as a bug or a feature request?

        As a intermediate solution I would really like to not hack the base code with my quick fix. Does anyone have an suggestions how I might be able to overload these methods or maybe use my own outside the core copy of the the same class that I then tweek. I would not want my tweek to get lost in a upgrade.

        I believe through XPDO connection I can pass in my own cache manager but never done it before.

        Adam
          "One of these days I will get around to my own website... Its only been about 12 years... maybe tomorrow smiley"
          • 577
          • 132 Posts
          To answer a portion on my own question above to help steer others in the right direction the way you override the cache manager is by passing in the FQN Class on the config options of the config.inc.php

          $config_options = array (
          'modCacheManager.class' => 'myModCacheManager'
          );
          


          That being said I could not get the class to resolve and override under the xpdo/om dir after much head banging but then it all fails after that. My guess is that since I am just coping the modCacheManager class but then trying to run it under XPDO its looking for things the modx class has that have not yet bee initialized. I had zero luck getting it to initialize at the modx level.

          I gave up and just hacked the core for now. I will put bug report and hopefully we can solve this in future releases

          Line 70 and 235 , I added !json_decode($v) &&
          if (!json_decode($v) && preg_match_all('~\{(.*?)\}~', $v, $matches, PREG_SET_ORDER)) {
          


          Here is the issue noted on github
          https://github.com/modxcms/revolution/issues/11235 [ed. note: aesmith last edited this post 12 years, 6 months ago.]
            "One of these days I will get around to my own website... Its only been about 12 years... maybe tomorrow smiley"
            • 3749
            • 24,544 Posts
            I don't know how well they would serve your purpose, but there are various other places to store JSON data. You could store it in a set of TVs or in one or more files. Probably the best place would be in the properties of a resource or element. You could create a new chunk just to hold the settings (or one chunk for each context). Settings are automatically converted to JSON when you save them and back into a PHP associative array when you retrieve them.

            Another option might be to perform some kind of reversible transform (base64_encode() or urlencode()?) on the JSON string before storing it as a System or Context Setting.
              Did I help you? Buy me a beer
              Get my Book: MODX:The Official Guide
              MODX info for everyone: http://bobsguides.com/modx.html
              My MODX Extras
              Bob's Guides is now hosted at A2 MODX Hosting
              • 577
              • 132 Posts
              Quote from: BobRay at Mar 25, 2014, 09:05 PM
              I don't know how well they would serve your purpose, but there are various other places to store JSON data. You could store it in a set of TVs or in one or more files. Probably the best place would be in the properties of a resource or element. You could create a new chunk just to hold the settings (or one chunk for each context). Settings are automatically converted to JSON when you save them and back into a PHP associative array when you retrieve them.

              Another option might be to perform some kind of reversible transform (base64_encode() or urlencode()?) on the JSON string before storing it as a System or Context Setting.

              Thanks BobRay that was were my thoughts were leading me next. I am looking for the most optimal way to store at a context level. I am actually going to parse the json and add to placeholders OnInit so I guess it really doesn't matter where it goes except that I am trying to keep the standard webdevs out of it.

              Basically what I have is a MIGX based interface that allows dev to configure site (kind like ClientConfig but for multi-context) that then stores the json in a system setting xtype = display-only. That way they have to run back through the MIGX Site builder with our own custom processors that controls what they can and can't do.

              MIGX is the quick solution so that I don't have to write my own CMP for now.

              Thanks for getting my my ideas flowing again. I was on the path to encoding or simply char sub and I think I may just do that.
                "One of these days I will get around to my own website... Its only been about 12 years... maybe tomorrow smiley"
                • 577
                • 132 Posts
                To complete this post.

                I have opted for base64() in context settings over urlencode() because:

                It has a smaller footprint
                Leaves less chance of misinterpretation that it has anything to do with a URL or querystring
                Unreadable at a glance so no dev is going to try to read the encoded data and use it as is
                  "One of these days I will get around to my own website... Its only been about 12 years... maybe tomorrow smiley"