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've created a single view which has multiple pages. One page has an alias of /content-type/admin and another has an alias of /content-type/%nid/admin. The first orders a view of all nodes with an empty node-reference field. The second orders all nodes which have a node-reference field set to %nid and validates in the contextual filter that the user has access to %nid. When viewing any pages using the second pattern, I get an array to string conversion in views_arg_load() because display_id is passing both pages within the view.
Comment | File | Size | Author |
---|---|---|---|
#9 | views-args_load_array-1924892-9.patch | 1.47 KB | plach |
#8 | views-args_load_array-1924892-8.patch | 2.63 KB | plach |
#6 | views-args_load_array-1924892-6.patch | 943 bytes | plach |
Comments
Comment #1
Ice-D CreditAttribution: Ice-D commentedYes, I'm experiencing the same problem. An array containing the display id two times is passed to views_arg_load in my case.
Comment #2
dqdConfirm error occurs after update of views and Drupal core from 7.1 to 7.28 and while drush archive dump and restore from server to localhost. Updating, menu rebuilding and cache clearing with no better.
Notice: Array to string conversion in views_arg_load() (Line 472
I marked newer issue #2170605: Array to string conversion in views_arg_load as duplicate and referenced to here. The error has been tracked down a little bit from others over there but in our case here the error may have a deeper lying reason. Running complex installation with i18n i18nviews domain and translated views content lists via
Content: Has taxonomy term ID (with depth) Content: Has taxonomy term ID depth modifier
views path contextual filter arguments. Logged in as UID 1 also causes bigger SQL Errors on this page, so in our case, it is not sure if the underlying problem is something else ...We are still tracking here. I'll report back if I get any news on this ...
Comment #3
dawehnerGiven the amount of changes I would assume #1651726: Use entity_label instead of term name for term reference exposed filters could have caused this issue.
@digidog
Could you please post those big SQL errors? They are maybe helpful in general to fix the issues.
https://drupal.org/node/2170605#comment-8463165
https://drupal.org/node/2170605#comment-8724255 ... @digidog Do you also have configured multiple views overriding the same path?
Comment #4
dqd@dawehner hi :-) it wasn't clear enough for us here, if the SQL errors have anything to do with this or any other views issue. That's why I sad, that I'll better report back later, to prevent others to unnecessarily look thru' error messages and hunting the rabbit. And sadly, yes, as already supposed: The SQL error is caused by i18n with domain access. Not views. #1906164: Domain Access Upgrade (> 7.x-3.7) causes PDOException: SQLSTATE[42000] for User 1 (i18n_select) - Patches are up in the queue and I restartet successful tests. Issue has already RTBC status now.
@dawehner: Not sure what you mean, your comment line positions were a little bit cluttered: is your last question regarding my comment under the links you have posted before? #15 in #2170605: Array to string conversion in views_arg_load was only a little bit support to the user, who asked how to get back his normal Drupal core default term view. It was not about our setup here. I was just chiming in to give some help in the issue queues. Or, maybe, were you refering to my comment #2 here above, where I mention the staging setup of us? If that's the case: Sorry, the views path-override of our test enviroment here is a simple
term/%
page override, based on the example views view for Drupal terms with views path contextual filters, provided by default views installation.And to obviate any fuss on this let me think loud: I slidely sense that there is something else simple and stupid going on with this, maybe a not fully cleared, or still locked cache, or something similar. Typical with archive restores and different stages as you know. Let me step thru all cache files and database rows to find the needle in the haystack and report back before we waste maintainers time ;-).
Best regards.
Comment #5
dqdHm, strange. Ok, from our side this is fixed so far (not sure if for others), but let me take the minute to inform for thoose who may humble over similar scenarios: if this occurs while you have different development stages you move from left to right, check if any cache files are really cleared. Also some others report, that even clearing all caches several times can still keep some left overs in Drupal nirvana if the cache is very old and big. Also re-enabling certain views and making cache clearing steps in between can help. In our case we just removed it all manually and resaved all views and the messages disappeared after a while. There seems to be no rabbit in the hole. :-)
I tried to reproduce the issue afterwards to help here to find something else, but with no luck. All I can assume is, the we may have a missing array condition control step here somewhere for certain corner cases causing this.
OFFTOPIC: @dawehner, best regards from here. Hope to see you soon. Cheers!
Comment #6
plachThis patch fixes the issue for me.
Here the error appeared when I added a second display with the same path of the first one (with different access configuration). I cloned it from the first one.
Comment #7
plachComment #8
plachThis should be more performant
Comment #9
plachAnd even better :)
Comment #10
dawehnerThank you! Committed and push
Comment #13
szczesuil CreditAttribution: szczesuil commented#9 worked for me. Thank you!
Comment #14
RAWDESK CreditAttribution: RAWDESK commented#9 worked for me too. Thanks!
Comment #15
aramboyajyan CreditAttribution: aramboyajyan commentedJust to confirm that #9 worked for me too. Thank you!
Comment #16
msankhala CreditAttribution: msankhala commentedI confirm #9 works for me. Thank you
Comment #17
dieter zmr CreditAttribution: dieter zmr commentedjust to confirm #9 worked for me too. Thank you!