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

    I upgraded from 2.1.X to 2.2.0-rc2 and had problems with the save progress bar in some of the ressources mainly home and articles. The progress bar would never stop but changes where still saved. Lots of error messages and plugins not working, wouldn't reinstall etc ... . However I thought maybe I start from scratch and install all core - connectors - manager again. Deleted all the plugins and snippets by hand and install it all again. Now everything seems to work, but I thought I give a feedback to articles:
    This happens while installing the plugin:
    Console running...
    Attempting to install package with signature: articles-1.4.0-pl
    Package found...now preparing to install.
    Grabbing package workspace...
    Workspace environment initiated, now installing package...
    Skipping vehicle object of class modSystemSetting (data object exists and cannot be upgraded); criteria: Array ( [key] => articles.container_ids ) 
    Skipping vehicle object of class modSystemSetting (data object exists and cannot be upgraded); criteria: Array ( [key] => articles.default_container_template ) 
    Skipping vehicle object of class modSystemSetting (data object exists and cannot be upgraded); criteria: Array ( [key] => articles.default_article_template ) 
    xPDOVehicle validator failed: type php (/home/iaredigi/public_html/core/packages/articles-1.4.0-pl/xPDOTransportVehicle/8ef91f50e22659ca23f3facf341b8ece.validate.getresources.validator)
    Could not validate vehicle: Array ( [license] => 

    Here are some error messages:
    [2011-12-21 23:26:15] (ERROR @ /connectors/workspace/packages.php) MODX could not download the file. You must enable allow_url_fopen, cURL or fsockopen to use remote transport packaging.
    [2011-12-21 23:26:15] (ERROR @ /connectors/workspace/packages.php) Could not transfer package quip-2.1.3-pl.transport.zip to /home/iaredigi/public_html/core/packages/.
    [2011-12-21 23:35:10] (ERROR @ /home/iaredigi/public_html/core/model/modx/modparser.class.php : 101) Recoverable error: Argument 2 passed to modParser::collectElementTags() must be an array, null given, called in /home/iaredigi/public_html/core/model/modx/modstaticresource.class.php on line 57 and defined


    phpinfo says
    cURL support enabled
    allow_url_fopen On On

    I don't have a clue what this all means. Is there anything I should check, repair etc...
    bb
    dreh [ed. note: splittingred last edited this post 12 years, 3 months ago.]
      • 37557
      • 25 Posts
      save bug is still there. I turned debug level to 3 and when I navigate to the articles page I get this:

      http://www.pasteall.org/27603

      dreh
      • How much memory is on your server, and how much of it is allocated to PHP? The first line of that error message reads "Allowed memory size of 134217728 bytes exhausted".
          • 6038
          • 228 Posts
          I'm having the same issue with installing Articles via remote package management, same installation error about validator failing and the same errors about ' must have allow_url_fopen', curl or fsockopen enabled' too, However, I have tested and know that allow_url_fopen is enabled... sad
          Unlike the original poster, I don't have any memory exhaustion messages
          I get server 400 messages when trying to access non-existent files/directories through the querystring eg ?f=/assets/components/quip/js/etc.js
          Im also using 2.2 from nightlies
          If you get anywhere with it, keep us updated.
            • 37557
            • 25 Posts
            I updated to rc3. No plugins are installed. When I load the page the Error log says:
             [2011-12-30 17:50:14] (ERROR @ /home/iaredigi/public_html/core/model/modx/modparser.class.php : 101) Recoverable error: Argument 2 passed to modParser::collectElementTags() must be an array, null given, called in /home/iaredigi/public_html/core/model/modx/modstaticresource.class.php on line 57 and defined
            

            and
            [2011-12-30 17:54:18] (ERROR @ /connectors/resource/index.php) Could not load class: ArticlesContainer from mysql.articlescontainer.
            


            Does "ArticlesContainer from mysql.articlescontainer" has something todo with the plugin Articles? If yes how could I delete all the "Articles"-bits thats left in my database. I have the feeling I have a corruption here. I could then try to reinstall Articles again and start the blogging from scratch.

            ty for help
              • 3749
              • 24,544 Posts
              The first thing to try is deleting all files in the core/cache directory and clearing your browser cache and cookies.
                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
                • 37557
                • 25 Posts
                Thanks for your reply.
                I deleted everything inside the cache folder, deleted browser cache and cookies. Unfortunately error persists. Maybe I explain a bit further my problem.
                Articles is NOT installed. All relevant snippets are not there. Site works so far. Still I get the error message in the logs, everytime the site is loaded. My 2 problems are:

                1. I have the feeling the site is slower than before. I see this in my ajax tab call that is a bit laggy when I updated to the developer versions rc2 and then rc3. ( I did cause of Articles)
                2. If I try to install Articles I get wierd error messages (in red) and articles behaves wierd. I believe the installer want's to update the mysql database and there's a corruption from an older error.

                Does this make sense? How can I get rid of "Could not load class: ArticlesContainer from mysql.articlescontainer"
                ty for help
                  • 37557
                  • 25 Posts
                  @Everettg_99 I'm on a mixed hosting. The cpanel says 50 % memory in use. I can't tell if it's a memory problem. I believe these errors have their origin in the "progress bar doesn't go away"-bug I mentioned earlier.
                  phpinfo() says memory_limit 128M
                  . I don't get these errors anymore. How can I verify this?
                  ty for help
                  • If phpinfo() says you've only got 128mb, then that's what's been allocated to PHP. I've found 128mb to be insufficient for many MODX Revo sites -- that could easily be a factor in your errors (the memory error in particular). You can't change that if you're on shared hosting -- you'd have to find a host that offers more memory (and that usually costs more, unfortunately). There are MODX hosts listed here: http://modx.com/partners/hosting-saas/ -- I rent space on my server too.

                    Re the progress bar not going away: that's a nondescript symptom of any number of problems, unfortunately. One common underlying cause is incorrect permissions: the manager tries to do something with a file, and it can't, so the Ajax request hangs. Ajax requests are kind of a pain like that because instead of YOU making the request from your browser, the PAGE is making the request. It does make for a cleaner user-experience and it makes for faster performance because portions of the page can reload without having to reload the entire page, but the downside of Ajax is that all the error messages that would normally come directly to you and your browser instead get sent back to the requesting page, making it that much more difficult to debug and fix.

                    Another insidious cause of the zombie progress bar is a bum plugin: the plugin hangs, and the request never completes. Third possibility: mod_security (see http://rtfm.modx.com/display/revolution20/Installation+on+a+server+running+ModSecurity) might be intercepting the requests and thwarting them. You have to go over your PHP/Apache logs (and mod_security, if installed) to help identify the error.

                    One of the most helpful things in situations like this is to re-run the setup: download the same (or newer) version of MODX and upload it to your site (see the upgrade instructions: http://rtfm.modx.com/display/revolution20/Upgrading+MODx). The setup process will test directory permissions and will alert you to anything that might need adjusting.

                      • 37557
                      • 25 Posts
                      To finish this. I opened another thread http://forums.modx.com/thread/72970/modx-2-2-rc3-sloooow#dis-post-406550 . I think my main issues were like Everett sayd not enough Ressources serverside because I had VERY inefficient code. I managed to stall the shared hosting laugh. The weird behavior was what I think a fawlty upgrade process and probably a corrupted database cause of memory issues. Hope it helps someone. Thanks for everyone involved --> SOLVED