We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 44909
    • 13 Posts
    Hi!

    Trying to upgrade from 2.2.9 to 2.2.10 on a test installation, I stumbled upon another strange problem.
    Since I do not know, if this problem is related to another problem I just posted (2.2.10 installation quirks / empty username column after installation), I start a new thread for this one.

    I ran into this problem when upgrading from 2.2.9 to 2.2.10, but it seems that can it be reproduced (at least on my system) with a fresh install of 2.2.10.

    To my mind, it should be possible to do an upgrade installation on a fresh install.
    So I perform a fresh install and leave the setup folder in place.

    If I click "next" while "Upgrade Existing Install" is selected I get the error:

    Database connection failed!
    Setup will attempt to create the database.

    Strange thing is, that left to "Database connection failed" is a green icon, while the message itself is written in red.
    Anyway the following error pops up in the install log:

    [2013-10-24 08:32:45] (ERROR in xPDOConnection::connect @ /var/www/default/wwwroot/tools/modx/core/xpdo/xpdo.class.php : 3051) SQLSTATE[HY000] [1044] Access denied for user ''@'localhost' to database 'modx'
    


    This is strange, because the user should be "modx_dummy" on database "modx_dummy".

    The page and the manager work fine at this stage!
    If I add

    $this->xpdo->log(xPDO::LOG_LEVEL_ERROR, print_r($this->config, true), '', __METHOD__, __FILE__, __LINE__);
    


    just before the creation of the xpdo object in core/xpdo/xpdo.class.php, I get

    [2013-10-24 08:44:04] (ERROR in xPDOConnection::connect @ /var/www/default/wwwroot/tools/modx/core/xpdo/xpdo.class.php : 3049) Array
    (
        [cache_path] => /var/www/default/wwwroot/tools/modx/core/cache/
        [table_prefix] => modx_
        [setup] => 1
        [dbtype] => mysql
        [host] => localhost
        [dbname] => modx
        [charset] => utf8
        [dsn] => mysql:host=localhost;dbname=modx;charset=utf8
        [username] =>
        [password] =>
        [driverOptions] => Array
            (
                [3] => 0
            )
    
    )
    
    


    in the log.

    These are obviously not the correct credentials and I don't know where these come from, since the page + manager work fine.

    Any ideas?

    Greetings

    Nico


      • 44909
      • 13 Posts
      Hi again!

      Just a few minutes after my post I found a way to get it working.

      If I delete the cache while on the "Install Options" page, everything works fine.
      Since this seems rather strange, I analyzed the cache contents step by step.

      Here is what happens (cache folder completely empty):


      1. navigate to "/setup" -> smarty cache appears (with header footer 'n stuff)
      2. click next -> "Welcome to the MODX..." -> settings.cache.php is written (with wrong db name and empty credentials)
      3. next -> "Install options" -> cache does not seem to change
      4. next with upgrade selected -> "Installation summary" with failed db connection

      If I delete the settings.cache.php on the third step, it gets recreated, this time with correct database settings and everything goes fine.

      Here is the content from the "wrong" settings.cache.php from the second page (note: I deleted the http_host):

      <?php if(time() > 1382598879){return array();} return array (
        'https_port' => '443',
        'http_host' => '************',
        'database_type' => 'mysql',
        'database_server' => 'localhost',
        'database_connection_charset' => 'utf8',
        'database_charset' => 'utf8',
        'dbase' => 'modx',
        'database_user' => '',
        'database_password' => '',
        'table_prefix' => 'modx_',
        'site_sessionname' => 'SN5268c55bb7e01',
        'cache_disabled' => 'false',
        'inplace' => 0,
        'unpacked' => 0,
        'config_options' => 
        array (
        ),
        'driver_options' => 
        array (
        ),
        'context_web_path' => '/var/www/default/wwwroot/tools/modx/',
        'context_web_url' => '/tools/modx/',
        'context_mgr_path' => '/var/www/default/wwwroot/tools/modx/manager/',
        'context_mgr_url' => '/tools/modx/manager/',
        'context_connectors_path' => '/var/www/default/wwwroot/tools/modx/connectors/',
        'context_connectors_url' => '/tools/modx/connectors/',
        'core_path' => '/var/www/default/wwwroot/tools/modx/core/',
        'web_path' => '/var/www/default/wwwroot/tools/modx/',
        'web_url' => '/tools/modx/',
        'mgr_path' => '/var/www/default/wwwroot/tools/modx/manager/',
        'mgr_url' => '/tools/modx/manager/',
        'connectors_path' => '/var/www/default/wwwroot/tools/modx/connectors/',
        'connectors_url' => '/tools/modx/connectors/',
        'web_path_auto' => 0,
        'web_url_auto' => 0,
        'mgr_path_auto' => 0,
        'mgr_url_auto' => 0,
        'connectors_path_auto' => 0,
        'connectors_url_auto' => 0,
        'processors_path' => '/var/www/default/wwwroot/tools/modx/core/model/modx/processors/',
        'assets_path' => '/var/www/default/wwwroot/tools/modx/assets/',
        'assets_url' => '/tools/modx/assets/',
        'database_dsn' => 'mysql:host=localhost;dbname=modx;charset=utf8',
        'language' => 'en',
        'server_dsn' => 'mysql:host=localhost;charset=utf8',
      );
      


      Any ideas why the cache gets populated with the wrong settings (or maybe not wrong but "standard")?

      Greetings

      Nico
        • 44909
        • 13 Posts
        Hi!

        As stated in another thread, disabling opcache seems to help during weird installation problems.
        Same applies here. I disabled opcache, and the upgrade installation runs without problems.

        I wonder, if it is save to turn on opcache for regular operation of the site. I'll leave it off for now.

        In the long run, this isn't an option though, since working without opcode cache is a pain in the a**.
        Could try another opcode cacher, though...

        Greetings

        Nico
          • 40404
          • 21 Posts
          I don't have an answer for you, but thank you for this post! Was upgrading from 2.2.8 to 2.2.11 with the same problem (XPDO was trying to use the user 'apache'!) Clearing the cache at the Install Options step took care of the problem.
            • 23491 ☆ A M B ☆
            • 1,056 Posts
            FYI -- Was just bit by this one as well, upgrading to 2.2.12-pl. Setup was not pulling in the config.inc.php correctly, at least until opcache extension was disabled.

            This was on a development server, PHP 5.3.28 and ZendOpcache 7.0.3
              Mike Reid - www.pixelchutes.com
              MODx Ambassador / Contributor
              [Module] MultiMedia Manager / [Module] SiteSearch / [Snippet] DocPassword / [Plugin] EditArea / We support FoxyCart
              ________________________________
              Where every pixel matters.