23376 Posts in 18295 Topics by 2867 members
|Go to End|
28 June 2010 at 7:31pm
Hi Guys, I have a site running on version 2.3.3 that is currently live and was hoping to see if I could get some help regarding some issues I have been facing lately.
I have attempted to get an upgrade to 2.4 working all day but have not managed to get it working properly - facing several incompatibility issues, even after making the necessary changes mentioned on the wiki page for upgrading to 2.4 I am still having issues with pages not linking up correctly ($Link), Widgets not displaying, Forms having issues, Images not displaying..
The reason for attempting the upgrade was in the hope that it may possibly alleviate the issues I am currently facing.
The issues lie within the admin area of the CMS - The first issue we encountered was the Files & Images (assets) tab taking phenomenally long to load and timing out on our live server. I have truncated the Files table and allowed SS to rewrite the file-list to the DB - unfortunately this failed to alleviate the issue.
The second issue we are facing is similar - a certain page node times out/gets stuck in a endless loop whenever we try to navigate to it via the Site Tree.. Not sure why, there are two other nodes of the exact same type in the tree at the same level and with more child nodes too. But they seem to load fine most the time.
The error that we receive tends to occur in:
• sapphire/core/model/SQLQuery.php on line 399
• sapphire/core/model/MySQLDatabase.php on line 455
Error generally states that the memory limit was exhausted. We have allocated over 350mb to the site and it still reaches this limit which is obviously abnormal behaviour.
Any help is much appreciated.
29 June 2010 at 3:49pm
Lets go through all the issues one at at time -
Files and Images taking too long to load: How many images have you got? When SS parses the assets to rebuild that table it will have to do a bit of processing and a database write per file. If you have a lot of files you will have a lot of database writes which = slowness. Also check to ensure your assets folder is read and writable by the web user. You may just have to up the execution time just to run that once off.
SiteTree Node not loading: Anything special about that node (look in the database via phpmyadmin or some other GUI). Is it missing a class name? Content field got something weird in it? (again a GUI DB tool is best for this) compare the row to the ones that work and see if somethings up. If its hitting memory limits could be looping. New in 2.4 is the nested urls so perhaps if you have a link to itself (or ParentID is set to itself) it could be looping rather nastly)
Forms having issues: Majority of issues will be around DateFields and the new Date API. Read the new Date documentation for how to use the new API - http://doc.silverstripe.org/datefield
Images not displaying: Permissions issue maybe? Webserver unable to read files or generate the thumbnails.
Pages not linking up correctly: Have you moved to the new nested urls functionality (SiteTree::enable_nested_urls()?) it should rewrite all the link tags to this new nested structure for you once you run dev/build.
Hope that helps
29 June 2010 at 3:59pm
Thanks for the reply.
I don't think we are going to upgrade to 2.4 simply because of the difficulty I have faced in doing so the last couple days and it's a very time-consuming process.
The assets folder has less than 200 files in it. Even after the file list is built and present in the database, we still have timeout issues.. Which means there's something failing in the backend - I'm guessing structurally, the database may have some issues.
The permissions are all set correctly, in which there are RW permissions enabled for web users.
I made sure nested URLs was disabled in the config file so it wouldn't be that.
I will investigate the SiteTree Node in the DB now and get back to you regarding that.
Cheers, I'll post back with my results.
29 June 2010 at 5:06pm
Ok I had a look at the SiteTree node in the DB and noticed that for this specific entry, the only major difference was the version number.
For some reason the node that has issues is up to version 70 where the others are 4 and 2 respectively.
We have been truncating the versions tables to save on storage as we have an import script running daily which imports products into the system, creating multiple versions and subsequently bloating the database.
|Go to Top|