Hello,
I am currently running jml 2.5.14 and vm sr 2.0.11 with global php-version 5.4.
I try to update to vm sr 2.0.22a - I used tar.gz files from dev.virtuemart.net. Of course I`ve done SQL dump and file backup.
Background:
I am since one week on a dedicated Server at 1und1. I switched my Hosting package because I tried this update (2.0.22a) 3 weeks before and it didn´t work for me-> I got fatal memory Errors at frontend after installation. Because of that, I took a look at my hosting-package and saw, that it was limited to 80 MByte. So I switched to the smallest dedicated Server-package which I am yet on.
Of course I already edited the php.ini and played around with it between 128 and 512 MBytes Memory Limit for php and tried the installations again - but error remains the same.
After installing both files vm and vm aio (2.0.22a), the backend works fine and I would love to use and see the new functions. But the frontend - only index.php - does not work as aspected- I get different fatal Errors, for example
Fatal error: Out of memory (allocated 126877696) (tried to allocate 69 bytes) in /homepages/25/d253685392/htdocs/administrator/components/com_virtuemart/models/product.php on line 669
Fatal error: Out of memory (allocated 126877696) (tried to allocate 696 bytes) in /homepages/25/d253685392/htdocs/administrator/components/com_virtuemart/helpers/vmtable.php on line 499
but only at index.php.
If it´s not only index.php, for example a category everything works, cart works, login works, it´s only the frontPage. First I thought, it may be the template and I switched to joomla standard, but it remains the same.
At this time, I have no further clue what I did wrong or what can I do to solve this.
If anyone of you know further tipps for me, I would appreciate any comments.
Update_ aah sry: URL is suite9.de, but yet it´s on 2.5.14 and vm 2.0.11 again, of course it prod Website.
regards jens
Does it go away if you go into your VM 'Tools > Tools & Migration' and click on 'Install or if necessary update tables' and also click in your Joomla menu 'Components > virtuemart-aio > Update VM Plugin tables'?
Quote from: jjk on August 18, 2013, 11:15:24 AM
Does it go away if you go into your VM 'Tools > Tools & Migration' and click on 'Install or if necessary update tables' and also click in your Joomla menu 'Components > virtuemart-aio > Update VM Plugin tables'?
Hi jjk,
thank you for you help! I just tried it - but it remains the same, fatal error at single FrontPage ...
any further ideas?
If you look at your Joomla 'System Information > PHP Information' tab, what are your current settings for max_execution_time and memory_limit?
Usually something like this is ok:
max_execution_time 90
memory_limit 128M
BTW - On your life site you still have ...index.php... in your url. If you want to get rid of the ...index.php... in your url, it is necessary to enable 'Use url rewriting option' in Joomla AND rename the file htaccess.txt to .htaccess in your root folder.
Quote from: jjk on August 18, 2013, 12:21:40 PM
If you look at your Joomla 'System Information > PHP Information' tab, what are your current settings for max_execution_time and memory_limit?
Usually something like this is ok:
max_execution_time 90
memory_limit 128M
Ok I see I am under 90 seconds right now. Is 90 really neccessary? I will try and get back ...
thanks for your help
[attachment cleanup by admin]
Ok I´ve tested max_execution_time with 90 sec, remains same.
But, I played along with the settings in vm configuration and aaahhh: at least I think I found the problem: If I check "show latest products" in the configuration settings and save, the error appears, if I uncheck "show latest products" and save, it disappears and FrontPage is accessible. I will have a look in this module. Can´t remember that I ve had made changes to it, less some css ... Will get back and give Information ...
Is anybody else is affected?
regards jens
[attachment cleanup by admin]
ok hm, I have to correct my last posts. It seems there are more "places" where I get fatal Memory Errors. I didn´t check all categories earlier. Some categories are accessible, others not. same with the manufacturers if I click "Show all products" from ... some are accessible, other not.
Could there be a relation between this problem and products in multiple categories?
Update: just checked it with 2.0.22 -> remains the same
Could you test your issue on php 5.3?
Hi Maxim,
thanks for your help!
My Provider 1und1 only supports php 5.2 and php 5.4 and php dev -whatever beta they mean with that. It´s not possible to switch to 5.3.
Is it precondition/necessary for vm 2.0.22a?
regards jens
Quote from: slammy on August 18, 2013, 13:15:16 PM
Could there be a relation between this problem and products in multiple categories?
Looking at your second screenshot, your 'Frontend default items per list view' and some other of these pagination settings are much too high. 120 products on a single page means slow page loading times (long waiting times for your customers), because browsers load one image after another (not simultaniously) and probably also high memory requirements. I've attached a screenshot of my settings, which I think make more sense (
for 3 products per row the setting should be i.e. 18,24,36, - but I don't use 3 per row) . In case you override your pagination settings with individual category settings, also check each of your category settings.
Also you still might be affected by this: http://www.djdesign.de/wordpress-hosting-1und1-prinzip/. (My own VM shop runs fine on a cheap 3.95 Euro per month shared server - not at 1and1 of course)
[attachment cleanup by admin]
Quote from: jjk on August 18, 2013, 16:17:37 PM
Quote from: slammy on August 18, 2013, 13:15:16 PM
Could there be a relation between this problem and products in multiple categories?
Looking at your second screenshot, your 'Frontend default items per list view' and some other of these pagination settings are much too high. 120 products on a single page means slow page loading times (long waiting times for your customers), because browsers load one image after another (not simultaniously) and probably also high memory requirements. I've attached a screenshot of my settings, which I think make more sense (for 3 products per row the setting should be i.e. 18,24,36, - but I don't use 3 per row) . In case you override your pagination settings with individual category settings, also check each of your category settings.
hi jjk again,
i tried it with your settings and unset the overrides in the category-settings but it remains the same ...
Maybe 1and1 has a 90 mb or lower default php memory_ limit on their dedicated servers too. You would have to ask them. If they didn't set a limit lower than 128 mb, you may check the max upload limit too, eventually increase it and then try to install the update again. Maybe the update was corrupt for some reason.
Quote from: jjk on August 18, 2013, 17:43:31 PM
Maybe 1and1 has a 90 mb or lower default php memory_ limit on their dedicated servers too. You would have to ask them. If they didn't set a limit lower than 128 mb, you may check the max upload limit too, eventually increase it and then try to install the update again. Maybe the update was corrupt for some reason.
Yes it was default at 90 MByte, but I can handle it on my own with php.ini
The server is at 4 GB ram. I tried it with 128, 256 and 512 as Memory_limit! I restarted the Apache sometimes ...
current config (phpinfo() and Joomla Systeminformation) is:
memory_limit=128M
upload_max_filesize=12M
post_max_size=12M
upload_tmp_dir=tmp/
max_execution_time=120
thanks you jjk for so much support, hope to find a solution or hint soon
regards jens
I think the important point in the "Wordpress hosting at 1and1" link in my first reply to you was that 1and1 ignores the website-owners php settings if it is above their default maximum (90 mb in your case). I would ask them if this applies to your account, too. Wouldn't surprise me if they tell you, you have to upgrade to a more expensive server to be able to use 128 mb or more php memory.
Quote from: jjk on August 18, 2013, 22:24:44 PM
I think the important point in the "Wordpress hosting at 1and1" link in my first reply to you was that 1and1 ignores the website-owners php settings if it is above their default maximum (90 mb in your case). I would ask them if this applies to your account, too. Wouldn't surprise me if they tell you, you have to upgrade to a more expensive server to be able to use 128 mb or more php memory.
If I edit a new php-script and output server-variables with phpinfo (), the Server gives back the settings of this configuration, in my case my php.ini setting ... and I did test it with 128, 256 and 512 MB. I can't believe they do an override and the server can keep this secret ... the server is 10 times higher by costs than the link to the wordpress-hosting ... however, I will ask at 1und1 and report. Thank u jjk
Just found this page: https://hilfe-center.1und1.de/skript--und-programmiersprachen-c82634/php-c82686/bedienung-c82739/welche-php-einstellungen-kann-ich-aendern-a791899.html
Read the section "Scriptlimits'. Do they assure your that no such limit is applied to your hosting package?
And maybe this is relevant: https://hilfe-center.1und1.de/server-c82640/dedicated-server-managed-c82667/php-einstellungen-auf-managed-server-aendern-a790410.html
Hi jjk again,
man thank you for so much help! I just call with 1und1 and there is no Limitation at dedicated-servers for memory-limit, it´s only limited by server-ram and a smart Setting. The Support adviced me and - I apologize - I have overseen a Setting in 1und1 backend, where I can set server-variables and other Settings. yesterday, the Setting was at 128 MByte Memory_limit. I just edit it to 256 MByte and restarted the server. I will go through the update-Prozess to 2.0.22a again and will get back here and report and if so, mark this thread as solved ..., hope to get it done with that setting.
Thank you again for all your tipps and hints,
regards jens
Quote from: slammy on August 19, 2013, 10:01:34 AM
I just edit it to 256 MByte and restarted the server. I will go through the update-Prozess to 2.0.22a again and will get back here and report and if so, mark this thread as solved ..., hope to get it done with that setting.
Ok I´ve done it again with confirmed 192 MByte and restarted Server and php 5.4 ...
I have deactivated all extern extensions or plugins, remains the same like yesterday
What I got is:
Fatal error: Out of memory (allocated 192413696) (tried to allocate 65484 bytes) in /homepages/25/d253685392/htdocs/libraries/joomla/database/database.php on line 513
You can see that almost 192 MByte´s are in use, then it breaks off.
The fatal error appears by different processes. Some category-views function properly, others run into fatal memory error. Same with manufacturer, if I click show all products from XY.
There are categories with subcategories they work, others witout yes and no. I can´t find out what rules are behind ...
The frontPage of vm is affected when I check "Show latest products". Checking "top ten" or "special prods" does not affecting the error.
hm, going back to 2.0.14 and jml 2.5.14
Think I give up for now and wait for the next sr to try all again. :'(
Thank you all for your great help!
If anybody of you is affected too, let me know if you have a solution for this.
P.S
What I else did see in 2.0.22a, it seems that the order-rules from vm-backend for categories are again damaged. I saw this in one of my working categorys .
If I choose "show late edited first" it doesn´t work and oldest products showing up first. I remember this is an old issue long before 2.0.14. Maybe it´s good for you to know ...
best regards jens
Quote from: slammy on August 19, 2013, 16:02:34 PM
Fatal error: Out of memory (allocated 192413696) (tried to allocate 65484 bytes) in /homepages/25/d253685392/htdocs/libraries/joomla/database/database.php on line 513
Could you give me a link to the page with this issue?
Quote
Could you give me a link to the page with this issue?
Hi Maxim, of course: ist www.suite9.de
But the problem is, this is a live-site and of course I had to revive sr vm 2.0.14 again. Are you online now? I could install again but I can´t keep it up for long time cause it´s prod Website (I know, never work on prod - but I am familiar with shell and linux so it´s a thing from 5 minutes to revive backups ... )
Live is at 2.0.14 and everything works fine
Something else I just noticed at the link to your live site in your first forum post about this problem is, that you are loading 2 different versions of JQuery (1.6.2 and 1.6.4) from the external Google api. You should eliminate one of them in order to avoid javascript conflicts. Personally I'm using the VM jQuery only. Loading stuff from Google often takes too much time.
Did you ever test the update on your own PC, i.e. using xampp?
Quote from: jjk on August 19, 2013, 16:56:22 PM
Something else I just noticed at the link to your live site in your first forum post about this problem is, that you are loading 2 different versions of JQuery (1.6.2 and 1.6.4) from the external Google api. You should eliminate one of them in order to avoid javascript conflicts. Personally I'm using the VM jQuery only. Loading stuff from Google often takes too much time.
Aah, thank you jjk. I uncheck and use vm query now. Think I tried something and forget to uncheck in vm-backend. Do you think this could be the reason for fatal memory error?
Quote
Did you ever test the update on your own PC, i.e. using xampp?
aehm, shame on me. Before vm2.0 I used a test-environment on another hosting. After Migration to vm 2.0 I really gave it up and forgot about it ...
I think I will give xampp a try.
Quote from: slammy on August 19, 2013, 17:27:00 PM
I think I will give xampp a try.
I can't live without it anymore... ;D
have you tried JUST simply turning off error reporting
?
Quote from: PRO on August 20, 2013, 02:48:09 AM
have you tried JUST simply turning off error reporting
?
Result is white blank screen then
Quote from: Maxim Pishnyak on August 19, 2013, 16:32:44 PM
Quote from: slammy on August 19, 2013, 16:02:34 PM
Fatal error: Out of memory (allocated 192413696) (tried to allocate 65484 bytes) in /homepages/25/d253685392/htdocs/libraries/joomla/database/database.php on line 513
Could you give me a link to the page with this issue?
Could you install web shop into your subdomain or in a folder?
Quote
Could you install web shop into your subdomain or in a folder?
glad to hear from you Maxim that you would take a look at it! Thank you. I will prepare everything under a new folder, with a second database on the same server, so environment will be the same - but it will take until friday cause I´am at a fairtrade next two days. Will get back to this thread when everything prepared, thank you!
You're welcome, Slammy!
Hi again,
It has left me no peace and I did various further tests and have news, I think I found the Problem:
@jjk: thanks for the tipp with xampp, easy and fast!
I give first here a short summary of this thread:
VirtueMart 2.0.14
Jml 2.5.14
Mission/Process:
Update to 2.0.22a and of course I test 2.0.22b too
What Happened after update:
different fatal Memory errors occurs in Frontend (Backend not affected!) e.g FrontPage, some (not all!) category-views, productdetailpages (not all) and some manufacturer-product-overviews (Not all) (manufacturer Detail page -> Show all products from manufacturer). I spent some time and first I couldn´t get a clue what rules are behind the appearing of this error, but now I´ve found it:
If I unpublish all product-variants from their parent products in a category-view, all category-views working fine again -> no fatal Memory error :) (and precisely these ones which did not work before!) -> If I publish a single product-variant in a category, the fatal memory error occurs again when browsing this category.
I hope this is a useful Information. I do not know if I´ve done something wrong creating these variants or misconfigured something ... if you visit the livesite suite9 de, you can see that variants are displayed in the categorys and everything working fine, e.g http://www.suite9.de/index.php/produktkategorien/f-s-home-collection-kissen
@Maxim
The "search" costs me some time, I don´t know if I am ready on friday with the testsystem if one of you developers would like to take a look at. I need some more time to prepare everything.
What I else (besides how to solve this) would like to know is, if someone can reproduce this error and/or is affected by this error too.
best regards
slammy
you may give me BE access and I can take a look. Please provide also a product with variants (BE editing link).
Hey Milbo,
Danke !!! Ich bereite alles vor und schicke dir links fuer domain und zugang als admin zum Be. Weiss nichtbob ich das bis Freitag schaffe aber mal sehen ... Wenn es fuer dich okay ist, lasse ich alle daten drin-> Produkte und kategorien ... Danke das du dir die Zeit nimmst .grüße jens
Hi again,
prepared everything. I will sent you an email now with accessinformation Milbo. thank you!
Hi again,
I spent some time on my test-Environment and did a sequential update. What I mean is:
Update in a sequence:
2.0.14
2.0.16d
2.0.18c
2.0.20b (incl/until here everything works!)
2.0.21h (excl/from here appearing of fatal Memory error as described before in this thread)
Can someone of you tell me wether there was an "big" update/Change between the Versions vm sr 2.0.20 and vm sr 2.0.21 and what this update is mainly about, specially things related to variants or related products. Sry for all my questions ...
Send me a message and I´ll give BE-ACCESS for the test-Environment if you are vm developer ...
best regards
jens
aaahhhh - yes :) I found the Problem: It seems there was a loop! Some of my parents did have their own childs/variants as related products (I found it nice to see all the child products under product-details and it worked in 2.0.14)!
Solution: I deleted all entrys in table virtuemart_customfields relating to the id from virtuemart_customs (RELATED_PRODUCTS) and see: everything works fine now. I can edit every other product as a related product, but no product own childs/variants, then fatal appears again.
Now it´s clear for me that this config does an loop because childs refer to the related products from their parents if you doesn´t check override parents-customs, so it´s an neverending loop and only limited to php_memory_limit ...
I am so glad, I thought I have to start from begin ...
What I else noticed is the max improved performance from 2.0.14 to 2.0.22 and a decrease of SQL-queries in FE! Glad to see all the new functions! Great, great great!
Thanks to all vm-buddies who helped out in this threat
best regards
jens