Just upgraded to Drupal 6.25 and all working well on that end.
Then upgraded from Finder 1.14 to 1.26 and all Finders result in slow load to WSOD.
No errors in the Drupal error log.
PHP error log shows this...
===
[20-Mar-2012 19:51:15] PHP Fatal error:
Maximum execution time of 60 seconds exceeded in ...drupal/modules/filter/filter.module on line 963
[20-Mar-2012 20:02:33] PHP Fatal error:
Allowed memory size of 100663296 bytes exhausted (tried to allocate 11204 bytes) in ...drupal/sites/all/modules/views/includes/view.inc on line 723
[20-Mar-2012 20:06:53] PHP Fatal error:
Allowed memory size of 100663296 bytes exhausted (tried to allocate 16 bytes) in ...drupal/includes/database.mysqli.inc on line 150
===
Downgraded to Finder 1.14 and all started working again.
Finder definition attached...
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | my finder definition.txt | 35.05 KB | webservant316 |
Comments
Comment #0.0
webservant316 commentedwasn't displaying properly
Comment #0.1
webservant316 commentedstill not displaying properly
Comment #1
webservant316 commentedhmm tried to include the finder definition above as "code" but wouldn't work. So attached here.
Comment #2
webservant316 commentedany thing else I can provide to help debug this?
Comment #3
danielb commentedHoly shit 23 elements. How many users in the view?
There might be nothing you can do but stick with the old version until you upgrade to Drupal 7. As long as only trusted users have 'administer finder' permission you have no security concerns to worry about.
Unfortunately improvements to the logic of finder, and effectively bug fixes, have reduced it's performance.
You could use the 'devel' module to debug the queries on that page and the time it takes to execute. Would be interesting to see that data. You might have to import a duplicate of your finder and kill off elements until it works to actually get output, then import again and kill off the *other* ones.
Comment #4
webservant316 commentedSo your confident the problem is simply a performance limitation? Seems surprising that my Finder search page loads quickly with 1.14 and won't load at all with 1.26 because that much more security crunching is going on.
Comment #5
webservant316 commentedSaw this in my php error logs, don't know if it is related...
[16-Mar-2012 20:56:57] PHP Warning: Unexpected character in input: ''' (ASCII=39) state=1 in .../modules/filter/filter.module on line 690
[16-Mar-2012 20:56:57] PHP Parse error: syntax error, unexpected T_IF, expecting ')' in .../modules/filter/filter.module on line 690
Comment #6
danielb commentedYou may want to test out what happens if you remove your 'rewrite' choices setting and 'no results' PHP code just in case? The textareas where you can pick 'filtered html', 'full html', 'php code', etc... are the ones the filter module deals with.
No you misunderstand, the fixes that cause potential performance and memory hogging were unrelated to security, but to the correctness of the results.
Comment #7
webservant316 commentedOK did that. No success.
1. Installed Finder 1.26, upgraded from 1.14
2. Ran update.php
3. For each of my many checkbox finder elements
a. Set "Add an empty value" to "Do not add an empty choice"
b. Set "possible choice - rewrite options" to blank
4. Loaded my finder page
5. WSOD
6. No drupal errors logged
7. PHP error logged = [22-Mar-2012 16:35:47] PHP Fatal error: Maximum execution time of 60 seconds exceeded in .../sites/all/modules/views/handlers/views_handler_field.inc on line 710
This sure feels like an infinite loop in the code or something else. Seems hard to believe that I am asking the module to do too much. Finder 1.14 does load the Finder form without any problem or slowness whatsoever. Of course you know you own code, but it seems surprising that Finder 1.26 is really requiring so much more processing. Is it possible that it is a bug or misstep in the upgrade path?
Comment #8
danielb commentedBut the filter.module messages went away? You didn't mention them in #7.
As for the maximum execution time, If it isn't simply too much processing due to the number of elements, but an infinite loop, then your finder is not an appropriate example of reproduction to determine what the bug is - it's just too complicated. If you can reproduce it with a finder that has one or two elements with a very generic view of users, and generic fields that every drupal installation has, then we might be in business.
If you can identify a bug in the code and show an infinite loop, then I could do something about that too.
Can you simply build a new finder using 6.x-1.26, testing the finder form after adding each element, and seeing at what point it fails?
I know that isn't fun, but otherwise I have no idea what to suggest.
Comment #9
webservant316 commentedyes no further php error messages observed.
I will test on a simpler finder definition as soon as I have time.
thanks for keeping the discussion going.
Comment #10
danielb commentedComment #11
danielb commentedhonestly sorry you've had trouble with this
Comment #12
webservant316 commentedno problem. thanks for the module.
Comment #13
webservant316 commentedI finally got around to testing the suggestion in #3 above. I had to kill off about 75% of my elements before the thing would work. So this is likely a performance issue. To bad it cannot handle my larger number of elements. If I remember correctly I used 'finder' instead of simply exposing filters to Views because finder allowed me to AND the elements together while Views simply ORed them together.
I guess I will just stick with 1.14 since it is working for now. Thanks again.
If anyone has insight about how to -AND- exposed 'Views' filters or improve the performance of 'finder' lemme know. Thanks.
Jeff
Comment #13.0
webservant316 commentedwhat? description not displaying