Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.I'm using last i18nviews with translation Views selection in Views settings.
As explained here http://drupal.org/node/1002098#comment-3969148 i did a refresh on Views Strings in translate interface, but I get this error Call to a member function unpack_translatables() on a non-object in /home/XXXX.com/prod/sites/all/modules/views/plugins/views_plugin_localization.inc on line 139
I'm using the last dev of views from today.
| Comment | File | Size | Author |
|---|---|---|---|
| #39 | unpack_translatables-1032836-39.patch | 837 bytes | Shawn DeArmond |
| #20 | 1032836-1.patch | 800 bytes | alexiscott |
| #15 | 1032836.patch | 771 bytes | alexiscott |
Comments
Comment #1
miro_dietikerTry deactivating some modules and identify the broken plugin / handler.
We expect that one of your modules don't inherit correctly... Please check e.g. the class definitions for handlers and plugins.
You'll need to reproduce this issue on a fresh drupal install in order to make us able to work on this. Please provide us step by step instructions.
Comment #2
merlinofchaos CreditAttribution: merlinofchaos commentedThis functionality is really new, and I'm definitely interested in finding the (probable) bugs that are still in it. Unfortunately, from the looks of this one, this is going to take some effort to hunt down what is really wrong.
We need to determine why there's a non-object with unpack_translatables being called on it. The easiest way to do this will be is if a developer can reproduce the situation and then analyze the data that leads to it.
Comment #3
heyyo CreditAttribution: heyyo commentedI did a reinstall of views and i18nviews with devel modules, and everything is working now. so my install procedure with drush was buggy, I thought drush up views-6.x-3.x-dev was correct or drush dl views-6.x-3.x-dev, folllowed by drush updb.
So this bug is not related to any of my modules, but the update itself.
Comment #4
heyyo CreditAttribution: heyyo commentedwhat's the best to get a fresh install of views without losing views already created ?
Comment #5
merlinofchaos CreditAttribution: merlinofchaos commentedUse the bulk exporter to export all your views into a module.
Once you've got that, you can then safely completely reinstall Views.
Comment #6
miro_dietikerYou might did some update that needed a views rebuild which was not triggered.
(Whatever version juggling you did during the setup)
drush cc isn't enough: Visit views tools tab and clear views cache.
Deprecated serialized data is really an ugly issue.
Comment #7
dawehnerDrush and views in the latest version has the feature "drush cc menu" <3
Comment #8
miro_dietikerWe would be very interested in how to reproduce this issue, if it was not caused by a handling mistake.
Comment #9
heyyo CreditAttribution: heyyo commentedI have installed a debug environment with netbeans(quickstart project), but I'm really new to this kind of things, how could I track this bug, what do I need to check ?
Additionnal information Apache error.log
Comment #10
heyyo CreditAttribution: heyyo commentednot sure if it's relevant but the views bulk export produces the same error.
Comment #11
sgabe CreditAttribution: sgabe commentedI got this error when I tried to export a feature with a view provided by the Calendar module. When I uncheck this calendar view on the features export page, it works fine.
Comment #12
kenorb CreditAttribution: kenorb commentedI've got this error, when clicking on 'Overridden' link on one of my Feature from Feature list.
On following URLs:
admin/build/features/geosearch_features
admin/build/features/geosearch_features/recreate
See the backtrace:
( 'drupal_get_form', array (0 => 'features_admin_components', 1 => class stdClass { public $filename = 'sites/all/modules/_custom/_features/geosearch_features/geosearch_features.module'; public $name = 'geosearch_features'; public $type = 'module'; public $status = '1'; public $throttle = '0'; public $schema_version = '0'; public $info = array ('core' => '6.x', 'dependencies' => array (0 => 'UKLP_UI', 1 => 'apachesolr_search', 2 => 'fe_block', 3 => 'flag', 4 => 'strongarm'), 'description' => 'Provides features for geosearch', 'features' => array ('ctools' => array (...), 'fe_block_settings' => array (...), 'flag' => array (...), 'variable' => array (...)), 'name' => 'Geosearch', 'package' => 'Features', 'project' => 'geosearch_features', 'version' => '6.x-1.21') }) )
( 'drupal_retrieve_form', array (0 => 'features_admin_components', 1 => array ('storage' => NULL, 'submitted' => FALSE, 'post' => array ()), 2 => class stdClass { public $filename = 'sites/all/modules/_custom/_features/geosearch_features/geosearch_features.module'; public $name = 'geosearch_features'; public $type = 'module'; public $status = '1'; public $throttle = '0'; public $schema_version = '0'; public $info = array ('core' => '6.x', 'dependencies' => array (0 => 'UKLP_UI', 1 => 'apachesolr_search', 2 => 'fe_block', 3 => 'flag', 4 => 'strongarm'), 'description' => 'Provides features for geosearch', 'features' => array ('ctools' => array (...), 'fe_block_settings' => array (...), 'flag' => array (...), 'variable' => array (...)), 'name' => 'Geosearch', 'package' => 'Features', 'project' => 'geosearch_features', 'version' => '6.x-1.21') }) )
( 'features_admin_components', array (0 => array ('storage' => NULL, 'submitted' => FALSE, 'post' => array ()), 1 => class stdClass { public $filename = 'sites/all/modules/_custom/_features/geosearch_features/geosearch_features.module'; public $name = 'geosearch_features'; public $type = 'module'; public $status = '1'; public $throttle = '0'; public $schema_version = '0'; public $info = array ('core' => '6.x', 'dependencies' => array (0 => 'UKLP_UI', 1 => 'apachesolr_search', 2 => 'fe_block', 3 => 'flag', 4 => 'strongarm'), 'description' => 'Provides features for geosearch', 'features' => array ('ctools' => array (...), 'fe_block_settings' => array (...), 'flag' => array (...), 'variable' => array (...)), 'name' => 'Geosearch', 'package' => 'Features', 'project' => 'geosearch_features', 'version' => '6.x-1.21') }) )
array 'value' => string 'Dataset Name' (length=12) 'keys' => array 0 => string 'wms_datasets' (length=12) 1 => string 'default' (length=7) 2 => string 'field' (length=5) 3 => string 'node' (length=4) 4 => string 'title' (length=5) 5 => string 'label' (length=5)object(views_display)[422] public 'db_table' => string 'views_display' (length=13) public 'vid' => int 0 public 'id' => string 'openlayers_1' (length=12) public 'display_title' => string 'OpenLayers Data' (length=15) public 'display_plugin' => string 'openlayers' (length=10) public 'position' => int 0 public 'display_options' => array 'pager' => array 'type' => string 'some' (length=4) 'defaults' => array 'style_plugin' => boolean false 'style_options' => boolean false 'row_plugin' => boolean false 'row_options' => boolean false 'style_plugin' => string 'openlayers_data' (length=15) 'style_options' => array 'data_source' => array 'value' => string 'openlayers_wkt' (length=14) 'other_lat' => string 'title' (length=5) 'other_lon' => string 'title' (length=5) 'openlayers_wkt' => string 'title' (length=5) 'other_top' => string 'title' (length=5) 'other_right' => string 'title' (length=5) 'other_bottom' => string 'title' (length=5) 'other_left' => string 'title' (length=5) 'name_field' => string 'title' (length=5) 'description_field' => string '' (length=0) public 'handler' => nullarray 0 => array 'value' => string 'OpenLayers Data' (length=15) 'keys' => array 0 => string 'display_title' (length=13)Comment #13
alexiscott CreditAttribution: alexiscott commentedI can confim this issue with calendar and views on Drupal 7 (Not using i18nviews)
I get it when I run drush fl, and it stops the display of my feauture list with:
Call to a member function get_option() on a non-object in /Users/alex/workspace/c4cm/modules/contrib-stable/views/plugins/views_plugin_style.inc on line 37
Note in the calendar view:
/* Display: Date browser */
$handler = $view->new_display('date_nav', 'Date browser', 'date_nav_1');
If I change 'date_nav' to 'block' there is no error and my feature list returns.
Comment #14
dawehnerViews assumes in a lot of places that the display actually works. Here is another place on which the calendar display seems to be broken/not ported are whatever.
That's indeed something major
Comment #15
alexiscott CreditAttribution: alexiscott commentedThanks for you're fast response Dereine. Here's a proposed patch to have views check to see if it's an object that get's returned, and ignore if not.
arcX
Comment #16
dawehnerTranslatable is always an array and never an object
Powered by Dreditor.
Comment #17
alexiscott CreditAttribution: alexiscott commentedAhhh, the error had led me to believe it was an object, and as it stopped the error I looked no further.
"Fatal error: Call to a member function unpack_translatables() on a non-object in /Volumes/Users"
So would is_array($translatable) be an option here?
arcX
Comment #18
alexiscott CreditAttribution: alexiscott commentedAhhh, the error had led me to believe it was an object, and as it stopped the error I looked no further.
"Fatal error: Call to a member function unpack_translatables() on a non-object in /Volumes/Users"
So would is_array($translatable) be an option here?
arcX
Comment #19
dawehnerIn fact you should check $this->view->display[$display_id]->handler for is_object.
Comment #20
alexiscott CreditAttribution: alexiscott commentedThanks: second attempt, but got a feeling it'll be third time lucky ;)
Comment #21
rbayliss CreditAttribution: rbayliss commentedConfirming that #20 worked for me. I was having the features issue described in #12. I believe in my case the broken handler may have come from a filter on a missing taxonomy vocabulary that was provided by the feature.
Comment #22
shunting CreditAttribution: shunting commentedConfirming that #20 works for me; I also had difficulties cloning Calendar. No features involved.
Views 6.x-3.x-dev
Calendar 6.x-2.4
Thanks!!
Comment #23
wiifmCan also confirm that this patch does stop calendar from causing errors
old error (prior to patch):
Can this be committed?
Comment #24
manos_ws CreditAttribution: manos_ws commentedSubscribe.
The patch in #20 works
Also this should get committed
Comment #25
Melissamcewen CreditAttribution: Melissamcewen commented#20 worked for me. THanks!
Comment #26
Jeremy CreditAttribution: Jeremy commentedSolved it for me too.
Comment #27
mathieso CreditAttribution: mathieso commentedAye, worked.
Comment #28
dawehnerSo i'm wondering whether someone already managed to understand the issue?
There is probably a bug much deeper so there shouldn't be just this kind of easy fix as this might hide it.
Comment #29
betoscopioAs arcX posted in #13, i'm having a similar problem in the D7 version too. I've created an issue explaining my use case #1274236: Call to a member function unpack_translatables() on a non-object
Comment #30
dawehnerFrom my perspective this patch still lacks the understanding of the bug :(
Comment #31
Shawn DeArmond CreditAttribution: Shawn DeArmond commentedPatch #20 also worked on 7.x-3.0-rc1.
In my situation, I was trying to re-export a Feature that had some Views.
Comment #32
dawehnerThe real question behind the issue is, what should happen if a handler fails to initialize in $view->init_display().
There are several solutions
Comment #33
shunting CreditAttribution: shunting commentedAnd now the same error is back, although I'm running 6.x-3.0-dev, where the patch in #20 has been committed.
Indeed, adding:
right before:
makes the error message go away, but the real problem lies deeper....
Comment #34
dawehnerNo it wasn't commited yet.
Comment #35
seanrI can confirm that the patch in #20 worked for me in 7.x-3.0-rc1 as well.
Comment #36
pcambraI found this problem reverting a feature that included views that missed dependencies.
Steps to reproduce (7.x):
- Create a feature with some views exported depending on views_data_export (I imagine that with other views' modules is the same, but this was my case)
- Do not include views_data_export as dependency in the feature info file
- On install process, (hook_install of other module i.e.) include a features_revert call of the module and views components (see drush fr command).
Comment #37
seanrI don't think mine had anything to do with views_data_export; wasn't able to track down the cause but the patch did work. My issue was also during feature creation, not installation.
Comment #38
mrfelton CreditAttribution: mrfelton commentedSimilar problem, patch in #20 resolved it for me. (7.x)
Comment #39
Shawn DeArmond CreditAttribution: Shawn DeArmond commented#20 didn't apply to branch 7.x-3.x in Git because it didn't include the a/ and b/ prefixes. Here's an updated patch off of 7.x-3.x as of today.
Comment #40
betoscopioPatch #39 is working fine in my case, using Drupal 7.9, views-3.x-dev from october 27. I'm not having more errors and i can export Calendar views.
Comment #41
dawehnerOkay, great commited to 7.x-3.x and 6.x-3.x