LGTM, thank you @graber!
Nit: as we are only using $userConfig
in buildConfigurationForm
, to prevent injecting the user.settings
configuration object, we could just leave the config.factory as is then use $this->configFactory->get('user.settings')->get('notify.status_canceled')
?
Rebased with latest 8.x-1.x and fixed conflicts, had to rename tmgmt_update_8011
as tmgmt_update_8012
Started to see the same in the logs after bumping from 2.8.0 to 2.9.0.
CI was fine (drush updb/drush cex committed), seeing drupalmedia/drupal-media-entity in the config export so seems to be related to
🐛
Media block is allowed even if not indicated as allowed
Fixed
#2 works for me, we might just make it clearer in the example hook, to use entity.group_relationship.create_form
instead of entity.group_content.create_form
and ensure that the plugin is from group_node
. Updated the patch with this.
Also, not sure if we should account the weight of the hooks here, but taking the first available hook that implements it for a Gutenberg enabled node type looks good.
For #7, it might indeed be that the route received a scalar parameter instead of the object because the route probably does not implement options parameters. So we could just check for NodeTypeInterface
and NodeInterface
here.
Thanks update bot!
Similar to https://www.drupal.org/project/la_eu/issues/3414576#comment-15482648 → i cannot reproduce anymore with English only (removed language.entity.eo.yml) as long as /homepage path exists.
I could not reproduce (anymore)
- drush si -y --locale=fr
- drush en -y la_eu_default_content
- drush pmu -y default_content
- Default configuration for the homepage (/admin/config/system/site-information) is /homepage
- As long as this path exists, works as expected when accessing from /
- Tried with and without language prefix set in /admin/config/regional/language/detection/url
We can simply merge the patch removal now.
colorfield → changed the visibility of the branch 1.0.x to hidden.
colorfield → made their first commit to this issue’s fork.
Thanks @juagarc4 makes perfect sense.
Great! Thank you for reporting
As PHP 8.1 is not actively supported anymore, it was more a way to not have BC in mind.
But the current code should work just fine with 8.1. I removed the PHP version requirement so the module can follow the core / Drush one.
Thank you both for the help here, and sorry for the late reply.
colorfield → created an issue.
Yes, looks like it's covered by #3116019: Updated module to work in Drupal 8/9 → , we might still want to move to base field definition and could discuss pros and cons here.
Proposing to postpone but will most likely happen in a new major version as it will break BC (custom code, views, ...).
Hi, 8.x-1.3 was just released and supports Drupal 10 https://www.drupal.org/node/add/project-release/2286181 →
Already merged in the dev branch.
I just did another round of manual testing on Drupal 10.2.2 and it looks good, so closing. Thanks all!
Thanks all. Already merged in the dev branch.
Tested manually, with config and clean install, works as expected so closing.
Feel free to create another issue if you spot a case that should be covered.
Thanks @szeidler for mentioning the core changelog and the fix, works for me too. I don't think that removing POST limitation would cause any issue. Here is a patch, it should also apply to 2.0.x branch https://git.drupalcode.org/project/facets_pretty_paths/-/blob/2.0.x/src/...
tmgmt_update_8011
was already declared, bumping to tmgmt_update_8012
Adding accessCheck
to prevent Drupal\Core\Entity\Query\QueryException: Entity queries must explicitly set whether the query should be access checked or not.
on cron run.
Manually tested on a project with https://git.drupalcode.org/project/facets/-/merge_requests/129
RTBC+1
RTBC+1
Added accessCheck()
to the MR as it is a blocker when deleting any kind of entity, including configuration, so also causes deployment issues.
We might still decide whether or not we want this behaviour to become the default one (see #16).
colorfield → made their first commit to this issue’s fork.
Seems to be closely related to 🐛 CKEditor 5 toolbar items of multi-value field (typically Paragraphs) overflowing on narrow viewports and overlapping with node form's sidebar on wide viewports Needs work
colorfield → created an issue.
Thanks for the great work! Added defer
to the plugin in libraries as the editor can error with
Uncaught TypeError: can't access property "config", settings.mathjax is undefined
CKEditorError: plugincollection-plugin-not-found {"plugin":null}
when JS aggregation is set $config['system.performance']['js']['preprocess'] = TRUE
.
colorfield → made their first commit to this issue’s fork.
Thanks, both looking good, just added the drupal prefix.
Awesome, thanks!
Thanks
For D10 use 1.1.x 📌 Automated Drupal 10 compatibility fixes Fixed
Fixed in https://www.drupal.org/project/graphql_extras/releases/2.0.x-dev → thank you update bot.
Thanks all, finally used the same resolution as https://www.drupal.org/project/facets_pretty_paths/issues/3254600#commen... 🐛 Cannot filter properly when using facet pretty paths Fixed
Approach from #5 looks great, but we might want a bit more flexibility here for multiple routes and probably get this from the configuration as it can be tricky to maintain for non devs. So we could discuss this in a follow-up.
Thanks @3li, I did a manual test on a large set of users and confirming that it works as expected so RTBC+1
Thanks for the patch, adjusted it a bit as it can fail in some translation cases.
Was working with this case
- Create a node in English, published state
- Translate it in French, published state
- Create a draft (or a non default revision state) from the French version
- Create a draft from the English version
But not in this one
- Create a node in English, published state
- Create a draft from the English version
- Create a draft translation in French
- Clone from the English version → it clones from the published / default revision
It's not optimal yet as it could miss to clone translations in some cases + we might want to check first if content moderation is enabled for the bundle, so setting back to needs work.
That sounds great, thanks! Added you as a maintainer
Hi, sorry for the late reply, this module does not use the API under the hood but https://platform.twitter.com/widgets.js so it should not be impacted.
See also e.g. https://twittercommunity.com/t/again-list-widget-says-nothing-to-see-her... or https://twittercommunity.com/t/again-list-widget-says-nothing-to-see-her...
Still commenting on this issue because these widgets can still have their own bugs and the cause seems to be rather confusing https://twittercommunity.com/t/again-list-widget-says-nothing-to-see-her...
Even though features like embedding timelines are working as expected here https://publish.twitter.com/ with the same principle.
Thanks, just created the new release.
Thanks @ressa for the kind words, this means a lot to me
Hi Jeff, the module is very minimally maintained, i just marked it as seeking for co-maintainers and made it Drupal 10 ready.
New features from the roadmap might be added but not clear date for now.
Happy to gather feedback in
🌱
Module feedback & suggestions
Active
and see if there is enough interest to prioritize some features.
Thank you for suggesting and sorry for the late reply, done.
Thanks update bot, also requiring latest checklistapi (^2.1)
Thank you for catching. Fixed in https://www.drupal.org/project/mastodon/releases/1.0.0-alpha2 →
Thanks! merged
colorfield → made their first commit to this issue’s fork.
Thanks! Merged
Thanks!
colorfield → made their first commit to this issue’s fork.
Very late to the party, but if you are landing here, just target goalgorilla/open_social
Example in your composer.json
"patches": {
"goalgorilla/open_social": {
"Issue": "https://www.drupal.org/[my-patch.patch]"
}
},
Where the patch targets
a/modules/social_features/social_*/files_to_patch
b/modules/social_features/social_*/files_to_patch
colorfield → created an issue.
Here is a re-roll if someone needs it but agree with
#6 the referrer method might not be ideal security wise
#7 not using the ui can cause issues so we need to change this to get the base url
Thanks @UpdateBot :)
Thanks for the patch, works well.
- Added some documentation
- Fixed drupal_get_path()
deprecation
- Nits like code style, docblocks and the one from #10
- Proposing to change the name of the command from PushCommand
to DataLayerPushCommand
as there are often multiple commands so we have a bit more context
Leaving to needs work for the tests.
colorfield → created an issue.
Works nicely, thanks for the great work!
colorfield → made their first commit to this issue’s fork.
Merged, thank you both!
Pushed.
Thanks for the input :) Created
📌
Check if the field used by the taxonomy coder exists
Fixed
follow up, when this one is done i will create a new release.
Perhaps we could also have a default computed field.
The hard dependency was not so nice, that's also discussed here https://www.drupal.org/project/facets_pretty_paths/issues/2878617#commen... → so we have a good first step to solve this.
colorfield → created an issue.
Thanks! This is brilliant / a lightweight way to have soft dependency with BC.
Adjusted the readme + space, added accessCheck on entityQuery with re-roll for
📌
Automated Drupal 10 compatibility fixes
Fixed
.
For some reason interdiff is not playing well here, so not posting it.
If the UI is wanted at some point, we could still provide it in a follow up. Just wondering if this should be in the facet source config form, in this case that could potentially open to different field configurations (even though, i don't see the use case for that). Probably better to keep it simple as it is for now.
Thanks update bot :)