Fatal error in certain categories after move

General Installation & Upgrade
1

So I moved from Secure Cart Hosting (VPS) over to ServInt (VPS) via their migration support. The site is working for the most part but about 20% of my categories are showing errors. Any idea of what could be causing this? I’m searching the forum but not finding a solution that seems to work. Below is a list of what I find when I click on a certain category:


Attitude
Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 491520 bytes) in /home/fastdeca/public_html/shop/var/compiled/customer/%%45^45E^45E480CD%%index.tpl.php on line 179

Band
Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 122880 bytes) in /home/fastdeca/public_html/shop/var/compiled/customer/%%FD^FD1^FD153A02%%top.tpl.php on line 62

Boat
Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 491520 bytes) in /home/fastdeca/public_html/shop/var/compiled/customer/%%FD^FD1^FD153A02%%top.tpl.php on line 234

Cowboy
Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 491520 bytes) in /home/fastdeca/public_html/shop/var/compiled/customer/%%45^45E^45E480CD%%index.tpl.php on line 179

DJ
Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 491520 bytes) in /home/fastdeca/public_html/shop/var/compiled/customer/%%FD^FD1^FD153A02%%top.tpl.php on line 234

Fearless
Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 491520 bytes) in /home/fastdeca/public_html/shop/var/compiled/customer/%%FD^FD1^FD153A02%%top.tpl.php on line 234

Kanji
Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 24 bytes) in /home/fastdeca/public_html/shop/prepare.php on line 181

Misc Lettering
Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 491520 bytes) in /home/fastdeca/public_html/shop/var/compiled/customer/%%FD^FD1^FD153A02%%top.tpl.php on line 234

NASCAR * Partial page loads
Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 491520 bytes) in /home/fastdeca/public_html/shop/var/compiled/customer/%%C0^C0D^C0D66DDE%%product_data.tpl.php on line 152

Nissan * Partial Page loads
Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 491520 bytes) in /home/fastdeca/public_html/shop/var/compiled/customer/%%C0^C0D^C0D66DDE%%product_data.tpl.php on line 152

Stick Figure* Partial page loads
Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 491520 bytes) in /home/fastdeca/public_html/shop/var/compiled/customer/%%C0^C0D^C0D66DDE%%product_data.tpl.php on line 152

Vehicle* Only a few block load
Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 122880 bytes) in /home/fastdeca/public_html/shop/var/compiled/customer/%%24^240^240BC9EB%%pages_dynamic.tpl.php on line 37

Wall* Partial page loads
Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 491520 bytes) in /home/fastdeca/public_html/shop/var/compiled/customer/%%C0^C0D^C0D66DDE%%product_data.tpl.php on line 152

2

And I should note that my config.local.php shows a memory limit of 564M. My host advertises a 768MB guarantee and 1.5GB bursts.

3

Have you tried clearing your cache now that you have moved (especially considering this is happening with /var/compiled in each error line)?

4

[quote name=‘Struck’]Have you tried clearing your cache now that you have moved (especially considering this is happening with /var/compiled in each error line)?[/quote]



Unfortunately I did try that before I posted here with no luck. It’s odd because some of these categories don’t have too many products in them and I get the error. While others have lots of products and I don’t get the error.

5

Try manually deleting the following directories and all files contained within both of these:



/compiled/

/cache/



They will immediately start to re-build as your site front & backend is first visited.



Fast, I would also make sure you have the correct permission settings within your config.local.php for newly created files to match the required settings on your new server.



Something like this example:

// Default permissions for newly created files and directories

define(‘DEFAULT_FILE_PERMISSIONS’, 0644);

define(‘DEFAULT_DIR_PERMISSIONS’, 0755);

6

[quote name=‘Struck’]Try manually deleting the following directories and all files contained within both of these:



/compiled/

/cache/



They will immediately start to re-build as your site front & backend is first visited.[/quote]



Okay, I may have found the problem but not sure how to fix it.



I can’t delete any of the files in the /compiled/ folder nor can I change the permissions of any of the files or folders in that folder.

7

Fast,



You need to change your FTP “User” to be the same as PHP runs as. Your host should be able to help you with this.

8

[quote name=‘Struck’]Fast,



You need to change your FTP “User” to be the same as PHP runs as. Your host should be able to help you with this.[/quote]



I guess I don’t understand what this means. I’m going to look into it but hopefully I didn’t mis-direct you. I can still change/modify permissions and all files and folders except those in the /compiled/ folder.

9

[quote name=‘IsItFast’]I guess I don’t understand what this means. I’m going to look into it but hopefully I didn’t mis-direct you. I can still change/modify permissions and all files and folders except those in the /compiled/ folder.[/quote]



Looks like you don’t have ownership of those folders, accordingly the errors you see are due to incorrect/partial CHMOD of the folders/files. (Partial Loads).



Either contact ServINT or find a professional to fix this.

SCH PHP Permissions were suPHP, if you haven’t set the server up they will be DSO and accordingly you have the mismatch.

10

Well if I am getting them deleted it isn’t fixing anything. It’s telling me it isn’t getting deleted (when I try to delete) but my host tells me otherwise:


[QUOTE]It looks like they were deleted and recreated again.



6.0K drwxr-xr-x 2 nobody nobody 6.0K May 23 21:30 customer

2.0K drwxr-xr-x 2 nobody nobody 2.0K May 23 21:30 mail



I have removed those two folders, so they can be re-generated. They are being created by the apache user, so they will have nobody ownerships.[/QUOTE]

11

I got it to work by updating my php.ini from 32MB to 64MB. Seems that things are back to normal now.

12

Good to hear!



As Jesse touched on above, I would have your host setup your server as suPHP and then change your permissions settings for “newly created files/folders” within your config.local.php to 755/644 as well as then resetting all permissions on your site to these new settings.



By getting these permissions setup correctly now will eliminate future problems which can very well be presently unseen!

13

755/644

14

[QUOTE]755/644[/QUOTE]



Thanks for clarifying this Tool ! :wink:



(I was in a hurry and had a temporary dumb-attack, and/or they put the number 4 & number 5 keys to close together on my keyboard…)

15

[quote name=‘Struck’]

I would have your host setup your server as suPHP and then change your permissions settings for “newly created files/folders” within your config.local.php to 755/644 as well as then resetting all permissions on your site to these new settings.



By getting these permissions setup correctly now will eliminate future problems which can very well be presently unseen![/quote]



Well my host said they could do it but…


[QUOTE]SuPHP uses 2-10x more resources than PHP run as a DSO (default on your server), so the potential is there to be forced into an upgrade that can support SuPHP running on a popular site long before the same site running on PHP as a DSO.[/QUOTE]



That kinda scares me.

16

[quote name=‘IsItFast’]Well my host said they could do it but…



That kinda scares me.[/quote]



Don’t see why they said that, I’ve got all client migrations running suPHP and all appear to have dramatic speed improvements thus far. I don’t have DSO as I’ve heard enough drama from that front and prefer the security overall.