Is there a limit to the number of pages you can have? Fatal error: Allowed memor

[kittymcooper]

Just upgraded a site from 1.3 to 1.6.4  (last release with working content alias I think). The site makes heavy use of cataloger pages with many many fields and now I get an error like this on all pages except the home

Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 7 bytes) in........... l/lib/classes/class.content.inc.php  on line 1784

this site has over 4000 content items, could that be the problem? This works on my test site which is similar but runs PHP4.? and has only about 3000 pages

[Jean le Chauve]

Yes, you must increase the php_memory_limit if you can : $config['php_memory_limit'] = '64M';
and collapse all sections in the admin => pages

[kittymcooper]

Thanks but no dice. I had already done that although the upgrade had lost it so I was hopeful for a minute that this would fix it

When I remove the menus, the ordinary content pages are OK but cataloger still blowing up ... for example

Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 47 bytes) in /lib/classes/class.contentoperations.inc.php  on line 73

or
Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 35 bytes) in /modules/Cataloger/Cataloger.module.php on line 308


One thought I had was to try to hack CMS made simple so it ignores content alias and catalogitem types when building those overly large objects of all the pages. But my try on this did not seem to work either.

Next I guess I could look at fiddling with the cataloger
Or try a different CMS since the site may just be too large for this one, sigh ....

[kittymcooper]

OK now I see why there is a limit to the number of pages- ALL pages on the site are loaded into the node tree objects for various functions. This means that large sites run out of memory.

I can get everything but cataloger working on my site by 2 quick hacks:

  1) rewrote function CreateHierarchyDropdown in lib/classes/class.contentoperations.inc

so it does not load everything!! instead it just selects the things it needs to build the "parent:" dropdown used in the admin directly from the content table in the database -- so content_id,content_name,parent_id,hierarchy - then use the hierarchy field with all those zeros  in the select list which gives a nice tabbing effect. Faster too. This is used in content and user preferences in the admin.

2) Wrote a quick user defined tag to do a simple top level menu which just selects the things it needs directly from the content table in the database. Faster too.

Now to figure out how to get a catalog category page to just build the nodes it needs....

[NaN]

I'm also interested in reducing the memory usage.
Could you attach your modified file here?

[kittymcooper]

Sure I attach my version of lib/classes/class.contentoperations.inc.php

   CreateHierarchyDropdown has been modified to use way less memory - this affects the parent drop down in the backend - it gets the informaton needed to create the drop down straight from the database instead of loading all pages. For our site I excluded not active, contentalias and catalogitem types but I put the sql to get all pages in a comment

Here is my fast one level menu user defined tag code. To speed it up further, I added the field active to the parent_id index in the database as well.

// get a top level menu with a simple database query - Kitty Cooper

    global $gCms;
    $db = &$gCms->GetDb();

    $query = "SELECT menu_text,content_alias FROM ".cms_db_prefix()."content WHERE active = 1 ";
    $query .= " AND parent_id = -1 ORDER BY hierarchy";   
   
    $rows   =& $db->Execute($query);

    if ($rows)
    {
         
        echo " \n";
        while (isset($rows) && $row = &$rows->FetchRow())
         {

        echo '';
        echo '';
        echo $row['menu_text']."\n";

        }

      }