We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 10746
    • 126 Posts
    OK, I have tried everything with no luck. So here is a step-by-step account of what I did...

    Platform Linux (Ubuntu), recent PHP, MySQL 5.0.67

    (1) Download MODx-1.0.0.tar.gz

    (2) Untar the files "tar zxvf MODx-1.0.0.tar.gz" creating folder "modx-1.0.0"

    (3) Change into assets subdir and change permissions on assets subdirectories

    cd modx-1.0.0/assets
    chmod -R 777 cache files export flash images media

    (4) Create blank config.inc.php in the manager/includes directory and make it world writable

    cd ../manager/includes
    cp config.inc.php.blank config.inc.php
    chmod 777 config.inc.php

    (5) In the meantime I have created a database called "modx" and a database user "modxuser" with all permissions on that database....

    (6) Navigate with webbrowser to .../modx-1.0.0/install

    (7) Leave language as "english" and click "Next"

    (8) Select "New Installation" and click "Next"

    (9) Enter database hots, login name and password and "test connection"

    (10) Change "SET CHARACTER SET" to "SET NAMES" and "test selection"

    (11) Choose "admin", enter my email address and choose password twice, leave language as English and click "Next"

    (12) Select "Install/Overwrite Sample Web Site" and leave everythign else checked and click "Install"

    Setup has carried out a number of checks to see if everything’s ready to start the setup.

    Checking PHP version: OK!

    Checking if Register_Globals is off: OK!

    Checking if sessions are properly configured: OK!

    Checking if /assets/cache and /assets/cache/rss directories exist: OK!

    Checking if /assets/cache and /assets/cache/rss directories are writable: OK!

    Checking if /assets/cache/siteCache.idx.php file is writable: OK!

    Checking if /assets/cache/sitePublishing.idx.php file is writable: OK!

    Checking if /assets/images, /assets/files, /assets/flash and /assets/media directories exists: OK!

    Checking if /assets/images, /assets/files, /assets/flash and /assets/media directories are writable: OK!

    Checking if /assets/export directory exists: OK!

    Checking if /assets/export directory is writable: OK!

    Checking if /manager/includes/config.inc.php exists and is writable: OK!

    Creating connection to the database: OK!

    Checking table prefix `modx_`: OK!

    Checking MySQL version: OK! Your MySQL version is: 5.0.67-0ubuntu6

    Checking MySQL for strict sql_mode: OK!

    (13) Agree to license and click Install

    Install results

    Setup will now attempt to setup the database:

    Creating connection to the database: OK!

    Selecting database `modx`: OK!

    Checking table prefix `modx_`: OK!

    Creating database tables: OK!

    Installing demo site: OK!

    Writing configuration file: FAILED!

    MODx couldn’t write the config file. Please copy the following into the file manager/includes/config.inc.php

    (14) Copy data to config.inc.php as requested, ensuring carefully that there is NO SPACE before <?php or after ?>

    (15) Click "Close" which produces a login page with the text

    "Install/update of this site is currently in progress. Please retry in a couple of minutes"

    (16) Examine "siteCache.idx.php" and note to my surprise...

    <?php
    $c=&$this->config;
    $c[’manager_theme’] = "MODxLight";
    $c[’settings_version’] = "0.9.6.3";
    $c[’server_offset_time’] = "0";
    $c[’server_protocol’] = "http";

    (17) Edit file so that MODxLight is MODxCarbon ... but why is the version 0.9.6.3?

    (18) Attempt to log in to manager page with admin password

    THIS SUCCEEDS ONLY IF THE MODxCarbon is changed before first log in attempt, and I arrive at the manager.

    (19) And now it all goes pear-shaped....

    If I try to view anything I get the "AjaxSearch" error that I referred to in a previous post.

    If I try to edit the "System Configuration" and then click "Save" I just get

    Warning: fopen(../assets/cache/siteCache.idx.php) [function.fopen]: failed to open stream: Permission denied in /u2/gordon/WWW/modx-1.0.0/manager/processors/cache_sync.class.processor.php on line 220
    Cannot open file (../assets/cache/siteCache.idx.php)

    even though when I check the file siteCache.idx.php, it is world writable...



    (20) Browsing siteCache.idx.php there are some other strange things...

    $c[’rb_base_dir’] = "/Applications/MAMP/htdocs/modx/assets/";

    Why would this be there?




    Anyway, I’m going to need some major help to get this back online..

    Thanks

    Gordon











      • 3749
      • 24,544 Posts
      Could the host be using suPHP or suExec? If so, the permissions need to be 755 for directories and 644 for files.

      It’s also possible that one or more of the MODx files were corrupted on download or upload.

      mod_security could also be the problem.

      See if anything here helps: http://www.bobsguides.com/modx-installation-faq.html
        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
        • 10746
        • 126 Posts
        I don’t think it is using suPHP or suExec or mod_security but don’t know for sure.

        But I noticed something else funny... if I look at this error message...


        Warning: fopen(../assets/cache/siteCache.idx.php) [function.fopen]: failed to open stream: Permission denied in /u2/gordon/WWW/modx-1.0.0/manager/processors/cache_sync.class.processor.php on line 220
        Cannot open file (../assets/cache/siteCache.idx.php)

        then the file that could not be opened was "../assets/cache/siteCache.idx.php"

        But from "modx-1.0.0/manager/processors" (which is where the file cache_sync.class.processor.php lives) this relative path name is just incorrect because ".." goes up just one level, whereas to reach "assets" we would need to have

        ../../assets/cache/siteCache.idx.php

        So, what gives? Do I give up and try install Drupal or something equally horrible?

        Gordon
        • If I’m not mistaken, step 15) in your original list should have been "Retry", not "Close".
          If you were indeed presented with the "Close" option at that point, then I think something needs to be fixed in the installer.
          Please confirm.
          Also, are you intending to install MODx in the subdirectory of your site /modx-1.0.0/ ?
          Although it’s possible to do so, it’s more "normal" to install it right in the root of your site.
            Mike Schell
            Lead Developer, MODX Cloud
            Email: [email protected]
            GitHub: https://github.com/netProphET/
            Twitter: @mkschell
            • 10746
            • 126 Posts
            If I’m not mistaken, step 15) in your original list should have been "Retry", not "Close".
            If you were indeed presented with the "Close" option at that point, then I think something needs to be fixed in the installer.
            Please confirm.

            Close was the only option at that point...

            • But from "modx-1.0.0/manager/processors" (which is where the file cache_sync.class.processor.php lives) this relative path name is just incorrect because
              No, because everything in the Manager is really coming from the manager’s index.php file.

              I’ve installed 1.0 several times now with no problems; if that were incorrect it wouldn’t install for anybody.
                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
              • This is simply a permission problem. The PHP process must be able to write to that file for a successful install. Set the permissions on that file to 0666 and all should be fine (unless you are running suPHP or an equivalent).
                  • 10746
                  • 126 Posts
                  This is simply a permission problem. The PHP process must be able to write to that file for a successful install. Set the permissions on that file to 0666 and all should be fine (unless you are running suPHP or an equivalent).

                  It seems that it IS a permissions problem, but a very nasty one...

                  Although the webserver is a Linux machine, the actual files themselves reside on a Mac whose disk is mounted on the Linux machine.

                  Somehow the permissions are getting screwed up ... so that I can type in "chmod 777 config.inc.php" on either the webserver, or the Mac and everything LOOKS alright, but somehow when we test it (i.e. log in as a different user, navigate to the same file and try to write to it) it is STILL NOT world writable.

                  All the sysadmins here are mystified by this behaviour, but it is almost surely the root cause of the problem.

                  (The Macs have an additional layer of file access control that seems to be causing problems... )

                  I think I’ll just get my area moved right on to the webserver itself...