This looks great, thank you.
We'll add it to the 3.1.0 release, where the new features will go.
That is really odd.
You might look to make sure the caching is working correctly, in particular that each environment is correctly able to access the caching system - presuming you're using memcache or redis.
That is definitely a weird error.
I suggest you first upgrade your codebase to the latest D10 (or 11) and Metatag 2 releases, and see if the problem persists.
Should this be turned into a documentation task instead?
The problem I was facing was that there were several menu links with the same path as the parent link, so it was picking the wrong parent.
This was what I was thinking of.
damienmckenna → created an issue.
Thank you for the patch.
Might someone be able to turn that into a merge request so we can see how the tests work?
Also, anyone have any ideas on how to trigger this bug?
Thank you for the merge request, supporting all revisionable entities is really important.
I think the test coverage should be extended to cover this.
If there are changes that can be made in Metatag to make this easier to work with I'm happy to consider it.
Has anyone checked to see what happens with Metatag 2?
I think changes to RabbitHole should be looked into in a separate issue, leave this one focused on Metatag.
I think a "verbose" option is unnecessary, just use the Diff module → .
FWIW still seeing this bug on a 10.2 site using Bootstrap Barrio to render the menu (in a custom region so the module's normal logic doesn't take effect). The referenced core issue fixes it for me, thank you.
Might it be worth adding a note about this on the project page?
I've been hitting this lately where a specific content type has a media field that's an icon, after it indexes a few nodes with the same icon it starts hitting the ye olde "Recursive rendering detected when rendering entity media: [media_id]" error.
I've been hitting this lately where a specific content type has a media field that's an icon, after search_api indexes a few nodes with the same icon it starts hitting the ye olde "Recursive rendering detected when rendering entity media: [media_id]" error. Changing the number of items per index batch from the default of 50 to 5 or 10 doesn't resolve the problem, it still runs into it after it hits 20 occurrences per referenced media entity.
Is this a duplicate of 💬 Boosting is limited to one boost per field Active ?
Thank you for providing an issue fork that includes the intended fixes. If you are finished with your work could you please create a merge request from the changes, set the status to "needs review" and set the "assigned" field to "Unassigned"? Thank you.
Yes, this is still a problem in the 4.0.x branch.
When the module is uninstalled it needs to loop through all of the defined filters and remove mentions of the "filter_footnotes" plugin.
This latest merge request drops compatibility with Drupal 9, is that going to be an issue for the maintainers? Otherwise this seems like great work!
Thank you for adding the test coverage, that is excellent work!
One minor request - please replace the direct use of the service with DI.
I just tagged 8.x-3.7, thank you for the reminder.
damienmckenna → created an issue.
FYI after discussing it with the security team it was decided that this fit under PSA-2023-07-12 → . In short, while there is a security aspect to this, it is such an unlikely scenario to happen that it was deemed fixable in public. As such, there won't be an advisory for this fix.
damienmckenna → created an issue.
damienmckenna → created an issue.
damienmckenna → created an issue.
damienmckenna → created an issue.
damienmckenna → created an issue.
Thank you!
I added them to a hook_update_NAME() script in a custom module.
The question is - does this fit in scope for the 1.x branch, given it's kind of an important fix to the module's logic, or should it be a 2.x thing as it's a change in functionality. I would vote for 1.x because it's a DrupalWTF and probably confuses a lot of people.
Drupal 11 is supported in the v2 releases.
This happens because $this->getMenuParent() returns NULL instead of a string.
Does this help?
Great work, thank you!
Committed.
Never mind - I had the wrong "bundle" value on my exported menu items, when I set them to the menu name instead of "menu_link_content" it worked correctly.
Clarifying the title, and that this is blocked by a core bug.
damienmckenna → created an issue.
How are you exporting the menu item? Menu items are considered content rather than configuration, so normally won't be in a configuration export.
damienmckenna → created an issue.
damienmckenna → created an issue.
Short but sweet.
+1 for adding nagy.balint.
BTW did you contact the maintainer directly?
FWIW this also affects the 3.x branch.
damienmckenna → created an issue.
I think this was fixed by 🐛 must be of type array, null given in array_keys DynamicEntityReferenceItem.php Active , I applied that patch and the problem stopped happening.
I believe this resolves another problem I ran into: 🐛 TypeError: uasort(): Argument #1 ($array) must be of type array, null given in uasort() Active
Should the 10.4, 11.0 and 11.1 release notes be updated to more clearly state this requirement in the upgrade process? While people will run into the issue if they try upgrading from 10.4 to 11.0, the issue is obscured and many are not aware of it.
Note that it didn't work if I didn't set ['dependencies']['module'] and ['backend'], those had to be changed to stop Acquia Search from overriding the configuration.
This seems to work for ddev, with a server configuration named "solr":
// Extra settings when using ddev, kept separate to distinguish between what
// ddev added automatically.
if (getenv('IS_DDEV_PROJECT') == 'true' && is_readable($ddev_settings)) {
// Search API Solr.
$config['search_api.server.solr']['dependencies']['module'] = ['search_api_solr'];
$config['search_api.server.solr']['backend'] = 'search_api_solr';
$config['search_api.server.solr']['backend_config']['connector'] = 'standard';
$config['search_api.server.solr']['backend_config']['connector_config'] = [
'scheme' => 'http',
'host' => 'solr',
'port' => 8983,
'path' => '/',
'core' => 'dev',
'timeout' => 5,
'index_timeout' => 5,
'optimize_timeout' => 10,
'finalize_timeout' => 30,
'skip_schema_check' => false,
'solr_version' => '',
'http_method' => 'AUTO',
'commit_within' => '1000',
'jmx' => false,
'jts' => false,
'solr_install_dir' => '',
];
}
damienmckenna → created an issue.
Thank you for reporting the bug, I'm sorry we left that bug in the module and didn't catch it.
FYI the correct status for a new issue is "Active"; "needs work" is for when a solution has been proposed via a patch or merge request but it needs further work.
It turns out that this is another symptom of Constant Contact's APIs changing and the module not updating to match.
This is failing:
function get_lists($action = 'lists', $exclude = 3) {
$xml = $this->load_url($action);
if (!$xml) {
return FALSE;
}
$xml is coming back empty, for some reason.
damienmckenna → created an issue.
Something like this?
This is a duplicate of #2789529: PHP 4 constructors are now deprecated → .
BTW before I updated the field specs I had to truncate the tables:
$db = \Drupal::database();
$db->query("TRUNCATE {preview_link}")->execute();
$db->query("TRUNCATE {preview_link__entities}")->execute();
I tried this:
$field_specs = \Drupal::service('entity_field.manager')->getFieldStorageDefinitions('preview_link');
if (!empty($field_specs['entities'])) {
\Drupal::entityDefinitionUpdateManager()->updateFieldStorageDefinition($field_specs['entities']);
}
That seems to resolve the problem.
I think it would be useful to have a Drush command to resave the fields, to work around these problems.
The recommendation in the DER module is to resave the field, but that's a little harder to do with Preview Link because the field was created programmatically, rather than within the UI.
I wonder if this is a problem from Dynamic Entity Reference?
The problem isn't limited to 2.2.0-alpha1, I tested all 2.1.0 and 2.2.0 alpha releases and they all have the error.
That should cover it? I'm running into other problems, but there are other issues for those.
damienmckenna → created an issue.
Did anyone open a feature request in gitlab to have a concept of a "security" role for users to be able to access all security issues?
Thanks for the fixes, lostcarpark!
damienmckenna → created an issue.
Am working on this.
damienmckenna → made their first commit to this issue’s fork.
Just hit this problem on a site after some recent codebase updates. FWIW the site is hosted at Pantheon the Preview Link configuration was not changed recently.
damienmckenna → created an issue.
Committed. Thank you!
Several other modules still use getStorage("node_type"), so I'm surprised this causes problems.
Is there a change notice related to it?