On March 26, 2019 we launched new MODX Forums. Please join us at the new MODX Community Forums.
Subscribe: RSS
  • We're attempting to move a site off our staging servers onto the production server but are running into some problems. We're using 3 templates, the default one is working, the two others are not. One template's images are all broken, the other one is in even worse shape. When trying to access page that uses it, I get

    « Etomite Parse Error »
    Etomite encountered the following error while attempting to parse the requested resource:
    « PHP Parse Error »

    PHP error debug
    Error: mysql_fetch_array(): supplied argument is not a valid MySQL result resource
    Error type/ Nr.: Warning - 2
    File: /export/WWW/Root/Depts/CHE/chemical/aitmp/docs/manager/includes/etomite.class.inc.php(486) : eval()'d code
    Line: 8

    Parser timing
    MySQL: 0.0668 s s (6 Requests)
    PHP: 0.0979 s s
    Total: 0.1647 s s

    So far, we've copied the database over, copied the files over and edited the config file. Are there any steps we're missing?

    Thanks,
    Jack K
    • Check all the paths and links in your documents, templates and your CSS files. Some may be relative, some may be absolute. Also check the system configuration; make sure all paths are correct. Check custom chunks and snippets; make sure their paths are correct for the new server.

      I ran into some interesting permission problems on one site, it would fail if the files were too open; for example if index.php got uploaded with 777 permissions (my dev server is set to 777 so I can edit from wherever I happen to be) I would get 505 errors.
        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
      • All the paths in chunks, snippets, templates, documents, etc. are set using an absolute base url snippet, so that's not a problem. The configuration paths are good as well. The permissions were set by our sysadmin and they all seem to be in order...
        • OK, I tracked down the problem to a bad database call, so that's one problem solved laugh
          • OK, I tracked down the problem to a bad database call, so that's one problem solved laugh

            jackk, was this bad database call in the MODx code or in a custom snippet or similar?
            • Totally an oversight on my part. I called the database by name in a custom snippet instead of using the config variables so it broke when I changed it do a different database.