We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 25663 MODX Staff
    • 12,272 Posts
    Sure enough: http://modxcms.com/forums/index.php/topic,3162.0.html

    When replacing it with the PHP4 compatible version, things worked out just fine. smiley
    Now, that means we need to update the default one to work with PHP4!
      Ryan Thrash, MODX Co-Founder
      Follow me on Twitter at @rthrash or catch my occasional unofficial thoughts at thrash.me
      • 25663 MODX Staff
      • 12,272 Posts
      For anyone interested, here’s a quick link to Raymond’s documentation on the recursive parser:
      http://modxcms.com/forums/index.php?action=dlattach;topic=5265.0;attach=2747
        Ryan Thrash, MODX Co-Founder
        Follow me on Twitter at @rthrash or catch my occasional unofficial thoughts at thrash.me
        • 22815
        • 1,097 Posts
        Hmmn, I’m getting
        Fatal error: Call to undefined function: parsetext() in /home/web/modx095/manager/includes/document.parser.class.inc.php on line 711
        on a reinstall. I’ll double check I’ve copied all the files and that I have the latest stuff in the morning. Can someone confirm that they’ve gotten this to work on a reinstall? Everyone seems to have ended up doing a new install.
          No, I don't know what OpenGeek's saying half the time either.
          MODx Documentation: The Wiki | My Wiki contributions | Main MODx Documentation
          Forum: Where to post threads about add-ons | Forum Rules
          Like MODx? donate (and/or share your resources)
          Like me? See my Amazon wishlist
          MODx "Most Promising CMS" - so appropriate!
          • 6726
          • 7,075 Posts
          Quote from: xwisdom at Aug 20, 2006, 03:44 PM
          Recursive parser (beta2) now added to the trunk. Please test to see if all works and performs well.
          Update: After addint the new parser you must refresh your site.

          I am a little late to the party, but I’ll make sure to give this a test run !
            .: COO - Commerce Guys - Community Driven Innovation :.


            MODx est l'outil id
            • 32963
            • 1,732 Posts
            Hi Everyone,

            Many thanks.

            Let me see if I can use one post to respond to all the questions asked.

            The parser now requires to additional cache files: siteSnippets.cache.php and sitePlugins.cache.php. These files are used to store your plugin and snippet codes inside a function. With this new type of caching php will detect and display syntax errors on the front-end if the when the follow evaluates to true:

            // Don't show PHP errors to the public
            if(!$_SESSION['mgrValidated']) @ini_set("display_errors","0");
            


            If the above evaluates to false then a blank page will be displayed.

            @Jason: It would apear that you had two plugins with the same name inside the database? I think the name generation section of the cache file might a little tweaking.

            @Paul: the parseText() function belong to the Parser class object. You might want to make sure that the file /manager/includes/extenders/parser.class.php does exists and that you have permission to execute it.

            A few other things to note:
            * Changed typo in checkPublishStatus from publihsedby to publishedby
            * I’m not too sure I’m for Fix #307 which forces any <html> within the text input TV to be converted to htmlentities.
            * I’ve noticed that $this->db->connect(); was called inside executeParser function. Any reason for this? IMO this means that the system will always make a connection to the db even if it’s not needed, correct?


              xWisdom
              www.xwisdomhtml.com
              The fear of the Lord is the beginning of wisdom:
              MODx Co-Founder - Create and do more with less.
              • 28042 ☆ A M B ☆
              • 24,524 Posts
              * I’ve noticed that $this->db->connect(); was called inside executeParser function. Any reason for this? IMO this means that the system will always make a connection to the db even if it’s not needed, correct?

              The index.php file calls the executeParser function, and first thing, the parser has to go to the database to get information on that page. Even if the page turns out to be a css document or something and doesn’t need parsing, how does the parser know this until it gets the information from the database? And even if it is a css document, the parser still has to get the document’s content from the database. I don’t see any instance of index.php, or the parser itself, being requested where it doesn’t need to get something from the database.
                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
                • 22815
                • 1,097 Posts
                Ah, it only shows errors when I’m logged in. As I understand it, there are plans for the 1.0 Manager to be written "in" MODx, and would thus need to use the parser in order to show the log in screen. So add one to the "Writing Manager In MODx Itself Potentially Bad Idea" column.

                Quote from: xwisdom at Aug 20, 2006, 06:23 PM

                @Paul: the parseText() function belong to the Parser class object. You might want to make sure that the file /manager/includes/extenders/parser.class.php does exists and that you have permission to execute it.

                I have /manager/includes/extenders/parser.class.php; and I’ve made sure I have permission to execute it.
                I’ve searched through all the files and eventually found that the file is loaded by this reference:
                		$this->loadExtension('Parser');
                

                Thus the reason it didn’t work for me - on a Linux server - is that loadExtension looks for..
                if(!file_exists($xpath.$extname.'.class.php')) return false;
                

                and didn’t find "Parser.class.php", because it doesn’t understand that this is the same as "parser.class.php", and that part of the code doesn’t raise an error.

                Please change line 550 of document.parser.class.inc.php to $this->loadExtension(’parser’); - and please can we all remember that case matters. Am I the only one testing on a Linux box?

                Quote from: xwisdom at Aug 20, 2006, 06:23 PM

                The parser now requires two additional cache files: siteSnippets.cache.php and sitePlugins.cache.php
                I know this is obvious, but these need to be added to the Clear Cache function. Presently, hitting that button doesn’t clear out these files.
                  No, I don&#39;t know what OpenGeek&#39;s saying half the time either.
                  MODx Documentation: The Wiki | My Wiki contributions | Main MODx Documentation
                  Forum: Where to post threads about add-ons | Forum Rules
                  Like MODx? donate (and/or share your resources)
                  Like me? See my Amazon wishlist
                  MODx "Most Promising CMS" - so appropriate!
                  • 25663 MODX Staff
                  • 12,272 Posts
                  Hey Paul... nice finds. I’ve done some cursory tests on OS X localhost and didn’t run into those problems. The next step was to upgrade a testing site running on a Linux server.

                  Why would writing a manager in MODx be a potentially bad idea based on an early beta test of brand new functionality?
                    Ryan Thrash, MODX Co-Founder
                    Follow me on Twitter at @rthrash or catch my occasional unofficial thoughts at thrash.me
                    • 28042 ☆ A M B ☆
                    • 24,524 Posts
                    I’ve been thinking about it, and I can’t think of very many things you can do in the Manager that don’t require access to the database; in fact, the manager/index.php file makes its own database connection before it does anything else. So maybe the parser’s connection could be wrapped in a conditional block, or else if the Manager is actually done with MODx then the connection in the index.php file wouldn’t be necessary.
                      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
                      • 22303 MODX Staff
                      • 10,725 Posts
                      Further, if we go with db-based session management, which is virtually a required option for serious scalability, every request is dependent on the db anyway. With some intellegent error handling, we can find ways to serve alternate content if/when db access is not available, and getting the connection to the database should be as simple as instantiating the modx object in the manager index.php. In fact, MODx itself is just a class derived from PDO in my 1.0 branch (class modX extends xPDO), so at it’s simplest, most basic level, the future central MODx class is nothing more than a db access controller with content-management specific attributes and behavior added to it.