We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 3177
    • 137 Posts
    Hello MODXers,

    We are building our first websites in MODX Revolution and encounter a small problem with the FormIt snippet.
    In MODX-Revolution we used the eForm snippet. The examples on eForm showed that you had to define three chunks (Form, Report and Thanks) and they work together in the process. In each Chunk you can put HTML code which will not be interpreted.

    In the ’Thanks’-chunk we put Google Adwords Conversion Codes to signal Google Adwords that a Sale is done. That code looks like this:
    <!-- Google Code for Vraag een demo aan Conversion Page -->
    <script type="text/javascript">
    /* <![CDATA[ */
    var google_conversion_id = 9999999999;
    var google_conversion_language = "nl";
    var google_conversion_format = "2";
    var google_conversion_color = "ffffff";
    var google_conversion_label = "XXXXXXXXXXXX";
    var google_conversion_value = 0;
    /* ]]> */
    </script>
    (and some more Javascript code...)
    


    in MODX Revolution we use FormIt.
    the call looks like this:
      [[!FormIt?
        &hooks=`email`
        &emailTpl=`requestDemoReport`
        &emailFrom=`[email protected]`
        &emailTo=`[[$emailAddress?]]`
        &emailSubject = `Email subject`
        &successMessage = `[[$requestDemoThanks?]]`
        &successMessagePlaceholder = `success`
        &validate=`title:required,
          name:required,
          company:required,
          email:required,
      ]]
    

    As you can see, the successmessage is a call to the Thanks-chunk.
    But in Revolution, code in that chunk is also interpreted by the MODX-tag-processor.
    And in the Google Conversion Code there is the following line:
    /* ]]> */
    

    Reason for this code is here: http://javascript.about.com/library/blxhtml.htm

    On the screen we get weird results because of the MODX-tag-interpreter wich picks up the ’]]’ in the Google Conversion Code.

    A solution might be a redirect to a new page but we really don’t want that because the forms are part of the page and then we need to duplicate the page.

    Does anybody have a solution for this?

    Thanks,

    Bert Catsburg

      • 10449
      • 956 Posts
      What happens if you put the JS in an external .js file and just reference it, instead of including it inline?

      e.g.

      <!-- Google Code for Vraag een demo aan Conversion Page -->
      <script type="text/javascript" src="assets/js/google.js"></script>


      If you’d like to still keep it all inside MODx, you can try storing that JS bit in a MODx document, change filetype to JS, and use:
      <script type="text/javascript" src="[~docid~]"></script>


      ^ that’s Evo syntax, check the Revo docs about the appropriate link syntax
        • 3177
        • 137 Posts
        Yes, that is all possible. But that means that I have to change the Google Conversion Code.
        And what we would like is to cut-and-paste the code from Google straight into a Chunk.
        In Evo-eForm that worked ok.
        We don’t like to do some post-processing on the JS code.

        In general the question would be: What if you need XML-CDATA in your content, which closes with ’]]’ and how to prevent the MODX-Tag-Processor to react on the ’]]’.

        Thanks,

        Bert
          • 22303 MODX Staff
          • 10,725 Posts
          First, is this an issue specifically with FormIt or the core?
            • 3177
            • 137 Posts
            Good question.
            We encounter the issue in Formit.
            But support you want to display the following text on your screen
            <script>
            <![CDATA[
            function matchwo(a,b)
            {
            if (a < b && a < 0) then
              {
              return 1;
              }
            else
              {
              return 0;
              }
            }
            ]]>
            </script>
            

            And that text is coming out of a chunk. Then MODX pick up the ’]]’, just like we see in the Formit chunk as described above.
              • 22303 MODX Staff
              • 10,725 Posts
              That works for me in a simple chunk being output to the page; since there is no unclosed bracket before the CDATA end tag, those are skipped by the parser. So perhaps it is a more complex problem that is being described here. Can you provide a little more detail about where the closing CDATA tag is causing the problems? Things like where the chunk is being placed (e.g. is it returned inside another tag)?
                • 3177
                • 137 Posts
                The chunk is called in the successMessage parameter of the Formit snippet.
                Maybe it has something to do with the way Formit processed this successMessage parameter.
                If this is not enough info for you, I will have to do some testing over the weekend and get back to you on this.

                  • 9207 ☆ A M B ☆
                  • 2,475 Posts
                  I ran into this same problem. The easiest solution by far was putting the js into an external file.
                    • 3749
                    • 24,544 Posts
                    Be sure you’re testing with the newest version of FormIt (released last night). There is a change in tag-processing that may factor in.

                    If you have last night’s version, check out line 172 of the formit snippet:

                    $fs[$k] = str_replace(array('[',']'),array('[','&#93'),$v);


                    It should be ’&#93;’ (missing semicolon). That could be causing an unclosed tag there.

                      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
                      • 6437
                      • 157 Posts
                      Quote from: Everett at Dec 10, 2010, 02:27 PM

                      I ran into this same problem. The easiest solution by far was putting the js into an external file.

                      Moving to an external file creates and additional HTTP request, slowing down the site and potentially messing up conversion tracking due to execution timing.