- 🇮🇳India akhilsoni Ahmedabad
I am also facing same issue, I tried the Metatag hack which is mentioned #9 and it dosen't worked for me. I have also applied #15 patch and also that is not working for me. Still looking for solution.
- 🇺🇸United States wells Seattle, WA
I never saw this in 8.x-1.x versions but I am now seeing the exact same issues as described in the initial issue report after upgrading to 2.0.0. Looks like there isn't much here to go on but I'll try to dig in and follow up on what I find. Downgrading to 8.x-1.26 works around the issue (at least in my use case).
I'm leaving the version as 8.x-1.x-dev here since the issue still seems to be active there as well.
- 🇺🇸United States wells Seattle, WA
On the 2.0.x-dev version this is at least somewhat related to 📌 Support JSON API, REST, GraphQL and custom normalizations via new computed field Fixed .
In my testing I found the issue is triggered somewhere along the line when the
metatag_computed
field is computed in\Drupal\metatag\Plugin\Field\MetatagEntityFieldItemList::computeValue
. Specifically it seems to come up after all the relevant entities for the media library view have been computed (i.e. there doesn't appear to be a specific entity or anything triggering the issue).I further traced this to
\Drupal\metatag\MetatagManager::processTagValue
where if I comment out the line handling token replacement the issue goes away. This obviously is not a solution as it disables token replacement in tags but maybe it points to something deeper in\Drupal\Core\Utility\Token::doReplace
? There were kind of recent changes to that handling in #2580723: Fix token system confusion, with new function Token::replacePlain() → but I haven't made it so far as testing this with different versions of Drupal core (and I'm thinking that's a dead end anyway).I also haven't been able to test this with a fresh Drupal installation and the relevant modules yet so I'm not ruling out something specific to our entity configurations or hooks.
- 🇺🇸United States wells Seattle, WA
Following up on the token lead... in my
metatag.metatag_defaults.global.yml
config I have (among other things):uuid: 0031d9a6-85cc-41f3-aa0b-46660705ab08 langcode: en status: true dependencies: { } _core: default_config_hash: sL588ui1E_8-2c_UupwyYxcqX2OVyMFp3HTLbbFqvPc id: global label: Global tags: title: '[current-page:title] | [site:name]' canonical_url: '[current-page:url]' og_url: '[current-page:url]' og_site_name: '[site:name]' og_title: '[current-page:title]'
I found that if I remove the two references to
[current-page:url]
from the config the issue goes away. So it seems this somehow has to do with the handling of that particular token for Media entities (or at least for Media entities as configured on my site).And thinking about it now having
current-page
references in the global config is probably unwise. So at least in this case I will probably work around the issue but making those configuration more precise. - 🇺🇸United States davedg629
I'm getting this same issue (media library pop-up not working) after upgrade from 8.x-1.26 to 2.0.0. I'm getting a similar error to the one posted in the original summary of this issue:
StatusText: error ResponseText: The website encountered an unexpected error. Please try again later.InvalidArgumentException: The opener ID parameter is required and must be a string. in Drupal\media_library\MediaLibraryState->validateRequiredParameters() (line 143 of core/modules/media_library/src/MediaLibraryState.php).
I'm testing with Drupal 9.5.11 and PHP 8.1.
I've downgraded to 8.x-1.26 for now to resolve the issue.
- 🇺🇸United States davedg629
Fix in #9 also worked for me. Additionally, I updated the Open Graph -> Page URL setting to "[media:url]" as well, as recommended in #21.
- 🇩🇪Germany stefan.korn Jossgrund
I suppose #15 is true with pointing towards:
Url::createFromRequest($request) ->setOption('absolute', TRUE) ->toString(TRUE) ->getGeneratedUrl();
if
[current-page:url]
token is used, we have this pattern:https://git.drupalcode.org/project/token/-/blob/381ba02fc93ce3a563ddc94e...
And it seems this is bringing the media library opener in trouble, killing the parameters media library needs. from MediaLibraryState class:
When the media library is opened it needs several parameters to work properly. These parameters are normally extracted from the current URL, then retrieved from and managed by the MediaLibraryState value object.
These parameters get lost if the above call to
Url::createFromRequest
happens during opening media library.That's why workaround from #9 is working in a standard setup of Metatag. Still there can be other cases where this pattern is used, that's maybe why some users problem is not fixed by #9. That said, one reason could be that
[current-page:url]
token is used not only for the canonical url but others tokens as well. But also other modules or custom code could be involved.So token module is at least involved in this, not only metatag. But still also questionable if the way media library gets the parameters is ideal. I find it hard to judge where the changes should be made. Possibilities:
Metatag:
- Another default configuration that does not use[current-page:url]
token for media (if media module is enabled)
Media Library:
- (more) failsafe way to get the parameters for media library
Token:
- is the useUrl::createFromRequest
recommended or necessaryFrom my point of view, first solution seems to be the easiest way. Just creating metatag.metatag_defaults.media.yml in config/install?