We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 36571
    • 145 Posts
    Hey all,

    I am building a site with quite a large number of pages (around 6000). I am running into the problem in the manager that when I try to expand the parent document containing these 6000, I get the error
    Fatal error: Allowed memory size of 16777216 bytes exhausted (tried to allocate 4820154 bytes) in /var/www/web122/web/manager/frames/nodes.php on line 139


    rather than seeing the list.

    Is there any way around this? Can I adjust the memory settings (other than directly in php.ini)?

    Any help appreciated.
    • It is a known issue with Evolution (9.6.x and 1.x) that there is a limit of around 5000 documents when performance issues begin to show up.

      As far as the PHP memory limit, according to the PHP documentation, it can be changed in code and in .htaccess files:

      memory_limit "128M" PHP_INI_ALL "8M" before PHP 5.2.0, "16M" in PHP 5.2.0

      http://php.net/manual/en/ini.core.php
      http://php.net/manual/en/configuration.changes.modes.php
        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
      • And regardless of resource limitations, you shouldn’t put all 6000 in one folder.
          • 36571
          • 145 Posts
          I increated the memory limit in my php.ini to 64M and now it seems to work.

          @OpenGeek: Any reason for this? I know it is far from ideal, but I can’t think of another way.

          If we were talking about 20,000 documents (which is insane) then I would probably have been forced to find a bespoke solution, but since 6000 docs is round about the modx "limit" of 5000, I thought I would give it a go and until now it is proving pretty robust.

          The fun will begin when I start running the geocoding scripts and adding 8 or 9 tvs for each document. wink
          • Quote from: danielw at Feb 05, 2010, 09:52 AM

            I increated the memory limit in my php.ini to 64M and now it seems to work.

            @OpenGeek: Any reason for this? I know it is far from ideal, but I can’t think of another way.
            It just takes that much memory to list all of those Resources in a single node of the tree (combine the memory needs for querying, processing, and building a list of all those Resource with what the whole system is using for each request already; see the size of your assets/cache/siteCache.idx.php file and consider that must be loaded on every request to the system, along with the required MODx core files).

            Quote from: danielw at Feb 05, 2010, 09:52 AM

            If we were talking about 20,000 documents (which is insane) then I would probably have been forced to find a bespoke solution, but since 6000 docs is round about the modx "limit" of 5000, I thought I would give it a go and until now it is proving pretty robust.
            Personally, I consider anything with a quantity of 100 or more as data best represented by a custom model and presented by custom Snippets that can create an endless variety of flexible, custom views into your data. To me, MODx is a Content Management System, and is great at helping organize your distinct views, but it is not meant for managing data of any significant quantity as a Resource. Even blog posts to me work better as an external data model; there is no better way to create multi-faceted views into your posts, like a good blogging system should allow (see WordPress). It also makes code/content maintenance and changes to your data model much easier to IMO. YMMV.
              • 36571
              • 145 Posts
              Personally, I consider anything with a quantity of 100 or more as data best represented by a custom model and presented by custom Snippets that can create an endless variety of flexible, custom views into your data.

              I agree with you 100% that from a purely technical/performance perspective, a custom snippet-based solution like the one you described would be far superior. However, the client needs to be able to go in and edit the various pages from time to time, and thus I could not see a way around making them into pages.

              I will certainly follow you recommendation to split the docs into several parents.