The merge request fixes the Gin display issue reported.
Note image buttons do not work the same as regular submit buttons in core. Right now, the image button always steals the submit handler! So maybe this cannot work, so although the display and the functionality are distinct issues that can be handled independently leaving this as active rather than needs review until there is a core fix / workaround (to address core functionality re-opened ✨ UX when using gin with Contnet Moderation and Workflows Active ).
And it is not a duplicate with changing values client side; although that may be related, this is being caused with alteration in a Drupal form/widget alter.
This is absolutely still a bug in Drupal 11.
Button Field module documents:
Important note
Due to #1452894: Elements with #has_garbage_value and #value are always set as a triggering element you can not use image buttons on edit forms when there are any other buttons. Non-editable displays are unaffected.
And where i'm coming from, i confidently told Gin in 🐛 Image buttons cannot be kept in Gin's sticky form actions Active that core's image button form element is a valid alternative to a standard submit input form element:
As noted in ✨ UX when using gin with Contnet Moderation and Workflows Active , Workflow Buttons module pairs very well with Gin for improving the experience of using content moderation workflows, and the 2.0.x branch of Workflow Buttons' "Trash workflow" submodule switches to using the image button to have a trash icon for the soft-delete, similar to the trash icon Claro/Gin add to core's delete link. […]
But in short swapping the submit button out and substituting an image button for it works, and Gin should support this core form element when adding Gin attributes and looking for the
#gin_action_itemflag.
And i get it working perfectly and then discover that no matter which button i press, the image button (soft delete!) is the one that gets incorrectly identified as the trigger button.
Thanks Arun!
Did you enable Admin Toolbar Extra Tools? drush -y en admin_toolbar_tools
Back to needs review then, this looks like. Great work, thanks!
Updating Drupal 11 status of modules in table, start to make other version headlines clearer.
mlncn → created an issue.
If you don't scroll back further in the code for the root error, TypeError: $(...).fitVids is not a function is probably the error you will see in your console for this problem.
The patch fixes FitVids.
mlncn → created an issue.
Thanks— i had followed the issue fork commands to make https://git.drupalcode.org/issue/drupal-3535695/-/tree/3535695-url-alias...
But when i went to submit the merge request, it said 178 commits, 0 changes, so that means i did something wrong and need to try again, yes?
This fixes it but no i have no idea why it would be broken in the first place.
Noticed when making this patch i do still have a core patch in the vicinity: "Path module calls getInternalPath without checking if the url is routed #3342398": "https://git.drupalcode.org/project/drupal/-/merge_requests/9209.diff", from 🐛 Path module calls getInternalPath without checking if the url is routed Active but it does not look like it intersects.
Likewise looked at #2484411: Manual path aliases are not the same as aliases on the node form → but could not see a connection.
Meant to mention the site has no multilingual or translation set up at all (at least not currently, it is possible it did at one point long ago and they were disabled) so 🐛 If you don't want to translate your URL alias, the original URL alias won't work with your translations Needs work should not be the issue.
Also meant to mention explicitly that this does not pose a problem as long as automatic aliases are turned on; our internal tracking issue once we realized the problem was not, say, a contact form no longer existing, only losing its alias, went from being titled "Issue with URL Alias" to "Content that had a manual (rather than automatic) URL alias has no alias shown in the form when edited, so on save the alias is lost" with the deathless description "Manual URL Alias are being forgotten.".
mlncn → created an issue.
Thought i should report
🐛
Remove last facet fails
Active
as related to here— TLDR i think the "prettiest" paths (no query string at all, /view/category/foo-258 in the example above) seem a little incompatible with Facets via Better Exposed Filters or Views itself.
This issue was filed first, but the same solution is already RTBCd in 🐛 Function maxlength_field_widget_third_party_settings_form() should return array, not null Active
These issues are duplicates but whichever is marked as fixed should give credit to the contributor(s) of the other.
The patch is straightforward and very needed.
Marking as major because it can cause a fatal error when you try to go to the manage display form of a content type (for example /admin/structure/types/manage/article/form-display). And there is no easy way to figure out that maxlength is to blame without a debugger (or searching the web now that i'm dumping the entire error message here):
The website encountered an unexpected error. Try again later.
TypeError: Unsupported operand types: array + null in Drupal\field_ui\Form\EntityFormDisplayEditForm->{closure:Drupal\field_ui\Form\EntityFormDisplayEditForm::thirdPartySettingsForm():129}() (line 131 of core/modules/field_ui/src/Form/EntityFormDisplayEditForm.php).
And the stacktrace:
Drupal\Core\Extension\ModuleHandler->invokeAllWith() (Line: 127)
Drupal\field_ui\Form\EntityFormDisplayEditForm->thirdPartySettingsForm() (Line: 459)
Drupal\field_ui\Form\EntityDisplayFormBase->buildFieldRow() (Line: 40)
Drupal\field_ui\Form\EntityFormDisplayEditForm->buildFieldRow() (Line: 213)
Drupal\field_ui\Form\EntityDisplayFormBase->form() (Line: 107)
Drupal\Core\Entity\EntityForm->buildForm()
call_user_func_array() (Line: 528)
Drupal\Core\Form\FormBuilder->retrieveForm() (Line: 279)
Drupal\Core\Form\FormBuilder->buildForm() (Line: 73)
Drupal\Core\Controller\FormController->getContentResult()
call_user_func_array() (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->{closure:Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber::wrapControllerExecutionInRenderContext():121}() (Line: 622)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 121)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext() (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->{closure:Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber::onController():96}() (Line: 183)
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 53)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle() (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle() (Line: 116)
Drupal\page_cache\StackMiddleware\PageCache->pass() (Line: 90)
Drupal\page_cache\StackMiddleware\PageCache->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 53)
Drupal\Core\StackMiddleware\AjaxPageState->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 715)
Drupal\Core\DrupalKernel->handle() (Line: 19)
To very belatedly report back, we are using (and struggling with ✨ Make compatible with Facets Pretty Paths Active Entity Reference Filtering Link.
Separately from my specific, messy issue fork above, the feature (for Entity Reference Filtering Link) of being able to automatically get the right pattern from the Views Exposed Filter configuration the way ERFL does from Facets configuration would be really amazing.
mlncn → created an issue.
This probably will not help 5½ years later but you were almost there— for entityQuery's purposes the column is not the full column name as it appears in the database table but only the part not redundant with the field name— so in the original post's example the field plus column indicator is not field_date_range.field_date_range_end_value but rather field_date_range.end_value, used like this:
->sort('field_date_range.end_value');
This does not seem documented for sort() nor condition(), at least not in the docblock, and it really should be i think.
Yes it was! And then in 📌 Clean up any remaining code issues for a Drupal 11 Release Active the @var line with a missing asterisk was removed, and i think is redundant with the assertion in most IDEs.
mlncn → created an issue.
Fairly certain this is not unique to my setup (note: using Facets 3) and it is pretty major.
Link are 'non-pretty' (?focus[1330]=1330) but i guess redirects to the pretty link. These are tacked onto the current path, including the pretty paths if there. The "non-pretty" overrides but for removing the last facet there is no "non-pretty". If Facet Pretty Paths could be done without the intermediary non-pretty facet links this inability to remove the last item would (have to) be solved.
Found 📌 Unhelpful PHP error with NULL type property Needs review while looking for similar issues and realized that my Drupal 11 was not up to date; a bizarre interaction with Drupal lenient plugin and a patch had left it at a release candidate. Completing the upgrade to Drupal 11.2 resolved this problem.
mlncn → created an issue.
And given that the above workaround has been working for us on a site for a long time, allowing Extra Field 3 in Extra Field Configuration's composer.json like this should be all that is needed.
This truly is blocking Drupal 11 compatibility (because only Extra Field 3.x is D11 compatible) so i think this is major.
A workaround, in the require section of your project root composer.json claim that Extra Field 3 is actually version 2:
"require": {
"drupal/extra_field": "3.0.x-dev@dev as 2.3",
Hi summit, bit late on the reply but you can use:
"repositories": {
"drupal/location_migration": {
"type": "git",
"url": "https://git.drupalcode.org/issue/location_migration-3288357.git"
},
with
"require": {
"drupal/location_migration": "1.0.x-dev",
or the Drupal lenient composer plugin - https://www.drupal.org/docs/develop/using-composer/using-the-drupal-leni... → - to allow composer to install the regular module and then add this patch as you were.
As updated in issue description and can be seen in the issue fork i think the most expedient solution is to avoid false negatives in the URL check by converting it to a string first.
(crosspost)
This is great! Works and the code change is straightforward. I would change to RTBC except for the decision on how to commit and release.
My 2¢ is to do the new major with different version constraints— and hope CKEditor does not make a habit of this level of breaking change!
Does anything happen with the module, or is the included library the only thing that needs changes?
(And any tips for swapping or patching plugins in the project composer.json to test this more easily?)
This is fixed for real in commit f27dd51d6a2c46ee6a2d577d1ad8fc8f7bf9cc65
No idea why the merge button would not work, not a month ago (apparently) and not now either. And no idea why the commit is not showing up here after doing it manually and pushing.
But it really is there: https://git.drupalcode.org/project/tomselect/-/commit/f27dd51d6a2c46ee6a...
The merge request deletes the built file, resulting in an unsurprising error of this kind: The requested URL /modules/contrib/ckeditor_abbreviation/js/build/abbreviation.js was not found on this server.
Given that it was committed before i presume there is a step committers should take to generate the file and then commit it?
And agree that a new major version release makes sense and we can have it version 6 require Drupal core 10.5 / 11.2 or later.
Really rotten of CKEditor to fail this badly on a breaking change; one thing for the plugin or even CKEditor to not work but for it to blank out all text on save is the worst possible behavior.
Precise error in console that i was getting with Drupal 11 and CKEditor 45.2:
"TypeError: e.icons is undefined"
Given that the icon package is at play here, that i'm not finding that error message on the internet anywhere, and that CKEditor Abbreviation is the only extra module for CKEditor we have, i think it has to be related.
"entity.$entity_type_id.edit_form.{$this->formModeManager->getFormModeMachineName($form_mode['id'])}"
looks like it, but we'd want to document the easiest way to get the form mode machine name and how to pass in the individual entity (ID) as a parameter when using the route to get a link to the entity's edit form mode.
mlncn → created an issue.
Needs at the very least an off-by-default toggle on the settings page.
Reported by a colleague on Drupal 11:
Warning: Undefined array key "override" in entity_reference_override_validate_custom_text() (line 59 of modules/contrib/entity_reference_override/entity_reference_override.module).
entity_reference_override_validate_custom_text()
call_user_func_array() (Line: 281)
Drupal\Core\Form\FormValidator->doValidateForm() (Line: 238)
Drupal\Core\Form\FormValidator->doValidateForm() (Line: 238)
Drupal\Core\Form\FormValidator->doValidateForm() (Line: 238)
Drupal\Core\Form\FormValidator->doValidateForm() (Line: 238)
Drupal\Core\Form\FormValidator->doValidateForm() (Line: 238)
Drupal\Core\Form\FormValidator->doValidateForm() (Line: 238)
Drupal\Core\Form\FormValidator->doValidateForm() (Line: 238)
Drupal\Core\Form\FormValidator->doValidateForm() (Line: 118)
Drupal\Core\Form\FormValidator->validateForm() (Line: 585)
Drupal\Core\Form\FormBuilder->processForm() (Line: 321)
Drupal\Core\Form\FormBuilder->buildForm() (Line: 73)
Drupal\Core\Controller\FormController->getContentResult()
call_user_func_array() (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 593)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 121)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext() (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 183)
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 53)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle() (Line: 124)
Drupal\cloudflare\CloudFlareMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 709)
Drupal\Core\DrupalKernel->handle() (Line: 19)
With a follow-up note:
Looks like it doesn't throw the error only if 'single line no markup' is used as the custom text format!?
mlncn → created an issue.
That last commit had a merge/rebase problem:
ParseError: syntax error, unexpected token "<<", expecting ")" in web/modules/contrib/give/src/Plugin/Field/FieldType/PaymentMethod.php).
It's not too bad for this use case! And on further inspection, this covers one of three to four effective outputs of the six configurations that Facets Pretty Paths offers.
In Entity Ref Filtering Link terms, the other options are:
/$view_url/$argument/$id
/$view_url/$argument/$pathautod_label-$id
(With URL-encoded raw value as an option for the first one, but as long as that is an integer ID i don't see how that could effectively matter.)
The option this merge request covers:
/$view_url/$argument/$pathautod_label
is certainly the prettiest. In Facets Pretty Paths this is the Taxonomy term name option, "Use term name, e.g. /services/blue"
Huh i'm not really sure facets pretty paths, where there is no query portion, fully makes sense with this module… well, it should work fine but as i mused above the sheer number of possible configurations for pretty paths seems not a great match to the current configuration approach of entity ref filtering link.
The above is one particular configuration of Facets Pretty Paths, i should note. Not sure if there is any reasonable way to support all the configurations without doing what Entity Reference Facet Link does and interrogate the facet itself for its configuration, and i am over here because seems that would be very hard to do for Facets 3— 💬 Facet links created perfectly except with a colon rather than Active
But making this one way possible will be very helpful i think and make it more possible for others to riff on this.
It works great!! Thank you chrisolof!
c_archer you need to do the configuration of Facet Pretty Paths on the View that has the facets, in the Filter criteria section, presented as (for an 'example' facet name) "Facet: Example (example)" — you need to press that name to configure Pretty paths coder, not the Settings link as we all would usually expect.
mlncn → created an issue.
The 4.0.x merge request (!18) is working perfectly. No code changes needed other than the declarations that it is Drupal 11 compatible.
Started documentation to save new adopters my trouble!
https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... →
That precise code does work, 'entity field' not needed.
Part of the problem for me in earlier attempts might have been not picking up that the field name needed is not the in-code ID of the computed field (plugin) but the machine name produced when you add the computed field to a content type / bundle via configuration. (Obviously i'm quite thick, but the fact that computed fields start with computed_ rather than field_ and the tests used test_ helped obfuscate this.)
My later attempts did not work either because i was misunderstanding 'entity field' to communicate the field plugin (`field`) and the field key to communicate only the field name; turns out what is essential is that field_name and id both be in the field array.
As for my merge request: It does indeed allow you to use computed field without ever attaching it to the given content type. I don't consider that to be a deal-breaker, though, as it allows adding to the view without custom code, and computed fields themselves work the same way— you need to know when you configure them that they make sense for a particular content type (bundle), or it probably won't actually work. Being able to do computed fields in Views only without them being on the entity could be a minor feature in some use cases.
Currently the computed field views plugin would only work for computed fields with no configuration, as noted, though i think exposing computed field's configuration in the view field configuration could work the same as on regular bundle display field configuration.
I think the problem here is that Entity Reference Facet Link is not compatible with Facets 3.0.x and the new recommended way to do Facets filters with Views at all:
New in Facets 3: For new sites it is recommended to use the "Facets Exposed Filters" submodule for Facets on Views. This module uses native Views filters instead, which has many advantages.
Click here for documentation on how to use this new workflow.What it was picking up is the old-style facets i still had which are not needed nor used with Views now.
Opened a support/documentation issue in Facets looking for guidance, 💬 Upgrading Facets ecosystem module to Facets 3 Active
Time Field module is fixing the same problem: 🐛 AssertionError: "General" must be defined in MODULE_NAME.field_type_categories.yml in assert() (line 183 of core/lib/Drupal/Core/Field/FieldTypePluginManager.php). Active per onion
mlncn → created an issue.
The part that is important to them is that the file when people save it has the same name, and that is the part determined by the filename but not the path.
Oh dear, i had hoped updating the directory would not be that difficult! (To be clear, i am planning to work on this but definitely hoping for feedback on technical implementation and of course especially if it is a feature, submodule, or separate module.)
The 95% or so use case would be met by pretty much the default setup of a media entity with a file path that includes the date (`2025-05-28`) so if that simplifies things particularly i would do that, or even cover 99.999% of cases by include the time or just use a timestamp as the subdirectory. Media Entity File Replace has the best UX for the concept, and the crucial ability to upload a replacement without deleting the other first so there is the potential to do this redirect idea.
mlncn → created an issue.
This is now fixed on both branches of Media Library Edit. Confirmed that it fixes the major bug it was causing here (file not being replaced, not uploaded at all, with no warning or error message but instead a false sense that it was successful).
Is there anything Media Entity File Replace can do about updating the thumbnail or would that be Media Library Edit's domain entirely? There is one old issue filed there: 🐛 File name and thumbnail remains same as previously existed file. Active
Clearly not critical as no one else has noted it here, but possibly major as the thumbnail not changing has been noted as a concern for Media Library Edit's interaction with Media Entity File Replace ✨ Incompatibility with media_library_edit Active .
That has to be a record in speed of commit. Thank you so much! (And everybody who worked on this fix!)
(Oh and respectfully upgraded to major because the way it manifests with Media Entity File Replace ✨ Incompatibility with media_library_edit Active results in the file not being replaced and it is extremely difficult to figure out exactly what is happening… if you even notice that people are being served the old file because the new one was never even uploaded (silently failing, no error or warning, seeming successful)!
marcoliver's merge requent !26 works beautifully for 3.0.x; good time to get it in now before further development on that branch!
mlncn → created an issue.
I agree with the proposals to re-use the contextual links pattern here (pencil icon in a circle plus dropdown). It may be a new pattern on the administrative theme while editing content, but it is not a new pattern for getting to editing from the front-end (edit block, edit teaser) nor for sitebuilding from the administration side (edit view). It is the right pattern to use in the media reference which by default has a preview much like what one would see on the front end.
Note that browsing the media library as Grid also has the preview much like what one would see on the front end and it already uses the pencil icon so extending that to the contextual links style (the pencil icon opens a dropdown) is completely natural there as well, and for Table, the existing button dropdown should continue to be used.
Here is a version that applies to Drupal 11.2 for anyone who needs that.
Sorry, is there a convention for patches we want the bot to ignore?
Re-roll complete; the phpstan error is a 500 Internal Server Error so probably not due to our code here.
Would be great to have a Drupal 11 release of this excellent module.
With pushing the original feature (note that i did that right after making a point release, so calling this "In review" on the dev branch right now), plus
✨
A themer can override In Other Words list templates for specific view modes and fields
Active
, it should be possible for people to do whatever template overrides they need to get the effect they want. Only starting to understand that and will see about including a default inotherwords_series_wrapped__string template or if we can avoid paragraph tags and so avoid the need for a template by default.
Thank you Jonathan for the contribution and i hope it has been serving you well as a patch these past two years!
Hello Andrew!
Apologies for not addressing this… two years ago.
If there is any text in templates that is not using |t or |trans we very much welcome issue fork merge requests or patches (or just pointing out the places where this is needed).
For the bigger problem of translating the join word and other text that you are able to enter, now we are in the realm of translating configuration → , which on the one hand is supposed to work if we have well-defined config schema files → — which we do not have, so that is where we should start.
I will warn however that unfortunately there is a core issue preventing this field display configuration from being easily translateable: 🐛 Entity view/form mode formatter/widget settings have no translation UI Needs review
And once that is finally in, there will probably be additional hoops for InOtherWords, which is kind of extreme in its complexity of field display configuration.
Right now, if you are willing to override a FieldFormatter you could do a hack, and wrap the configuration output in t() functions or $this->t() method, and values you use will start showing up in the collected strings that can be translated. Just be careful not to include anything truly dynamic (field values) in there.
OK it is great to have all the code to fix the GitLab CI complaints but we will take the CI config file as a first step here.
teknorah → credited mlncn → .
Thank you!
I think the future for spaceless for In Other Words warrants its own issue.
Certainly does not hold up a D11 compatible release.
Jonathan, thank you for your many contributions in the issue queue here. Would you be interested in being a co-maintainer of In Other Words?
Thank you!