MR supports Group 2.x and 3.x.
Since the error message complains about the getAccount() function, I suggest checking if that function exists instead. For example,
$user_name = (method_exists($account, 'getAccount')) ? $account->getAccount()->name : $account->getAccountName();
The method_exists checks aren't really necessary. When you log out normally, the object that gets passed to hook_user_logout() is an AccountProxy, which is a wrapper around a User entity. The AccountProxyInterface is what defines the getAccount() method used by the current code, which returns the wrapped User. However, AccountProxyInterface also extends AccountInterface—which, as noted above, is all that's guaranteed by hook_user_logout()—and as such, an AccountProxy object also has the getAccountName method, which is implemented like so:
public function getAccountName() {
return $this->getAccount()
->getAccountName();
}
And that getAccountName() method on the User is simply this:
public function getAccountName() {
return $this->get('name')->value ?: '';
}
Thus, calling $account->getAccountName() on an AccountProxy does the same thing as calling $account->getAccount()->name, the only difference being that getAccountName is guaranteed and getAccount is not.
As for the error thrown when using Masquerade, that's because masquerading first triggers a logout event for the admin, followed by a login event for the user they are masquerading as. When it does so, the object that comes into hook_user_logout() isn't an AccountProxy, it's just a normal User entity for the admin, and thus it will fail if you try to call getAccount, but succeeds with getAccountName. (This also answers the question about which user will be logged: it's the admin.)
So the cleanest solution would be to revert the MR to the original commit f0f48bdab0cac3b9cbc54e07640637a54f8995a0 that just changed $account->getAccount()->name to $account->getAccountName().
muriqui → created an issue.
Reroll for 7.0.x.
Created a merge request with the changes from msielski's patch, plus converting the GroupEventSeriesPermissionProvider. Haven't had a chance to test this yet, so marking as "needs work." (Also hiding the patch file from issue description so as to direct people's attention to the MR for latest changes.)
Opened an MR to reroll patch #48 against 9.1.x, and to clean it up a bit by removing bits that seemed unnecessary to resolve the issue reported here (such as renaming of the module's admin menu item). Seems to work in my testing.
Steps to test:
- Create a view that has a page display and a contextual argument.
- Create a menu link pointing to that page and use a token to supply the argument. Example: /path-to-my-view/[current-user:account-name]
Result in 9.1.x: The token is not replaced.
Result with MR: Token replaced as expected.
Opened merge request:
- Re-rolls the patch for 9.1.x.
- Fixes a PHP warning that could occur when parsing the query string.
- Fixes the query string tokens not being added to the link when using Context to resolve the tokens.
muriqui → created an issue.
Reroll of #168, resolving two conflicts:
- In ContentEntityStorageBase::setPersistentCache, cache tags are now set using the
$itemsarray and$this->cacheBackend->setMultiple($items), rather thanthis->cacheBackend->set()as in #168. - In SqlContentEntityStorageTest::testLoadMultiplePersistentCacheMiss, changed
$entity->expects($this->any())->method('isDefaultRevision')->will($this->returnValue(TRUE));to$entity->expects($this->any())->method('isDefaultRevision')->willReturn(TRUE);
Added MR !20 to resolve for 3.x.
Also including a backported patch for 8.x-2.x, for those who may need it.
smustgrave → credited muriqui → .
Created MR !5 to make the invalidation type options dynamic (with the 'Everything' option excluded, since there wouldn't be anything to type in the Item field). Also included a few coding standards fixes on the form.