Hi, I am using a Seblod List field in a List type on a content type that has a parent conte type, in other words I have a content type PRODUCT, a sub/content type PRODUCT-PHOTO and a List Type about PRODUCT_PHOTO where the Seblod list field is used to display articles related to product_photo item.
Well, on the production site (Joomla 3.7/3.8, Linux, PHP 7.1.3) the List on product_photo works. Moving the site to localhost for development (moving via akeeba backup) on WAMP (Windows 10, PHP 7.0.6, Apache 2.4.18) the Seblod List field makes Apache crash every time the list is accessed (removing the field makes the list work again). The Apache log shows infact
child process 10576 exited with status 3221225477 -- Restarting
where that status is related to memory allocation problem (segmentation fault). Infact the browser goes blank with "ERR_CONNECTION_RESET".
Someone in Internet suggests to increase Apache ThreadStackSize but it does not solve for me, I tried to increase it up to 10 MB with no effect and beyond that, Apache shuts down with "ERR_CONNECTION_REFUSED" on the browser.
All official requirements for Seblod are matched (max_file_uploads and max_input_vars).
What in the Seblod list field is harming Apache/PHP so badly? What to test and fix in WAMP?
thanks
Giuse
This is an error in your apache/php stack, as photos are involved it is most likely caused by something related to image resizing that wasn't compiled properly, e.g. gd library or gd php extension
thanks Klas but.. I have no image field in the list, "photo products" are description of cameras, lenses with no image
ok, but still - php application can't cause segmentation fault, this is server side error.
Ok, I upgraded PHP and Apache and that Seblod field is now rendered and Apache is no more crashing, very weird but it's solved.
cheers
Giuse
Hi,
Your SEBLOD search list require certainly some optimlization too.
You can use the SEBLOD debug mode to display performance of your search list.
Often some fields are used like a search filter but the field itself is doing some request. Example you use a select dynamic as a hidden search filter, it doesn't makes sense and this field can be replace by an alias of the select dynamic but with the type field "text".
Thanks.
Hi
Thanks Bes, that's the answer ! Thanks again
cyril
thanks, so the suggestion is to "clone" search intensive select fields used in form types with simple text fields when used in search types and not using the selection capabilities since the input value is provided externally