We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 10746
    • 126 Posts
    Before I start working in earnest with MODx, I’m working through the things I need figuring out the basics and doing some simple "proof of concept" things..

    One thing that I want to do is to integrate some existing PHP scripts into it, but I have a mental block on how the variables work.

    Here is the situation: outside MODx, I have two PHP programs "input.php" and "output.php" - the input.php script produces an HTML form that the user fills in, and then the values are passed as POST variables to "output.php". The "output.php" script looks up some values in a MySQL database and formats the output.


    Now, I can certainly create a MODx page with the HTML form on it, and I can create a snippet that does the work of output.php - but what I can’t see is how to "connect them together" so that the variables that my form creates arrive at the snippet... what would I specify as the "target" for the form submission? If I specify the MODx page containing my snippet, then can the snippet access $_POST, and will it contain just "my" variables or will there be a whole pile of other variables to do with MODx.

    I know I’m not expressing this well, but hopefully somebody can see what I’m getting at..

    Thanks

    Gordon
      • 7923
      • 4,213 Posts
      You can create the input.php as one snippet and output.php as one like you say and then put those in separate documents and in the input.php snippet form target set the document that has the output.php snippet running what then get’s the form data from $_POST..

      I would do the input and output in one and same snippet though.. in the snippet, you could have if ($_POST[’submit’]) {..} check or something that checks if the form is submitted or not. If it’s not, it would output the form with current document as target [~[*id*]~].. and if it is, it would process the user inputted data and output any error messages (and the form in that case) or redirect to some success document or something..


        "He can have a lollipop any time he wants to. That's what it means to be a programmer."
        • 10746
        • 126 Posts
        Quote from: doze at Nov 11, 2006, 06:25 PM

        You can create the input.php as one snippet and output.php as one like you say and then put those in separate documents and in the input.php snippet form target set the document that has the output.php snippet running what then get’s the form data from $_POST..

        OK thanks... it sounds too easy to be true..

        I think I don’t fully understand how MODx constructs a page - in other words what happens when a page is requested and MODx puts it together. Does one script just create a PHP page by literal text-replacement of the chunks and snippets and THEN send the whole thing off to be re-parsed by the PHP interpreter? Or does the main "page constructor" actually "call" the snippets and then put the output into the right places?

        I am sure I am just missing one small piece of the jigsaw, but it is annoying me...

        Thanks again - I have found the MODx community just great and hope that I can contribute in return when I learn more..

        Gordon
          • 28042 ☆ A M B ☆
          • 24,524 Posts
          As far as I have been able to figure out, it goes like this (more or less):

          1. index.php initiates an "ob" (ob_start) object, and a new $modx object.
          2. index.php calls calls $modx->executeParser()
          3. parser gets site settings ($modx->config array, such as $modx->config[’site_name’])
          4. parser checks site’s available status and outputs the unavailable page or message if site is unavailable. Done.
          5. parser unpublishes/publishes all documents that need to be published/unpublished at this time.
          6. parser determines from the URL request how to get the page to be parsed (site_start? alias? docID?) and works out the ID of the document it wants.
          7. parser invokes the OnWebPageInit event at this point.
          8. parser invokes the OnLogPageHit event, if track_visitors is set to 1.
          9. parser checks cache, if page is cached loads the cache file into $modx->documentContent and invokes the OnLoadWebPageCache event, and jumps straight to the outputContent function without further parsing.
          10. parser calls getDocument Object, which goes through various access checks, and loads the $modx->documentObject array (such as $modx->documentObject[’pagetitle’]). It also adds the TV tags from the document’s template to the documentObject.
          11. parser determines if page is published, and if not, if the user has permissions to view unpublished documents.
          12. parser determines if page is a "reference" (weblink) and quits with a redirect if it is.
          13. parser gets the document’s template and sets the $modx->documentContent array to the template’s content.
          14. parser invokes the OnLoadWebDocument event. (at this point you can see the template with all the MODx tags).
          15. parser inserts metatags and keywords
          16. parser sets $modx->documentOutput to documentContent (still only the template, no tags parsed yet) and records its length (to see if it needs another pass)
          17. parser invokes the OnParseDocument event.
          18. parser merges the document’s content into documentOutput (the [*content*] tag). As far as I can tell, TVs are also parsed and merged at this time.
          19. parser merges site settings tags into documentOutput (such as [(site_name)] ) and calls parseDocumentSource with documentOutput as an argument.
          20. parseDocumentSource merges chunk content into documentOutput (any MODx tags in the chunk are passed through unchanged for the next pass to deal with).
          21 parseDocumentSource merges snippet output into documentOutput.
          22 parseDocumentSource merges placeholders into documentOutput.
          23 parseDocumentSource checks length of documentOutput, and if it has changed, runs it through parseDocumentSource again (up to maxParserPasses). When either the length doesn’t change, or maxParserPasses is reached, the documentOutput is returned to the parser.
          24. parser inserts any javascript or css blocks (regClientStarupScript() ,etc)
          25 parser sends documentOutput to outputContent function
          26 outputContent deals with uncached snippet calls (coming from a cached document)
          27 outputContent runs through parseDocumentSource again (to parse these uncached snippet calls)
          28 outputContent deals with any more javascript or css blocks (in case the uncached snippet call had any)
          29 outputContent gets rid of any unused placeholder tags
          30 outputContent rewrites any URLs in the content
          31 outputContent sets up content-type and content-disposition headers
          32 outputContent sets up the timing, number of queries values ([^q^] etc)
          33 outputContent invokes the OnWebPagePrerender event
          34 outputContent echoes the final documentOutput. Well, not exactly, since the whole thing has been wrapped in an "ob" object. But that simple "echo $this->documentOutput;" does seem a little anticlimactic.

          And interesting thing you can do is to set $modx->dumpSnippets to 1 (either edit the index.php file or make a plugin) for some debugging information.





            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
            • 31037
            • 358 Posts
            Quote from: sottwell at Nov 12, 2006, 02:55 AM
            As far as I have been able to figure out, it goes like this (more or less):
            Wow, this was really interresting information! This listing should be in the wiki under "development" or advanced or something.

            /Anders
              • 7923
              • 4,213 Posts
              yes, this should go definitely into the wiki, with maybe some code snipplets from the parser from some of the most interesting parts, like how tvs and chunks are merged and that snippets are evaled etc.. Great post!


                "He can have a lollipop any time he wants to. That's what it means to be a programmer."
                • 22303 MODX Staff
                • 10,725 Posts
                Quote from: doze at Nov 12, 2006, 04:02 AM

                yes, this should go definitely into the wiki, with maybe some code snipplets from the parser from some of the most interesting parts, like how tvs and chunks are merged and that snippets are evaled etc.. Great post!

                That’s fine to post this kind of stuff in the wiki; but, keep in mind, the changes coming down the pipe are going to significantly change this internal processing model.
                  • 26435
                  • 1,193 Posts
                  Quote from: OpenGeek at Nov 12, 2006, 12:06 PM

                  That’s fine to post this kind of stuff in the wiki; but, keep in mind, the changes coming down the pipe are going to significantly change this internal processing model.

                  But also keep in mind that there are people using modx now that this information will be very helpful to. I imagine it is not hard to get ahead of yourself when you’re hammering at the beast everyday Jason, but if I were a gambling man, I would bet that the majority of MODx users are using 0.9.2.2 or below. When 0.9.5 officially releases, I don’t know what percentage of them will upgrade right away (or at all if the current installation is working for them). For these people the wiki, and posts like this in the wiki are a terrific resource. Not to mention the burden of repeated questions it can possibly take off the forum, the team, and the moderators. 2¢. I do not want to be offensive to you Jason. I respect you more than most people I know. Please do not read this as insulting or undermining your opinion, that is not the context I am writing it in. I just don’t want it to be confused that this info is going to be useless soon. It is not.

                  -sD-
                    Husband, Father, Brother, Son, Programmer, Atheist, Nurse, Friend, Lover, Fighter.
                    All of the above... in no specific order.


                    I send pointless little messages
                    • 28042 ☆ A M B ☆
                    • 24,524 Posts
                    Well, if somebody wants to put it in the wiki, be my guest. I’m not all that sure of some of the steps, especially exactly where the TVs get parsed. I hope if it does get put in the wiki somebody who knows more about it than I do can correct it.
                      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
                      • 26435
                      • 1,193 Posts
                      I am not even begin to claim that I know more about the order of execution than Susan, but I do love the wiki, so here is the beginning of a wiki post.

                      http://wiki.modxcms.com/index.php/Order_of_execution


                      -sD-
                        Husband, Father, Brother, Son, Programmer, Atheist, Nurse, Friend, Lover, Fighter.
                        All of the above... in no specific order.


                        I send pointless little messages