visiting the user/1/view path gives:

*  Warning: array_flip(): Can only flip STRING and INTEGER values! in DrupalDefaultEntityController->load() (line 108 of includes\entity.inc).
* Warning: array_flip(): Can only flip STRING and INTEGER values! in DrupalDefaultEntityController->cacheGet() (line 272 of includes\entity.inc).
* Recoverable fatal error: Object of class stdClass could not be converted to string in DatabaseStatementBase->execute() (line 1919 of includes\database\database.inc).
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

aspilicious’s picture

Confirm

aspilicious’s picture

Object of class stdClass could not be converted to string in DatabaseStatementBase->execute() (line 1976 of C:\xampp\htdocs\drupal\includes\database\database.inc).

thats why...

mcarbone’s picture

Title: fatal error on user/1/view » fatal error and duplicate local tabs on user/1/view
Component: user.module » menu system
FileSize
688 bytes

The problem is the %user loads the whole object, and %user_uid_only_optional only loads the uid, and user_view_page is expecting only the latter. This simple patch fixes that problem, but now there's another one -- the local tab menu is being duplicated on user/1/view. There seems to be something odd going on with the underlying menu settings, and I'm not quite sure what it is.

Berdir’s picture

Status: Active » Needs review

Setting status to see if the patch still applies.

Sivaji_Ganesh_Jojodae’s picture

Title: fatal error and duplicate local tabs on user/1/view » fatal error on user/1/view
Component: menu system » user.module
FileSize
1.53 KB

@mcarbone If $uid is user object then you don't have to run the user_load() again. Attached patch prevents redundant user_load() call and adds comment & changes argument $uid to $account.

Now i don't see duplicate local tab menus because #755638: Tasks are duplicated for default local tasks is fixed.

Cibes’s picture

FileSize
1.59 KB

Solution works fine.

I rewrote the check a little bit - this seems more straight forward to me and can return "MENU_NOT_FOUND" in all ways.

mcarbone’s picture

Status: Needs review » Needs work

Hmm, but now the local task tabs aren't appearing at all.

Sivaji_Ganesh_Jojodae’s picture

Status: Needs work » Needs review

@Cibes Looks much better now.

@mcarbone node/[nid]/view doesn't shows local tabs either, may be we need to discuss that in a separate issue.

mcarbone’s picture

Status: Needs review » Reviewed & tested by the community

Valid point. I'm not really sure of the purpose of this menu item then, but better that it's working if it's going to be there. This seems ready to go.

Dries’s picture

Mmm, that seems to be a bit of a hack, IMO.

aspilicious’s picture

#6: 716150_user_view_page.patch queued for re-testing.

aspilicious’s picture

*Retesting old patches*

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 716150_user_view_page.patch, failed testing.

aspilicious’s picture

Status: Needs work » Reviewed & tested by the community
FileSize
832 bytes

Rerolled, even smaller patch due to fixed trailing whitespaces in an other patch

chx’s picture

Title: fatal error on user/1/view » Default local tasks should never be used
Status: Reviewed & tested by the community » Needs review
FileSize
1.97 KB

What is the use case of typing in the default local task path? I do not get it. Nor does IMO Drupal work on those URLs. So let's redirect.

pwolanin’s picture

I guess a redirect is ok, but in that case we don't even need access, etc for these since they cannot be accessed at all?

thurein’s picture

#3: 716150_user_view.patch queued for re-testing.

joachim’s picture

Issue tags: +Needs documentation

The relationship between a MENU_DEFAULT_LOCAL_TASK menu item and the tab group parent which shows it has always been mysterious and hard to grok. It looks like this change would alter that mysteriousness -- therefore, needs documentation.

jacquesboucar’s picture

failed

pwolanin’s picture

Version: 7.x-dev » 8.x-dev
BrockBoland’s picture

Status: Needs review » Needs work

I think this bug may have been fixed by some other change, because I can not replicate it on the 8.x HEAD. If nothing else, this patch needs to be re-rolled since it was created before the /core directory was created.

jhedstrom’s picture

Issue summary: View changes
Status: Needs work » Closed (cannot reproduce)

The errors in the IS no longer occur. user/x/view isn't even a route anymore from what I can tell.