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.
This looks like fantastic work but one question— is there any reason a person using a screenreader should have to hear about all the blocks we hide from view?
That is, in:
$form[$entity_id]['#attributes']['class'][] = 'visually-hidden';
Shouldn't we use just "hidden" here?
We had moved into direct discussion with the maintainer hanoii, i just missed the last message. That said i remain five+ years behind on my goals with Give module so will engage in the issue queue about specific needs with the newer releases as needed there, and see if that develops into co-maintaining making any sense. Thanks all!
Facet Bot Blocker – https://www.drupal.org/project/facet_bot_blocker → – should be able to do this, per ✨ Per role allowance? Active over there!
People can assign that permission to whatever role they want, so i think this fulfills the initial request. (I would even say that doing things with a role setting directly rather than through permissions is an anti-pattern.)
And this would seem to fulfill this feature request to Facets: ✨ Permissions-based limit on the number of facets a user can select Active
Really exciting!
Thank you! Pretty glad to hear that, really, because i had already started making a module to work around that for this use case, heh: FillPDF Comprehensive Mapper, https://www.drupal.org/project/fillpdf_comprehensive_mapper →
Should have that done soon, things got in the way, and i'll think about where it makes sense to document the architecture of FillPDF— it's both obvious in the way the filling is set up but also not 100% clear that passing in another parameter might be a hidden capability.
Hi duaelfr i missed your offer in 🐛 Paragraph tags are not stripped if the p tag has attributes like dir=ltr or title Fixed to help maintain— ridiculously belatedly, i have added you as a maintainer.
Since in that issue you fixed the character encoding issues i trust that you (and, y'know, the Drupal core team) are confident that this is not a regression there.
Thanks again!
Side note: Releases have always been made against the 1.0.x branch and i have made the 1.x branch not the default in git.drupalcode now, i'll try to archive it but let's ignore it and be sure we are on 1.0.x from now on.
Release: https://www.drupal.org/project/strippfilter/releases/1.0.1 →
(Going to release a 1.1.0 that also fixes 🐛 Warnings when using this on HTML5 markup Active in a minute, keeping it separate and on a minor release on the very low chance that the change in libraries changes anything about functionality in some edge cases.)
Very nice, looks good.
We really should have had tests in place to ensure it still does what it is supposed to do but manual check and the code looks good.
Yes i will try to separate out what i can into a new module and change this (or make a new) issue fork for only what is needed for the new module to work, if anything is needed.
In the meantime, working in the open in this issue fork!
Seems the correct path forward would be #3188704: I expect