We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 26903
    • 1,336 Posts
    Ok guys, I haven’t updated today, so I’m in the same state as I was when I found this yesterday, at the point of failure(when ’install’ is pressed) I can confirm that I have no ’settings_version’ in the system_settings table.

    Ok, I’ve updated one of my systems to latest(4532) and the fault seems to persist, I’m getting the same error. still no settings_version in system_settings. Ok, do I need to do a rebuild here?

    BobRay, as far as the backtrace goes this is just a standard install of the Xdebug module with standard settings in its ini file/php.ini file. On Windows using XAMPP the backtrace appears on the web page, on my linux system it doesn’t, it appears in the error.log but the contents areobviously the same. Don’t know why XAMPP is different here.
      Use MODx, or the cat gets it!
      • 3749
      • 24,544 Posts
      Quote from: shamblett at Dec 08, 2008, 02:37 PM

      Ok, I’ve updated one of my systems to latest(4532) and the fault seems to persist, I’m getting the same error. still no settings_version in system_settings. Ok, do I need to do a rebuild here?

      I think the system settings are set during the build, so probably yes.


      BobRay, as far as the backtrace goes this is just a standard install of the Xdebug module with standard settings in its ini file/php.ini file. On Windows using XAMPP the backtrace appears on the web page, on my linux system it doesn’t, it appears in the error.log but the contents areobviously the same. Don’t know why XAMPP is different here.
      Thanks, I’ll give it a try.

      Do you have to do anything special to have MODx running under XDebug, or is that automatic?


        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
        • 30223
        • 1,010 Posts
        For debugging you need a suitable client (editor) but for the backtrace to appear you just need to install xdebug and set some configuration settings in php.ini.

        See http://www.xdebug.org/docs/remote

        I don’t know however if revolution’s set_error_handler overrides this functionality. Question of trying I guess.

          • 3749
          • 24,544 Posts
          I got it to work although it seems to make Apache crash even more often. wink

          @splittingred: The fix didn’t seem to do it. I did a build and cleared the browser cache & cookies, but the update install still crashes and the system setting’s still not in the DB.
            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
            • 26903
            • 1,336 Posts
            I think this line(133) may be the prob,
            this->processResults($this->install->xpdo,$results,$class,$description,$sql);
            in /setup/includes/upgrades/2.00-alpha-1.php

            Its passing an XPDO object as param 1, according to modErrorHandler this should be a MODx object. This may be why its recursing but my eyes are going now!

            OK, commented the line out, install now completes and I can log into the manager OK. Still haven’t got a settings_version in system_settings however.

              Use MODx, or the cat gets it!
              • 28215
              • 4,149 Posts
              Quote from: shamblett at Dec 09, 2008, 04:02 AM

              Its passing an XPDO object as param 1, according to modErrorHandler this should be a MODx object. This may be why its recursing but my eyes are going now!

              Actually, it should be:

              $this->processResults($class,$description,$sql);
              


              I’ve committed a fix in r4534 that should fix this and any other issues you might be having.
                shaun mccormick | bigcommerce mgr of software engineering, former modx co-architect | github | splittingred.com
                • 3749
                • 24,544 Posts
                Thanks!  That solved the install problem, but I still have one site that crashes Apache whenever I access the front end.

                I tracked the problem (finally) to a snippet called in my template.

                Under debug, I get

                [2008-12-09 15:16:10] (FATAL/modx097/index.php) The requested resource has no valid content type specified. RESOURCE: Array ( [id] => 1 [type] => document [contentType] => text/html [pagetitle] => Home [longtitle] => Home Page aardvark smiley hello [description] => [alias] => [link_attributes] => [published] => 1 [pub_date] => 0000-00-00 00:00:00 [unpub_date] => 0000-00-00 00:00:00 [parent] => 0 [isfolder] => [introtext] => [content] => [[Wayfinder? &startId=`0`]] This is the home page. [richtext] => [template] => 1 [menuindex] => 0 [searchable] => 1 [cacheable] => 1 [createdby] => 1 [createdon] => 2008-09-18 16:59:13 [editedby] => 1 [editedon] => 2008-11-02 13:42:10 [deleted] => [deletedon] => 0000-00-00 00:00:00 [deletedby] => 0 [publishedon] => 2008-11-02 13:42:10 [publishedby] => 1 [menutitle] => Home [donthit] => [haskeywords] => [hasmetatags] => [privateweb] => [privatemgr] => [content_dispo] => 0 [hidemenu] => 0 [class_key] => modDocument [context_key] => web [content_type] => 1 ) .

                Here’s the offending snippet (which used to work fine in earlier alphas). I imagine that the snippet is flawed, but it would probably be better if it generated an error message rather than crashing Apache.  wink

                I cut it down to the minimum required to cause the crash:

                /* Keywords  snippet Version 1.0 */
                $pageId = $modx->getDocumentIdentifier('id');
                $pageInfo = $modx->getPageInfo($pageId, 0, 'longtitle');
                


                getPageInfo()  in the modx class now looks like this:

                function getPageInfo($pageid=-1, $active=1, $fields='id, pagetitle, description, alias, class_key, context_key') {
                ...
                }


                Obviously, the number of arguments is way off, but it’s only called three times that I can find in the MODx code and in all cases there are only three arguments given.

                BTW, I’m a refugee from C++, but my understanding is that in PHP, like C++, arguments with default values have to come at the end of the argument list.

                From php.net:" Note that when using default arguments, any defaults should be on the right side of any non-default arguments; otherwise, things will not work as expected."

                I noticed some other default arguments on the left side of the argument list in MODx (notably, the original captcha code) with, IMO, is asking for trouble.


                  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
                  • 16034
                  • 107 Posts
                  There are only three arguments to function getPageInfo(..), they are $pageid, $active and $fields. And they all have default values. ’id, pagetitle, description, alias, class_key, context_key’ is a string, and is the default value for $fields.
                    MODx snippet-glossary 101:
                    Ditto = Content Lister -- Wayfinder == Menu Builder -- Jot = Comment Control
                    • 22303 MODX Staff
                    • 10,725 Posts
                    Quote from: BobRay at Dec 09, 2008, 04:02 PM

                    Here’s the offending snippet (which used to work fine in earlier alphas). I imagine that the snippet is flawed, but it would probably be better if it generated an error message rather than crashing Apache. wink

                    I cut it down to the minimum required to cause the crash:

                    /* Keywords  snippet Version 1.0 */
                    $pageId = $modx->getDocumentIdentifier('id');
                    $pageInfo = $modx->getPageInfo($pageId, 0, 'longtitle');
                    

                    First, getDocumentIdentifier() really is not ever appropriate to call in a snippet, even in 0.9.6.x; it’s an internal method used in processing every request and it changes things that can affect the rest of the request processing. See the examples below for the appropriate ways to do this in Revo...

                    Second, what in the world is the point of getting the page info of the current page? That information is already available, either in the good old fashioned documentObject, i.e.:
                    <?php
                    $id = $modx->documentIdentifier;
                    $longtitle = $modx->documentObject['longtitle'];
                    ?>
                    
                    or preferably, using Revo standards you can refer to the current "Resource" object via $modx->resource, i.e.:
                    <?php
                    /* get the id of the current resource being requested */
                    $id = $modx->resource->id;
                    /* alternate way of getting the id of the current resource being requested */
                    $id = $modx->resourceIdentifier;
                    /* get the longtitle of the current resource being requested */
                    $longtitle = $modx->resource->longtitle;
                    /* another way to get the longtitle of the current resource being requested */
                    $longtitle = $modx->resource->get('longtitle');
                    /* a way to get the id and longtitle of the current resource being requested */
                    $assocArrayOfIdAndLongtitle = $modx->resource->get(array('id', 'longtitle'));
                    /* a way to get the all the attributes of the current resource being requested as an array */
                    $assocArrayOfResourceAttributes = $modx->resource->toArray();
                    /* a way to get the all the attributes of the current resource being requested as a JSON object */
                    $jsonObjectOfResourceAttributes = $modx->resource->toJSON();
                    //etc
                    ?>


                    Quote from: BobRay at Dec 09, 2008, 04:02 PM

                    ...
                    Obviously, the number of arguments is way off, but it’s only called three times that I can find in the MODx code and in all cases there are only three arguments given.
                    ...
                    I think you are misreading the default value of the third parameter. It is called consistently with the three parameters expected from what I see. huh
                      • 3749
                      • 24,544 Posts
                      Quote from: OpenGeek at Dec 09, 2008, 05:24 PM

                      I think you are misreading the default value of the third parameter. It is called consistently with the three parameters expected from what I see. huh

                      Doh! Tired eyes and a small font. I missed the singe quotes there.

                      Thanks for the references (now pinned to my wall).

                      The snippet is definitely flawed (and I usually do know better than to use getDocumentIdentifier() ), but I think my point stands that it would be better if it didn’t crash the server. wink

                      And it might be a good idea to use an underscore ($_getDocumentIdentifier() ) for functions that are for internal use only.
                        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