Array to string conversion in views_arg_load

Yes, I'm experiencing the same problem. An array containing the display id two times is passed to views_arg_load in my case.

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

Given 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?

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

Hm, 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!

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

This should be more performant

And even better :)

Thank you! Committed and push

#9 worked for me. Thank you!

#9 worked for me too. Thanks!

Just to confirm that #9 worked for me too. Thank you!

I confirm #9 works for me. Thank you

just to confirm #9 worked for me too. Thank you!