Hi last time I had this problem quite a few times and after reading few forums I contacted my hosting provider to increase the PHP memory size which was 128Mb at the time. It was increased to 192Mb and sice then it was working fine with no issues at all. By time I was adding to a list on a daily basis created by fabrik whis is now about 400 rows and when exproted from phpmyadmin about 200Kb (kilobytes) in size. When I try to access this list by the admin backend it gives me a blank page! If I remove few rows from it by phpmyadmin it works fine. I know it is a memory issue but if was pushed to the edge of 128Mb few weeks ago how come now a plus of 30-40 rows which I added since then exhausts the extra 64Mb? Anybody has a similar issue?
-
New Commercial Services Section
We have now opened a commercial services section here on the forum for registered users. If you have a Fabrik project that you wish to have someone work on for you, post it under Help Wanted. If you are an application developer and wish to earn some money helping others, post your details under Fabrik Application Developers.
Both of these are unmoderated. It will be up to both parties to work out the details and come to an agreement.
-
Joomla 5.1
For running J!5.1 you must https://fabrikar.com/forums/index.php?wiki/update-from-github/ or include the new file manually https://fabrikar.com/forums/index.php?threads/joomla-5-1-and-fabrik-cannot-find-files-error.54473/post-285151 See also Announcements
Server memory issue - Call of short list gives a blank page!
- Thread starter fehers
- Start date
cheesegrits
Support Gopher
I regularly use tables with millions of rows, and know of hundreds of Fabrik sites which have similarly huge tables.
One thing to check is if you are using element filters on join elements, which are joined to large tables. That's about the only place where it is possible to generate very large result sets on queries.
Try enabling J!'s debug mode, and look at the Profile information at the bottom of the page. That should tell you how much memory is being used at various points during rendering of the list. It should be afairly obvious from that where the memory use is going ... so copy and paste that profiling information here.
-- hugh
One thing to check is if you are using element filters on join elements, which are joined to large tables. That's about the only place where it is possible to generate very large result sets on queries.
Try enabling J!'s debug mode, and look at the Profile information at the bottom of the page. That should tell you how much memory is being used at various points during rendering of the list. It should be afairly obvious from that where the memory use is going ... so copy and paste that profiling information here.
-- hugh
Hi there and thank you for the quick reply. I really appreciate it. The thing is now I got no blank pages. I assume it has to do something with the number of pages requested, extensions triggerred sitting in the memory etc. but... When I first encountered this problem and read the few forums about blank page issues I tried the J! debug mode, error reporting etc... but got nothing returned except a pure blank page. Even looked at server logs, the errorlog.txt file but nothing. The only thing that helped at the time is to increase the PHP server memory. Anyway, if the problem persists I'll try to narrow down the circle on it and post it here. Thanks again!
cheesegrits
Support Gopher
Error reporting is somewhat server dependent. Your provider may have disabled the ability to change PHP settings through ini_set() in scripts, which then means J! can't modify the errorp_reporting_level setting, and it own't get shown on the page OR logged in a file.
You might be able to do it with an ini set in an htaccess file, or a secondary php.ini, although if they have disallowed changing through PHP, they have probably disallowed changing through htaccess / ini files.
Either way ... a blank page means PHP has tossed a fatal error. Finding it in the logs, or displaying it on the page, is a server dependent issue.
However ... J! can always show profiling info, asusming the page isn't blowing up. So what I meant was, increase your memory (or delete enough rows) so the list IS showing. Then look at the profile, which should show you which part of the processing is suddenly hogging up huge amounts of memory. J! / Fabrik will typically consume somewhere in the 20mb range ... and it should be obvious in the profile
-- hugh
You might be able to do it with an ini set in an htaccess file, or a secondary php.ini, although if they have disallowed changing through PHP, they have probably disallowed changing through htaccess / ini files.
Either way ... a blank page means PHP has tossed a fatal error. Finding it in the logs, or displaying it on the page, is a server dependent issue.
However ... J! can always show profiling info, asusming the page isn't blowing up. So what I meant was, increase your memory (or delete enough rows) so the list IS showing. Then look at the profile, which should show you which part of the processing is suddenly hogging up huge amounts of memory. J! / Fabrik will typically consume somewhere in the 20mb range ... and it should be obvious in the profile
-- hugh