Also note the clever workaround of paragraph type per term (or whatever else you are referencing) used by jglynn who posted #3326344: Serial number per taxonomy term →
Thank you again for your amazing responsiveness, created an issue at Readonly field widget: 🐛 Save of Read Only widget fails in hard to debug way when Geocoder Field is enabled Active
Going to make a try at doing this in a submodule for serial. This should take care of the requests in #3326344: Serial number per taxonomy term → and #1387152: 'Sub node' serial field → – i think, in any case i'll be first trying joachim's suggested approach in comment #1 → there.
mlncn → created an issue.
Yeah. And i figured out some whacky CSS to hide the facets section if no facets are visible!
.facets-views-plugin:has(.block-facet--links) {
display: none;
}
.facets-views-plugin:not(:has(.hidden)) {
display: flex;
}
That was our use case, probably display: block will be more common than flex. And the first :has() is not "needed" but it avoids hiding the facets permanently for the dwindling number of browsers (under 8% share) that do not support has.
Putting this here for anyone else who wants to use it, not for inclusion in Facets.
OK, fascinating that the hidden class is added rather than the block suppressed. Would like to know why. That approach makes it a lot harder to avoid outputting surrounding markup when there are no facets at all.
Also, Facets is responsible for adding CSS for classes it relies on; while a common class, hidden cannot be expected on every theme.
Pushed update for 8.x-1.x branch too because why not.
2.x branch is Drupal 11 compatible.
Release made, thank you all!
https://www.drupal.org/project/wysiwyg_linebreaks/releases/2.0.1 →
I am able to reproduce this with the same steps on a different site.
Are you sure geocoder_field submodule is enabled?!
Geocoder should be an option for the Readonly field format (in the dropdown with Plain text), just not the one selected.
The attached patch is far from the correct fix, but it is a workaround. Maybe it is more Readonly's responsibility to suppress or not trigger the settings forms of its options?
Wait, never mind, having a geocoding provider (or at least random) set up does not help. I'll try a bit more to isolate.
Thank you for trying that out promptly. Great apologies for my missing the response. All i know is it is still happening.
To be clear the part with configuring the widget looks the same, but when pressing Update it does not close, and when trying to save the whole page, that is when the blocking error occurs.
Are you certain that you have no Geocoding providers configured? I left out that negative step, sorry.
And i'm sure you're certain the geocoder_field submodule is enabled.
Updated indenting to consistent two spaces to match Drupal YAML coding standards, https://www.drupal.org/docs/develop/coding-standards/configuration-file-... →
Thank you for this!
Huh, wow, there's no way to load roles by permission with Role::loadMultiple()?
The patch did not apply even after i deleted the web/modules/contrib/ parts (that is, the patch was created relative to your Drupal site rather than relative to the module, which is what it needs). I'll give another look later, but i think the 2.x branch might have changes also.
I ended up creating the module [Dismissable blocks]( https://www.drupal.org/project/dismissableblocks → ) for this purpose.
This somehow happened to us on an up-to-date Drupal 10 site. I would say this is a bug report in that:
- It is possible to break your site in an important way (people cannot change their password or other things on their profile, and the administrator cannot either!) by installing and configuring, and uninstalling, all core modules. (Per scott_euser's excellent recreation.)
- The error message provides zero indication what the actual problem is. I was very lucky to find this issue.
Hah, i ran into this on a site we update only intermittently and uninstalled and reinstalled rather than mess with the update hooks. But then i ran into this on a site we update like every couple weeks and came to look for this issue!
Agree that these update hooks should be re-added and kept working throughout the 2.x release cycle.
This happens with list of links or checkboxes without filtering, without List item label, … seems 3.0.x-dev may be broken generally? Or i am misconfiguring.
mlncn → created an issue.
mlncn → created an issue.
I'm giving credit on this issue but not taking a lot of the changes. Maybe someone can explain while i should care someday but until then i am not making perfectly readable 89 character lines into three less readable ones because phpcs tells me too.
A fair number of the warnings appear to be at odds with Drupal's coding standards (not allowing inline doc block comments that start with /**??)
For modules i maintain please check with me before undertaking these sorts of patches, please.
(The merge request also commented out a couple variables which is absolutely not OK in a formatting patch!)
Brought in (as indented by ✨ Hide the 'Add existing [label]' form / button if there are none Needs review ).
Thanks!
Awesome, thank you for the report! It will likely help others. I was not looking forward to identifying a bug in the DOM processor!
But it does seem like it will fail if the HTML is invalid; i wonder if there is a way to make it more robust without risk of stripping out too much.
Since this works without disruption, i think we can simply run with it in the 2.x branch, putting it in the dev release now hope more people will give it a try and we'll make an official release.
Excellent, No Sssweat, thank you!
We will probably release a 3.x branch that requires core CKEditor5 instead, or maybe we should have the module not require any CKEditor and it will work with any, if there are any?
This is needs review now? Looks great to me! So many contrib modules need to try to add this, not knowing if another module already has; having core do it would be so much better!
Taking the liberty of making this active now that Help Topics has been put into core, is no longer experimental, has been merged into Help, and core has recognized the need for at least one new permission to use help pages → !
Exited to find this issue and i am hoping that jhodgdon's great work and benjifisher's and andypost's review and thoughts. I hope it can be applied to core.
This is critical for making help pages helpful. For a content editor or even a site manager to visit the help page and see documentation for every single enabled module is overwhelming and makes finding the needed help harder.
A huge advantage of built-in documentation is that it can have links to the configuration page or the block listing or whatever else— having a bunch of these links result in access denied results in an unfriendly experience.
In my opinion best practice is splitting help topics into administration/configuration and regular usage, and this permission system allows these help pages to be targeted at those they can, indeed, help.
Wow! Code looks good, and works in limited testing.
Patch does not apply, probably only needs minor re-roll.
I see it disables the action links for form mode manager globally. This is probably a useful option but personally i would go for being able to hide or rename any specific action or operations link generated by Form mode manager, if i were to take this on. But a couple of alter hooks makes that possible too.
In an `example.module` file in your custom Example module— presuming you are not using bundle subclasses for your content, the ProgramApplication parts can be dropped and this will still work:
use Drupal\example\Entity\ProgramApplication;
/**
* Implements hook_menu_local_actions_alter().
*/
function example_menu_local_actions_alter(&$local_actions) {
// Remove "Create as" link for the content form mode 'form_mode_edit_only'.
unset($local_actions['form_mode_manager.action:node.form_mode_edit_only']);
// Shorten "Create content as form_mode" link to "Create form mode".
$local_actions['form_mode_manager.action:node.application_forms']['title'] = t("Create application forms");
}
/**
* Implements hook_entity_operation_alter().
*/
function example_entity_operation_alter(&$operations, $entity) {
if ($entity instanceof ProgramApplication and isset($operations['application_forms'])) {
// Shorten the edit link e.g. it the per-node dropdown on the content admin listing page.
$operations['application_forms']['title'] = t("Edit application forms");
}
}
Agreed but i believe this is a duplicate of #3108525: Anyway to disable/hide the "Add node as xxxx" local action →
If you still have this need perhaps you could try the patch there?
Related to ✨ Permission like 'Use Example form mode with user entity" does not grant permission Needs review in the sense that both call for clarifying the permission wording and documentation.
Hmm, i think we should clarify the wording, and maybe provide a submodule with this sort of feature (expanding permissions rather than restricting).
For example, i would absolutely *not* expect that granting "Use Example form mode with Page content type" to authenticated users and anonymous users would suddenly allow people who could not edit pages before now edit them. I would hope that the most restrictive permission wins, as is usually the case in Drupal.
In the case of content, it is possible to grant the permission to create or edit to multiple roles, and then *restrict* what fields are shown to different roles with the Form Mode Manager.
Unfortunately, users do not have the breakdown of permissions you would need to do that in core (moving
The combination of these modules should make it possible to do what you have done elegantly with custom code with permissions instead:
https://www.drupal.org/project/create_user_permission →
https://www.drupal.org/project/edit_profiles_perms →
Agreed and agreed, and i would even go further, and that if possible all permissions should be granted on module install. That would both make it so the module does not make the site unusable until permissions are carefully configured, and also make it more clear how permissions should be used.
(It was already sentences, of course, i broke up one long sentence into two. I hope my edits are clearer than my commit message!)
Liked the improvement, tried to take it a little further.
Noting that i also received a similar error; in this case it was after trying to install the examples module (as YouTube seems to have taken teh demo videos down— and this is the first time i've been willing to click on a demo/tutorial video in a long time, lol) but it failed because this site manages to not have a body field:
Configuration objects provided by form_mode_manager_examples have unmet dependencies: field.field.node.node_form_mode_example.body
(field.storage.node.body)
However, Form Mode Manager itself *did* get installed. Maybe not fully though?
In my case, uninstalling form_mode_manager and installing it again (no example or submodules) worked. Maybe a simple cache clear would have worked too; maybe that's the only thing the initial install choking on the examples module missed.
Putting this here for anyone else searching for this error:
The website encountered an unexpected error. Try again later.
Drupal\Component\Plugin\Exception\InvalidPluginDefinitionException: The "node" entity type did not specify a "fmm_application_forms" form class. in Drupal\Core\Entity\EntityTypeManager->getFormObject() (line 212 of core/lib/Drupal/Core/Entity/EntityTypeManager.php).
Drupal\form_mode_manager\AbstractEntityFormModesFactory->getForm(Object, 'fmm_application_forms') (Line: 202)
Drupal\form_mode_manager\AbstractEntityFormModesFactory->entityAdd(Object) (Line: 206)
Drupal\form_mode_manager\Controller\FormModeManagerEntityController->getEntityControllerResponse('entityAdd', Object) (Line: 163)
Drupal\form_mode_manager\Controller\FormModeManagerEntityController->entityAdd(Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 638)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 121)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 181)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 53)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object, 1, 1) (Line: 741)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)
With the initial release of the module, this is ready for review.
mlncn → created an issue.
Remove link to no-longer-offered service.
I am working on a modern Drupal version of Cite that builds on Bibliography & Citation: https://www.drupal.org/project/cite/issues/3464149 🌱 Modern Drupal version based on Bibcite Active
AardWolf, how do you tell a Reference to be viewable as one or several particular CSL styles? I get the option to download various formats (BibTeX, Endnote of several varieties, etc) but not to display the citation in, say, Chicago Manual of Style 16th edition, even though it is one of the installed styles.
Updated summary.
I was going to file an issue that the arrow to an action block should not be deleted with the block— at least if there are any conditions on the arrow, there should be a warning. But it seems making undo/redo capability (as a keyboard shortcut or with buttons/links) would take care of this issue. If ECA does get used in Starshot, #3449154: Include ECA (without UI) with a number of pre-configured models as recipes → , even without the UI, it would naturally bring a lot of people to try this out as representing the Full Power of Drupal™, and undo/redo then is critical. So bumping up the priority in the hopes more people see it— probably not in my capacity to take on.
Looks like this module could indeed use another co-maintainer… and thrilled for it not to be me!
While i think it is customary for someone offering to maintain to have contributed patches or reviewed other issues already – such as perhaps ✨ Decorate plugin.manager.extra_field_display service instead of creating plugin.manager.extra_field_plus_display Needs review – i'll also note that UsingSession is an active maintainer on several modules already, and has my vote to help out here.
Related, possible duplicate, 🐛 Links widget is loading the checkbox widget JS library Needs work , and wow i 1,000% agree with all that have worked on both issues that links should not be converted to spans by JavaScript needlessly! In addition to all the problems mentioned, it means that a theme's link stylings are not used. This is at least major and this surprisingly simple patch fixes it all, for me. Less code, much less overhead, better functionality == win.
Was all right there in the issue branch; now it is a merge request too.
Wow, awesome work!
Maybe this is related to 🐛 The menus should be aligned with the submenus Needs work ?
This is due to the new-in-Drupal-9 stable9 subtheme not being enabled. See 🐛 The base theme stable9 is not enabled when updating the theme on Drupal 9.x Active
Is this fixed by the more targeted approach in 🐛 Bulma CSS inherits white colour for local tasks menu links in .hero region, making them invisible. RTBC (committed to both 8.x-1.x and 3.0.x-dev branches)?
Javascript is removed from the 3.0.x branch.
This is fixed more generically and not only for webform in ✨ Add asterisk to webform required fields Fixed . Can folks here confirm, testing either supported dev release (1.x or 3.x)?
File icon function updated for D11 compatibility.
Same fix in both 3.0.x and 8.x-1.x, please review!
The committed approach should make this work without the need for JavaScript.
Added to 8.x-1.x-dev and 3.0.x-dev. Manually applied given the conflict in the compiled CSS. Separate commits for SCSS and compiling the CSS makes merge conflicts / cherry-picking easier.
Further testing welcome before releases are made!
Thanks again Jaydeep, and Medden, and Riddhi!
Thank you Jaydeep for fixing this without using !important!
Added to 8.x-1.x-dev and 3.0.x-dev, further testing welcome before releases are made!
This should be able to be done with a CSS variable also; followups welcome for that.
Also, do we need a countervailing fix for dark mode? (Using a CSS variable may solve that at the same time.)
In the future i appreciate separate commits for SCSS and compiling the CSS— easier to cherry-pick across branches, among other things.
Thanks all!
I have the branch working for my purpose.* Needs to switch to using "{entity_type}__{entity_id}" as a composite key with the action ID as keys as the nested array for ensuring that validation errors can be stashed to our hearts content without any risk of collision.
But i am sure there is a lot more maintainers will want to change before bringing this in.
*Validation works when an entity reference field is filled out, even when using Inline Entity Form to reference the existing entity— it does not work for inline entity form creating a new entity. Process form on the other hand did not pick up even the existing entity reference on initial save; i am sure that is possible without this validation layer integration but it was enough of a hiccup to get me moving on this.
Attached is a model with this working; requires a vocabulary 'sources' and a term reference 'field_source' to it on article nodes.
I think this is very needed (see people stumbling without it for example in 💬 Workflow Content moderation condition Closed: outdated ).
However, the direction of all the patches confuses me— they all seem to be trying to provide standalone content moderation state tokens, when what is needed is a token on entities with content moderation enabled.
So, [node:moderation_state] (or likely [node:moderation_state:id] and [node:moderation_state:label]). The original state should be accessible on the original node token.
Indeed, without any of these patches, i already have standalone Content moderation state tokens ([content_moderation_state:content_entity_id], [content_moderation_state:id] (an integer…), [content_moderation_state:moderation_state:value]), they just don't work in any context relevant to me, and these patches do not seem to change that.
I'll note that it is reasonable to want to disable breadcrumbs — especially as a workaround to get rid of the "Back to site" feature pending ✨ Remove the 'Back to site' link on admin-only sites Needs work — and it would be nice to have the option to show the very useful content type information on node edit pages.
I think i may have the event dispatch part figured out, but how do we get back from the action "into" the validator so as to return the custom message?
OK i see those are from ✨ Support the 'add_existing_widget' setting from #2683125 Needs review as i thought and should have already checked. Still willing to adopt everything that is stuck getting into IEF and then, i hope, getting everything into IEF (in particular ✨ Prioritize 'add existing' in nested entity creation UX to prevent duplication. Needs work ) and obsoleting this module entirely!
The patch did not apply, but i think i brought this in faithfully except the ief_items and ief_add_existing_widget properties which did not exist in this module and do not yet exist in Inline Entity Form either. Talking about these lines that existed in the patch both as if already there and only getting indented in for the conditional:
'#ief_items' => $items,
'#ief_add_existing_widget' => $this->getSetting('add_existing_widget'),
Leaving open for any further bot updates.
Until ✨ Restrict bundles for "Add new" (taxonomy term, etc) when "Add existing" is powered by an entity reference view Needs review this module provided no configuration at all, in my understanding. But ah, it does need to explicitly extend field.widget.settings.inline_entity_form_complex because it is our widget that is ultimately saving the configuration.
Do you know how to add onto inline_entity_form.schema.yml the restrict_to_bundle configuration option we just added?
This is implemented in IEF Complex Open widget → for the time being, and here is how, this same change could work for IEF itself:
https://git.drupalcode.org/project/ief_complex_open/-/commit/6863903b015...
This is implemented in the dev branch now.
mlncn → created an issue.
I do think i like this better and would accept a patch doing this / making this an option!
Thanks! Would it make sense to bring this feature into IEF - Complex Open until/if it gets accepted into IEF?
mlncn → created an issue.