Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
My site runs on an average of 40-50mb. I have installed the viewfield module and when I try to define a view field type in a content type the memory hits the maximum I am allowed at 256mb and displays an incomplete html page. Just how much memory does this module need in configuring a field or is there some other issue at work here?
Comments
Comment #1
natureofdorset CreditAttribution: natureofdorset commentedComment #2
natureofdorset CreditAttribution: natureofdorset commentedJust wondering what the point of this reporting system is if no one answers?
Comment #3
robmalon CreditAttribution: robmalon commentedI was thinking about using this module and this case stood out since it points out a concern I had. I'm currently in between two options. Use this module, or create a dummy field in my content type and use hook_views_pre_render (http://api.drupal.org/api/views/views.api.php/function/hook_views_pre_re...) on the related view to do what I want. The latter would seem more efficient for me since I condense about 5 separate views queries for my use case into a single simpler one. Just feels not kosher. I bring this up because it might be an option for you @natureofdorset. It's the route I'll probably be going.
Anyways, in the past it seems as though views is somewhat a memory hog to begin with. It would be interesting to know if this module adds that much more weight to it or if it's just a symptom of using it more often via the field on additional pages.
Comment #4
fraweg CreditAttribution: fraweg commentedHello,
how do you test your memory usage?
Best regards
Frank
Comment #5
simonyeldon CreditAttribution: simonyeldon commentedWe have been having the same issue, and after a bit of playing around it seems to be that there is an issue with the token helper rendering.
We got around the problem by using a hook_form_FORM_ID_alter to unset the token helper so that it was not rendered.
Here is an example of the code we used.
Comment #6
steinmb CreditAttribution: steinmb commentedCross posting #2073555: Node/add/page with viewfield loaded very slow ...
Comment #7
fraweg CreditAttribution: fraweg commentedHello simonyeldon,
So you do this:
for every viewfield?
Do you feel that the performance is better?
Best regards
Frank
Comment #8
peterx CreditAttribution: peterx commented@robmalon, joins can be memory hogs and Views sometimes uses joins in cases where you could hand code something more efficient.
Token helper is mentioned a problem in several issues.
To everyone with views hogging resources under Viewfield, edit the view and add a page display. Test the view in the page display. Is it a resource hog when run by itself?
Switch on the SQL display in views and look at the SQL. Are there joins? Are the filters selecting the minimum data?
If the view is not a resource hog when run by itself and it is not producing a join, you could export the view and add the export here so we can look at the view code.
Comment #9
ilia.ivanov CreditAttribution: ilia.ivanov commented@simonyeldon thank you very much! #5 solution works for me.
Comment #10
DamienMcKennaMaybe try applying the patch from #1784880: Implement token dialog to make the token browser use the popup dialog instead of displaying inline?
Comment #11
steinmb CreditAttribution: steinmb commentedComment #12
ngocketit CreditAttribution: ngocketit commentedWhy don't we have an option to not show the Token helper? The page is exceptionally slow for Ajax requests of image fields.
Comment #13
ngocketit CreditAttribution: ngocketit commentedProbably it's better to use hook_field_widget_form_alter() instead of hook_form_alter() since the field may be used in a Field collection item for example.
Comment #14
hargobindWith the commit of #1784880: Implement token dialog and release of 7.x-2.1 a couple weeks ago, this issue is likely resolved. If not, feel free to reopen the issue.