damienmckenna → created an issue.
This is a documentation issue - the project's docs → need to make it more clear.
I added a breakpoint at the top of MetatagFirehose::formElement() and it shows that $element['#weight'] exists and has a value of 0:
I changed the field's order on the form display settings for that content type and its weight did not change.
I examined EntityFormDisplay::buildForm() and after it runs foreach($this->getComponents() the Metatag field's is correct:
This implies a bug in Form API or maybe the admin theme, not Metatag.
Could this not also cause regressions if the computedValue() is legitimately being triggered during a batch?
I wonder if there is some other custom or contrib code that is triggering the computedValue() logic when hook_entity_delete() is triggered? Maybe something is regenerating JSONAPI data or something?
Related: 📌 Drupal Core strategy for 2025-2028 Active
I had the same suggestion in 📌 [policy no-patch] Discuss LTS options Active .
Wouldn't it be better to clearly document how to override the credentials via settings.php?
damienmckenna → created an issue.
Regarding the current wording, I think it's too vague - people won't know until probably the second quarter of a given year if the forthcoming core x.0.0 release will be finalized in time to release in June. This is why I suggested separating the EOL date from the new x.0.0 release date.
With respect to having a firm EOL release date for each major branch of Drupal, and to separate the EOL date of a release (n) from the uncertain release date of a future release (n+2), which may be in June, August or December, the EOL date for each core major branch (n) will be December 31st of the year of the second major (n+2).0.0 release that follows.
I would like to skip most of the conversation tangents and just provide a +1 for the idea of extending the support period of each major release branch six months.
We are currently scheduling major new Drupal core x.0.0 releases every two years due to the need to accommodate release and EOL schedules for a range of 3rd party libraries, with the intent to support the previous-previous (x-2) branch until the new x.0.0 release is done. The hope is to tag the release in June, with a first failover date in August, and a second failover date in December. This implies that the Drupal core maintainers are comfortable with supporting 3rd party libraries through the December of each year.
There is also an uncertainty on the date that the new core releases will be tagged - is it the first Wednesday, the first Friday (because it takes a few days to get all the builds to "green" and docs finished), is it the second Thursday, etc?
I would argue that, given the interest of having more predictability on when branches are marked unsupported, that each major release of core (n) would be supported until either the date in December of the second release window for core n+2.
Or better yet, December 31st of that year, just to have exact certainty.
In practice this would mean:
Drupal 12.0.0 release window #1: June 2026
Drupal 12.0.0 release window #2: August 2026
Drupal 12.0.0 release window #3: December 2026
Drupal 10 EOL: December 31st, 2026
Drupal 13.0.0 release window #1: June 2028
Drupal 13.0.0 release window #2: August 2028
Drupal 13.0.0 release window #3: December 2028
Drupal 11 EOL: December 31st, 2028
Drupal 14.0.0 release window #1: June 2030
Drupal 14.0.0 release window #2: August 2030
Drupal 14.0.0 release window #3: December 2030
Drupal 12 EOL: December 31st, 2030
In each scenario the exact date of the EOL is known, regardless of when the new release is actually tagged.
Should this be closed now?
This wraps the $order->uid check in a simple isset().
damienmckenna → created an issue.
If you need more flexibility than what Schema Metatag provides you might want to look at Schema.org Blueprints → which provides a different approach to implementing the schema.org metadata in a way that is much more flexible.
Was looking for a way of doing this via twig, but didn't see any other way.
I think the configuration for listing the allowed tags should be built in a more user friendly way and then converted to a format that is passed to preg_replace(), rather than passing that value directly in - the risk for mucking up the syntax is a little high otherwise.
damienmckenna → created an issue.
Done! Thank you pandaski!
Done.
damienmckenna → created an issue.
damienmckenna → created an issue.
Committed. Thank you.
We'll do a separate issues to add gitlab support and then fix the tests.
damienmckenna → created an issue.
Duplicate of #3288646: Automated Drupal 10 compatibility fixes → .
This is a duplicate of 📌 Automated Drupal 10 compatibility fixes Needs review .
damienmckenna → created an issue.
damienmckenna → created an issue.
damienmckenna → created an issue.
damienmckenna → created an issue.
damienmckenna → created an issue.
@webengr: The latest 8.x-1.8 release should be compatible with D11 as-is.
This change is already present in the latest release, 8.x-1.8.
It couldn't be completely excluded as that's where some of the token processing is done.
Maybe we should start with updating the test coverage to track what the output should look like, and work from there?
I created a MR from the changes with slightly improved messages to help inform the site builder on a possible solution.
Note to self: when this happens the best option is to manually create {file_managed} records for the files identified and re-run the migration.
I think the error message could be further refined to suggest creating the {file_managed} records and rerunning the migration.
I recreated the example hook implementation for CKEditor Media Resize, which was my intended use case: ✨ Convert data migrated using Media Migration to new structure Active
This code has been working for me in local testing.
damienmckenna → created an issue.
FYI I've tested it now using code from the example hook implementation in the API docs, and it's working rather well for me, especially when used with 💬 Recommendation for converting alignments added via "style" attribute Active .
A WIP and untested ;-) change to add hook_media_wysiwyg_filter_alter().
damienmckenna → created an issue.
I worked out how to do this in the module, so here's a merge request that checks for float:left, float:center or float:right in the "style" attribute on the source object. And it works great in my local testing :-)
damienmckenna → created an issue.
@steva1982: No problem. This has been a weird situation for sure - there was no grand announcement that they were getting rid of half of their meta tags, the change had existed for a few years before I came across it, so I do sympathize with your confusion. Thank you for raising the question, I'm sorry it took me a bit to remember the root issue, but I'm glad I could help. Take care.
Thanks for mentioning that issue.
Disclaimer: I'm using the address field via a Webform element, so I'm not discounting the possibility that there's a problem with Webform.
Related issue: https://github.com/commerceguys/addressing/issues/227
damienmckenna → created an issue.
Ah. It was removed: 📌 Remove deprecated Twitter Card plugins (D9) Fixed
This is the list of available Twitter/X Card tags: https://developer.x.com/en/docs/x-for-websites/cards/overview/markup
Giving folks here credit for working on this.
Committed. Thank you.
damienmckenna → changed the visibility of the branch 3484792-page-manager to active.
damienmckenna → changed the visibility of the branch 3484792-page-manager to hidden.
damienmckenna → made their first commit to this issue’s fork.
This would happen because some of the logic uses empty() to check if the value is set, rather than checking to see if it's blank. So, if you look around for uses of empty() you'll probably find the source of the problem.
This would be a feature request.
Committed. Thank you.
Doing a little debugging on this, the problem is that the after maintenance mode is set and the render cache is invalidated, loading the user/1 page again results in the "Access denied" message instead of the "Site under maintenance" message.
So for some reason the output cache was not invalidated as expected.
The same code needs to be turned into a test.
Yes, let's do that.
The change needs to accommodate "empty" values that are not blank, i.e. the number zero.
Committed.
damienmckenna → created an issue.
Committed.
Committed. Thank you all.
Won't this remove valid strings which fail empty(), like the number zero?
I think this should be changed to loop over each element of the array and run the old check.
damienmckenna → changed the visibility of the branch 3396529-no-main-property to hidden.
Did you enable the Metatag Twitter Cards submodule?