I'm looking at the commit that allowed adding computed bundle fields in views via 📌 Allow adding computed bundle fields in Views Fixed and before i start trying things at random, are we talking for "id":
field(looking in core, this is "EntityField" class at web/core/modules/views/src/Plugin/views/field/EntityField.php)computed_string_field- … i don't think
computed_bundle_fieldor something from core likestandard,custom, ormarkupwould apply, but maybe almost anything valid works?
Initial approach is in this commit on that other issue branch: https://git.drupalcode.org/project/fillpdf/-/merge_requests/56/diffs?com...
Inside $this Drupal\views\Plugin\views\field\Broken, configuration, id = "computed_changed_shortterm_fields"
(In the report above i replaced "computed_changed_shortterm_fields" with "computed_example" but other than that it is identical.)
And before handlePluginNotFound, when PluginManagerBase does createInstance, the $plugin_id it has is "computed_changed_shortterm_fields" with $configuration:
id = "computed_changed_shortterm_fields"
group = TranslatableMarkup "String"
title = TranslatableMarkup "Computed changed short-term fields"
entity_type = "node"
entity field = "computed_changed_shortterm_fields"
What is the plugin expected to be?
Again, the computed field itself with ID "computed_changed_shortterm_fields" is working, but including that code here for completeness:
<?php
namespace Drupal\hw_household\Plugin\ComputedField;
use Drupal\computed_field\Attribute\ComputedField;
use Drupal\computed_field\Field\ComputedFieldDefinitionWithValuePluginInterface;
use Drupal\computed_field\Plugin\ComputedField\ComputedFieldBase;
use Drupal\computed_field\Plugin\ComputedField\SingleValueTrait;
use Drupal\Core\Entity\EntityInterface;
use Drupal\Core\StringTranslation\TranslatableMarkup;
/**
* Computed field which outputs short-term changed fields as a string.
*/
#[ComputedField(
id: "hw_household_changed_shortterm_fields",
label: new TranslatableMarkup("Changed short-term fields"),
field_type: "string",
)]
class ChangedShortTermFields extends ComputedFieldBase {
use SingleValueTrait;
/**
* {@inheritdoc}
*/
public function singleComputeValue(EntityInterface $entity, ComputedFieldDefinitionWithValuePluginInterface $computed_field_definition): mixed {
$revision_id = \Drupal::service('revision_summary.compare_revisions')->latestRevisionIdWithChangedField($entity, 'field_date_stamp');
$fields = \Drupal::service('revision_summary.compare_revisions')->listChangedFields($entity, $revision_id);
return implode(',', array_values($fields));
}
}
(Relying on Revision Summary → module which i've contributed, though it turns out to really be using Diff module, remixed slightly.)
We could accept patches for more options in display, but mostly when customization is needed using Rendered Entity (rather than Label) and doing whatever is needed in a view mode / template is probably the way to go.
Code looks good, and this works!
Note that this only applies to, and only makes sense for, the Label formatter (as opposed to the Rendered Entity formatter).
Looks good and any bugs will only affect people looking for Feeds integration; there is zero impact on the rest of the module.
Marking this as fixed; follow-up issues can be opened as easy. Thanks!!
Thank you both!
With the code above and a computed_example field that is otherwise working, while i can add my field to a view it does not work, and indeed warns immediately:
The handler for this item is broken or missing. The following details are available:
Installing the appropriate module may solve this issue. Otherwise, check to see if there is a module update available.
That is, Views knows my computed field has a broken or missing handler, but it cannot provide any details about it.
Suggestions?
(i will note that Module Builder does not currently composer install for me, Drupal 11 and PHP 8.4 and maybe something else causing incompatible dependencies, so if this or other things are taken care of when using Module Builder as documented → such things still need to be documented independently)
Proposed a workaround in Field Encryt: 🐛 Error when computed_field module fields are present Active
But that does not mean Computed Field should not be providing this setting (empty by default?) in case other modules are also expecting it.
Whether other modules providing fields should always implement getThurdPartySetting or not, from Field Encrypt's point of view if that is not there the field cannot be encrypted, so we can do this check and move on. That is, this protects people using Filed Encrypt from more than only Computed Field in its current state.
Curious about the difference between joachim's example of how to declare the field to Views in hook_views_data() 💬 Access Computed Field in Views Active versus that in the change record associated with the same issue, Computed fields can now be displayed by Views → , which would seem to suggest something looking more like this:
/**
* Implements hook_views_data_alter().
*/
#[Hook('views_data_alter')]
public function addComputedFieldChangedFields(&$data) {
$data['node']['computed_example'] = [
'title' => t('Computed field example'),
'field' => [
'id' => 'field',
'default_formatter' => 'string',
'field_name' => 'computed_example',
],
];
}
}
'node' instead of 'node_field_data', no 'entity field' line.
Confirmed that i can get it to show up using Joachim's approach; here is the full thing in the object-oriented hook implementation → available from Drupal 11.1 onward:
declare(strict_types = 1);
namespace Drupal\example\Hook;
use Drupal\Core\Hook\Attribute\Hook;
class ViewsDataAlter {
/**
* Implements hook_views_data_alter().
*/
#[Hook('views_data_alter')]
public function addComputedFieldChangedFields(&$data) {
$data['node_field_data']['computed_example'] = [
'title' => t('Computed field example'),
'entity field' => 'computed_example',
'field' => [
'id' => 'computed_example',
],
];
}
}
However i am unable to test that it works beyond showing up in Views due to i think an unrelated error: 🐛 Call to undefined method Drupal\computed_field\Field\FieldStorageDefinition::getThirdPartySetting() Active
mlncn → created an issue.
Among the numerous meaningless changes for coding standards, the patch also fixes a deprecation warning:
( ! ) Deprecated: Drupal\computed_field\Plugin\ComputedField\ComputedFieldBase::createComputedFieldDefinition(): Implicitly marking parameter $bundle as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/web/modules/contrib/computed_field/src/Plugin/ComputedField/ComputedFieldBase.php on line 131
Unfortunately it breaks the module in a worse way:
PHP Fatal error: Uncaught Error: Call to a member function getName() on null in /var/www/html/web/core/lib/Drupal/Core/Config/Entity/ConfigEntityStorage.php:188
Stack trace:
#0 /var/www/html/web/core/lib/Drupal/Core/Entity/EntityStorageBase.php(312): Drupal\Core\Config\Entity\ConfigEntityStorage->doLoadMultiple()
#1 /var/www/html/web/modules/contrib/computed_field/computed_field.module(122): Drupal\Core\Entity\EntityStorageBase->loadMultiple()
#2 /var/www/html/web/core/lib/Drupal/Core/Entity/EntityFieldManager.php(415): computed_field_entity_bundle_field_info()
mlncn → created an issue.
So people searching on this JavaScript error find it, this issue will fix the critical error: Uncaught TypeError: $(...).once is not a function
Merge request 17 is off of 2.0.x now so it is ready for review!
This does not trigger an update to the index when an item is added, removed, or re-ordered in an update queue.
Possible code i'm hoping for Search API advice on in https://www.drupal.org/project/search_api/issues/3016821#comment-16054098 ✨ Sort by Entityqueue Closed: works as designed
The current problem with the code over in ✨ Search API/ SOLR integration Active is that it does not trigger an update to the index when an item is added, removed, or re-ordered in an update queue. How would that be done in Search API?
\Drupal::getContainer()->get('search_api.entity_datasource.tracking_manager')
->entityUpdate($entity);
as in https://git.drupalcode.org/project/search_api/blob/HEAD/search_api.modul... ?
This simple logic change fixes my problem.
In field_config_cardinality_field_widget_complete_form_alter the // Implementation for multi select type. had $cardinality_config >= 1 as the check to setting $elements['#multiple'] = FALSE; and my merge request here changes that to check that the cardinality equals one, which seems to make sense.
My only problem with this fix is that i cannot believe no one reported the problem for seven years, so i feel like i must be missing something?
Possibly relevant— i am on Drupal 11. (Courtesy of 📌 Automated Drupal 11 compatibility fixes for field_config_cardinality Active )
This is true whether "Select List" or "Select List (Cardinality)" is chosen for the widget.
mlncn → created an issue.
mlncn → changed the visibility of the branch 3516112-upgrade-to-drupal to active.
mlncn → changed the visibility of the branch 3516112-upgrade-to-drupal to hidden.
This is fantastic. I'll have to test it out later if nobody else gets to that first but the code and tests look great!
We are technically still in beta but we could do a 2.0.x release (side benefit: gets us in modern versioning numbers, away from 8.x-1.x) to avoid people running into form ID troubles without a little warning.
Removed the use statement in favor of \Exception because non-namespaced classes/interfaces/traits should not be referenced with use statements.
This is definitely fixed, feel like it could be done better? More specific exception maybe?
well i cannot find a way to check that there is a route before doing the match request (there probably is though?) but wrapping the attempt in an exception handler works fine. Maybe it would be better to target the specific exception if going this route (no pun intended), but this fixes the fatal error.
> $fields = \Drupal::service('value_revisions.settings')->fieldsInfo($entity);
= [
"title" => [
"field_type" => "string",
"widget_type" => "string_textfield",
],
"field_addresses" => [
"field_type" => "entity_reference",
"widget_type" => "inline_entity_form_complex",
],
"field_aka" => [
"field_type" => "string",
"widget_type" => "string_textfield",
],
"field_alternate_names" => [
"field_type" => "string",
"widget_type" => "string_textfield",
],
"field_email_addresses" => [
"field_type" => "email",
"widget_type" => "email_default",
],
"field_industries" => [
"field_type" => "list_string",
"widget_type" => "options_buttons",
],
"field_naics_codes" => [
"field_type" => "string",
"widget_type" => "string_textfield",
],
"field_phone_numbers" => [
"field_type" => "telephone",
"widget_type" => "telephone_default",
],
"field_related_actors" => [
"field_type" => "entity_reference",
"widget_type" => "entity_reference_autocomplete",
],
"field_tags" => [
"field_type" => "entity_reference",
"widget_type" => "",
],
"field_visas" => [
"field_type" => "entity_reference",
"widget_type" => "entity_reference_autocomplete",
],
"field_websites" => [
"field_type" => "link",
"widget_type" => "link_default",
],
]
When a widget is blank, as in this example for tags, that is because at some point after configuring Value Revisions for the field, the decision was made not to show the field on the form.
mlncn → created an issue.
mlncn → created an issue.
mlncn → created an issue.
And the module is done!
Administration Theme by Content Type - https://www.drupal.org/project/admin_theme_by_content_type →
I think you are right it is more straightforward for the end-user as a standalone. Thanks!
Thank you so much for your quick and kind response!
Admin Theme has the same
I am curious why Simple Admin Theme by Route uses event subscriber when alterRoutes should be enough to add _admin_route
And do you know for certain that your EventSubscriberInterface onKernelRequest() cannot set the theme for non-route things like path for the creation forms and what type of object (or rather bundle of entity) for edit forms? Since i'll have to grab the request anyway your approach seems a little more straightforward than the ThemeNegotiator approaches i'm finding.
Thank you very much for everything!
(New module coming shortly…)
In our case it was to adjust column heights in order to see the text properly (display issue probably specific to LibreOffice Calc) and also in our case to quickly confirm that the hidden Key column was using an export-specific ID (which we sort of knew it had to be, but somehow this seemed the fastest way to check).
Above commit appears to work perfectly (for the narrow and i think our only current use case of addresses); i just had thought i'd made the revision an official source when i had not. If we have any other inline entity references it should be pretty easy to expand that approach.
Well, with one more caveat— we are checking only one field on the address entity, field_address. (That one field happens to have like 14 parts, of which we currently check about half for the value hash, but it could be made all easily.) The present client actually adds another field, for the type of address (mailing, physical etc). I am willfully ignoring that in the value hash as not important enough to affect which revision the address is attributed to. But most inline entities will probably be made up of several relevant fields which would entail a different, and certainly more annoying, strategy for calculating value hashes.
See 🌱 Offer to co-maintain / issue fork for updated version Active issue fork.
See 🌱 Offer to co-maintain / issue fork for updated version Active issue fork.
See 🌱 Offer to co-maintain / issue fork for updated version Active issue fork.
Add link from FAQ to main documentation on same topic.
mlncn → created an issue.
mlncn → created an issue.
Actually the best solution would be to use https://www.drupal.org/project/entity_reference_revisions → and then we would be saving the revision ID instead of the entity ID.
So long as that is smart enough not to change the revision ID if nothing changes (doubtful?)
And provided it works with Address module.
mlncn → created an issue.
The code to make it work was partially there. The merge request finishes and fixes that work.
Also wanted to note that ECA module → could be configured to do this and it has true entity validation now ✨ eca_content: Provide plugins for entity validation Fixed
… and true entity validation, not form-level validation, is what i wanted and expected from Unique Field but that is not what Unique Field does. That should also be documented clearly or fixed, but i hope my contribution here is useful but i'm going to switch to ECA.
Still not working and this is arguably half of the documented functionality, not working, so i would call this major at least until the module page and internal documentation is updated to note this functionality is aspirational and not in fact implemented in current versions.
… fixed after a cache reload!
mlncn → created an issue.
Looks good (i've looked at a lot of these lol) and works, thank you! As noted already in the issue summary there are no compatibility concerns given Drupal core's minimum PHP requirements.
Major, because a priority major is postponed for this currently. (This and 📌 Support OOP hooks Active (or combining them into one issue again) are needed for Field Encrypt to work on Drupal 11.1.)
Definitely do think the hooks should be in separate files based on usage, loading only what is needed when it is needed is a big benefit of OOP hooks, but that can be a later code reorganization.
So it is not a Drupal Core issue (as i guess i should have expected)— it occurs due to the Drupal 11.1-compatible issue fork of Field Encrypt 📌 Support OOP hooks Active , specifically the src/FieldEncryptServiceProvider.php file, which is… not mentioned in the field_encrypt.services.yml Huh, did not realize there would be anywhere Drupal automatically interprets something not in Plugins or something like that. Anyhow if there is anything that jumps out to core maintainers for Field Encrypt to fix… 📌 Support OOP hooks Active
New merge request against the correct branch.
mlncn → changed the visibility of the branch 3511754-deprecated-implict-nullable to hidden.
mlncn → changed the visibility of the branch 3511754-update-deprecated-implicitly to hidden.
Dammit that was against 8.x-1.x and just silently made the 2.0.x changes? I never made the changes dropping 8/9! Anyway if a maintainer could make 2.0.x branch the default i'm sure that'll make contributions easier going forward.
@sergio morais are you using this module? Would you want to co-maintain?
Awesome thank you! Better than what i had locally because i had not internalized the `?` shortcut yet (seemed FormStateInterface|null but the shorter form is nicer especially with that longer form already in the docblock code comment.
mlncn → created an issue.
Excellent. A release would be a good idea still!
Preventing WSOD's by catching an exception here has become increasingly important with something that changed in Drupal 11.1 or in PHP 8.4. Something that did not used to be a noticeable warning on the status page is now a fatal error on the status page with a "White Screen Of Death", and a stack trace that starts with:
"Drupal\Component\Utility\Html::escape(): Argument #1 () must be of type string, null given, called in /var/www/html/web/core/lib/Drupal/Component/Render/FormattableMarkup.php on line 238"
And then leads the perplexed site maintainer or developer on a journey through TranslatableMarkup and Twig\Template->display() and twig_template_render and Drupal\Core\Render\Renderer->doRender among other less notable stops, with the template and rendering stuff all showing up twice. But not once does the stacktrace give a hint of what code actually started the problem.
Using a debugger one can go a few steps down (up?) the stack to Drupal\Core\StringTranslation\TranslatableMarkup and find the variables passed into it. These made clear that the underlying problem is that a custom profile has no version string. (OK, and looking at this, separate issue from this one, probably status_report_grouped should be taking care not to require information that is not required?)
(OK i must have been wrong about their being no error, i see escape() used to have this code: @trigger_error('Passing NULL to ' . __METHOD__ . ' is deprecated in drupal:9.5.0 and will trigger a PHP error from drupal:11.0.0. Pass a string instead. See https://www.drupal.org/node/3318826', E_USER_DEPRECATED);. But that does not change the fact that Drupal has increased the ways a fatal error can take down a site in ways that can have many sources and be hard to track down.)
Strict typing is great for coding. But there are too many ways a non-string can end up handed to HTML::escape() to take down a site over it.
Works great on the 4.x branch! No deprecation warnings, and Field Group still works.
(People who contributed partial fixes to issues closed as duplicates who should get credit when this is fixed include prem suthar, deepali sardana, MrDaleSmith, and nickdickinsonwilde. And solideogloria who is already over here!)