We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 43371
    • 17 Posts
    Description of Problem:
    When trying to filter Context Settings (in the System/Contexts menu) to a specific sub-area on my development environment I get a JavaScript crash because of an attempt to parse a JSON array that is in fact a PHP warning string. The warning string consists of multiple "Array to String conversion" errors in calls to 'bindValue' in the 'bind' function of xPDOCriteria. This in turn can be traced back to the parseConditions function in xPDOQuery.

    The parseConditions function has two main paths, depending on the results of this test:
    if (isset ($conditions[0]) && !$this->isConditionalClause($conditions[0]) && is_array($pk) && count($conditions) == count($pk)) {

    In the specific case I'm seeing, there are two conditions (context and area), but the primary key for the table also has two columns (context_key and key), so the code follows the 'true' path of the 'if' statement. I think it's making an assumption that if the number of conditions matches the number of columns in the primary key, then the conditions are for the primary key.

    But this isn't true here...

    So the code doesn't split up the $condition[i] (which is an array) into its key/value pair, and instead binds $field['binding']['value'] to the whole $condition[i] - which ultimately gets passed to the 'bindValue' function as its 'value' parameter - which cannot be an array.

    Does anyone know what the logic in this 'if' clause is meant to be doing?

    Cheers!


    • MODX Version: 2.2.7
    • PHP Version: 5.4
    • Database Version: SQL Server (but the code path above is the same for MySql)
    • Additional Server Info: Windows 7, IIS 7.5
    • Installed MODX Add-ons:
      • 43371
      • 17 Posts
      As a brief follow-up I've tried commenting out the entire 'if' branch of the aforementioned if/else clause, and the more general 'else' branch appears to work fine - no more 'Array to string conversion' warnings and no more crashing front end.

      I've opened bug 9864 to cover this.
        • 18373 ☆ A M B ☆
        • 3,141 Posts
        I can't seem to replicate this on my local MySQL install; might be something specific to sqlsrv, maybe in the listSettings method in core/model/modx/sqlsrv/modcontextsetting.class.php?
          Mark Hamstra • Developer spending his days working on Premium Extras and a MODX Site Dashboard with the ability to remotely upgrade MODX and extras to make the MODX world a little better.

          Tweet me @mark_hamstra, check my infrequent blog at markhamstra.com, my slightly more frequent ramblings at MODX.today or see code at Github.
          • 43371
          • 17 Posts
          I've installed Revo 2.2.7 on another machine that's running MySql (also Windows 7, IIS 7.5, PHP 5.4) and see the exact same issues on the back end (array to string conversion warnings) although for some reason what gets passed through to the front end is not the collection of PHP warnings but some other string that causes a JavaScript syntax error. The steps I take to reproduce this are:

          • Select System->Context Settings
          • Right click the 'mgr' context and select 'Update Context'
          • Select the Context Settings tab - you should see a couple of context settings there (on a clean, default, installation) - these settings are under the 'System and Server' area, so you should be able to select the 'Filter by area' drop down and select the 'System and Server' option (you may need to scroll down to see it)
          • At this point, a 'Loading' spin-wheel comes up and the front end just stops there, unless you enable JavaScript debugging, in which case it will bomb out with a syntax error.
          On the back end, provided you've enabled PHP error and warning logging, you should see in the log file the same 'Array to string conversion...' warnings.

          I've looked through the code and the MySql and SqlSvr versions seem very similar - I'm convinced that the parseConditions function is fundamentally wrong in that 'if' clause I mention above.

          Cheers,

          Andy
            • 18373 ☆ A M B ☆
            • 3,141 Posts
            Ah.. at a second look I'm indeed getting this as well (using MySQL), it just doesn't manifest itself in the manager due to configuration.

            [02-May-2013 11:23:50 UTC] PHP Notice:  Array to string conversion in /Applications/MAMP/htdocs/modx-stable2/core/xpdo/xpdo.class.php on line 2754
            [02-May-2013 11:23:50 UTC] PHP Stack trace:
            [02-May-2013 11:23:50 UTC] PHP   1. {main}() /Applications/MAMP/htdocs/modx-stable2/connectors/context/setting.php:0
            [02-May-2013 11:23:50 UTC] PHP   2. modConnectorRequest->handleRequest() /Applications/MAMP/htdocs/modx-stable2/connectors/context/setting.php:3
            [02-May-2013 11:23:50 UTC] PHP   3. modConnectorRequest->prepareResponse() /Applications/MAMP/htdocs/modx-stable2/core/model/modx/modconnectorrequest.class.php:66
            [02-May-2013 11:23:50 UTC] PHP   4. modConnectorResponse->outputContent() /Applications/MAMP/htdocs/modx-stable2/core/model/modx/modconnectorrequest.class.php:79
            [02-May-2013 11:23:50 UTC] PHP   5. modX->runProcessor() /Applications/MAMP/htdocs/modx-stable2/core/model/modx/modconnectorresponse.class.php:131
            [02-May-2013 11:23:50 UTC] PHP   6. modProcessor->run() /Applications/MAMP/htdocs/modx-stable2/core/model/modx/modx.class.php:1631
            [02-May-2013 11:23:50 UTC] PHP   7. modDeprecatedProcessor->process() /Applications/MAMP/htdocs/modx-stable2/core/model/modx/modprocessor.class.php:173
            [02-May-2013 11:23:50 UTC] PHP   8. include() /Applications/MAMP/htdocs/modx-stable2/core/model/modx/modprocessor.class.php:343
            [02-May-2013 11:23:50 UTC] PHP   9. xPDO->call() /Applications/MAMP/htdocs/modx-stable2/core/model/modx/processors/context/setting/getlist.php:49
            [02-May-2013 11:23:50 UTC] PHP  10. call_user_func_array() /Applications/MAMP/htdocs/modx-stable2/core/xpdo/xpdo.class.php:736
            [02-May-2013 11:23:50 UTC] PHP  11. modContextSetting_mysql::listSettings() /Applications/MAMP/htdocs/modx-stable2/core/xpdo/xpdo.class.php:736
            [02-May-2013 11:23:50 UTC] PHP  12. xPDO->getCollection() /Applications/MAMP/htdocs/modx-stable2/core/model/modx/mysql/modcontextsetting.class.php:36
            [02-May-2013 11:23:50 UTC] PHP  13. xPDO->call() /Applications/MAMP/htdocs/modx-stable2/core/xpdo/xpdo.class.php:841
            [02-May-2013 11:23:50 UTC] PHP  14. call_user_func_array() /Applications/MAMP/htdocs/modx-stable2/core/xpdo/xpdo.class.php:736
            [02-May-2013 11:23:50 UTC] PHP  15. xPDOObject::loadCollection() /Applications/MAMP/htdocs/modx-stable2/core/xpdo/xpdo.class.php:736
            [02-May-2013 11:23:50 UTC] PHP  16. xPDOObject::_loadRows() /Applications/MAMP/htdocs/modx-stable2/core/xpdo/om/xpdoobject.class.php:479
            [02-May-2013 11:23:50 UTC] PHP  17. xPDOQuery->prepare() /Applications/MAMP/htdocs/modx-stable2/core/xpdo/om/xpdoobject.class.php:233
            [02-May-2013 11:23:50 UTC] PHP  18. xPDOCriteria->bind() /Applications/MAMP/htdocs/modx-stable2/core/xpdo/om/xpdoquery.class.php:612
            [02-May-2013 11:23:50 UTC] PHP  19. PDOStatement->bindValue() /Applications/MAMP/htdocs/modx-stable2/core/xpdo/xpdo.class.php:2754 
              Mark Hamstra • Developer spending his days working on Premium Extras and a MODX Site Dashboard with the ability to remotely upgrade MODX and extras to make the MODX world a little better.

              Tweet me @mark_hamstra, check my infrequent blog at markhamstra.com, my slightly more frequent ramblings at MODX.today or see code at Github.
              • 22303 MODX Staff
              • 10,725 Posts
              I believe adding one additional check to make sure the first condition value of the array is a scalar will resolve this. See https://github.com/modxcms/xpdo/commit/36d9454abf83f3773f88c7a7c6a7194e8329e2c8 for the possible solution.