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!
Sorry finally back to this and it is still bedeviling me:
#[Hook('views_data_alter')]
public function addComputedFieldChangedFields(&$data) {
$data['node_field_data']['hw_household_changed_shortterm_fields'] = [
'title' => t('Computed changed short-term fields'),
'entity field' => 'field',
'field' => [
'id' => 'computed_changed_shortterm_fields',
],
];
}
}
Tried multiple variations for the field ID, including node.household.computed_changed_shortterm_fields and household.computed_changed_shortterm_fields.
Before trying computed_field.computed_field.node.household.computed_changed_shortterm_fields, the full config file path for the field, and for all i know that would have worked, i dove into how views plugins work and understanding it from the perspective of writing a plugin that could be configured to show any (simple) computed field proved easy to understand for me, and the result is this merge request.
It works great for my purposes and i would bet a good 80% of use cases.
Right now it returns the computed field for the entity with zero configuration that is theoretically possible for the view mode and bundle it was placed on. If anybody needs it, i am convinced i could figure out how to let a specific display configuration be chosen, or load those configuration options in the Views field settings, long before i could figure out how to do the cursed views data alter for a single custom computed field.
The views data alter that works for all computed fields in the merge request works great, and with the Views field plugin unlocks this for others without further custom code.
use Drupal\entityqueue\EntitySubqueueInterface;
/**
* Implements hook_ENTITY_TYPE_update() for entityqueue sub-queues.
*/
function example_entity_subqueue_update(EntitySubqueueInterface $subqueue) {
if ($subqueue->original->items->getValue() == $subqueue->items->getValue()) {
// They are the same items in the same order, nothing to do, move on.
return;
}
$subqueue_items = $subqueue->get('items')->getValue();
$subqueue_items_ids = array_map(function ($item) {
return $item['target_id'];
}, $subqueue_items);
$entity_type = $subqueue->getQueue()->getTargetEntityTypeId();
foreach ($subqueue_items_ids as $id) {
$entity = \Drupal::entityTypeManager()->getStorage($entity_type)->load($id);
\Drupal::getContainer()->get('search_api.entity_datasource.tracking_manager')->entityUpdate($entity);
}
}
This fixes it for saving the whole entityqueue listing.
Have to admit i'm not sure of other cases.
Getting the same " This entity (node: 2005) cannot be referenced. " style errors for every unpublished piece of content in the queue.
User 1 does not have this problem. But there are no permissions that could be granted to allow referencing, which makes this a major permissions-related bug.
mlncn → created an issue. See original summary → .
mlncn → created an issue.