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

natureofdorset’s picture

Assigned: natureofdorset » Unassigned
natureofdorset’s picture

Just wondering what the point of this reporting system is if no one answers?

robmalon’s picture

I 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.

fraweg’s picture

Hello,

how do you test your memory usage?

Best regards
Frank

simonyeldon’s picture

We 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.

function CUSTOM_MODULE_form_FORM_ID_alter(&$form, &$form_state, $form_id) {
  $field = &$form['field_NAME_OF_VIEWFIELD'];
  unset($field[$field['#language']]['0']['vargs']);
  unset($field[$field['#language']]['0']['token_help']);
}
steinmb’s picture

fraweg’s picture

Hello simonyeldon,

So you do this:

function CUSTOM_MODULE_form_FORM_ID_alter(&$form, &$form_state, $form_id) {
$field = &$form['field_NAME_OF_VIEWFIELD'];
unset($field[$field['#language']]['0']['vargs']);
unset($field[$field['#language']]['0']['token_help']);
}

for every viewfield?

Do you feel that the performance is better?

Best regards
Frank

peterx’s picture

Issue summary: View changes

@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.

ilia.ivanov’s picture

@simonyeldon thank you very much! #5 solution works for me.

DamienMcKenna’s picture

Maybe try applying the patch from #1784880: Implement token dialog to make the token browser use the popup dialog instead of displaying inline?

steinmb’s picture

ngocketit’s picture

Why don't we have an option to not show the Token helper? The page is exceptionally slow for Ajax requests of image fields.

ngocketit’s picture

Probably 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.

hargobind’s picture

Status: Active » Closed (duplicate)

With 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.