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.
Very much in favor of this direction and would like to help! If there are any top-of-your-head thoughts to start with i'd appreciate any and all pointers. I have made a couple validation plugins and i would presume the approach will be to create "the last validation plugin you'll ever need" that hands the entity off to ECA and returns any message ECA wants to.
i think this is code i was starting to add related to this, throwing it here for now will delete if it doesn't make sense.
/**
* Gets the bundles for which the current user has create access.
*
* @return string[]
* The list of bundles.
*/
protected function getCreateBundles() {
$create_bundles = [];
foreach ($this->getTargetBundles() as $bundle) {
if ($this->getAccessHandler()->createAccess($bundle)) {
$create_bundles[] = $bundle;
}
}
$allowed_bundles = ['sources'];
if ($allowed_bundles) {
$create_bundles = array_intersect($allowed_bundles, $create_bundles);
}
return $create_bundles;
}
mlncn → created an issue.
Of course, we could try to get our recipe into Starshot itself.
Bringing this in; would be excellent to have a test before we make a release.
mlncn → made their first commit to this issue’s fork.
OK i'm arriving here only a couple weeks after it was closed, so i will not immediately re-open, but i agree that this is definitely a good idea for Drupal core to do.
It's a → recurring request → .
Aha, it is already in progress over here: ✨ Allow password on registration without disabling e-mail verification Needs work
Updating status accordingly!
If you have ended up here looking for a solution for this with modern Drupal (or for Drupal 7 for that matter), currently you do need a module to do this:
Can't figure out how to get it to re-test on Drupal 11— it gives me Drupal 7 only as an option?!? So seeing if setting to Needs review kicks the bots into gear.
Also, for people looking for an immediate solution the module mentioned for D7, User Registration Password (user_registrationpassword) is available and supported for modern Drupal (8, 9, 10…) now!
It feels kind of tautological, but i guess no more than the other tests, looking at "Explicitly add and validate tokens" in the CSRF access checking documentation → it looks like generating the URL like this would work:
Url::fromRoute(
'entity.block.disable',
['block' => $this->blockId],
['query' => [
'token' => \Drupal::getContainer()->get('csrf_token')->get("admin/structure/block/manage/{$block->id()}/disable")
]]);
Here is the issue for a contextual link to disable the block, ✨ Add contextual menu item on blocks to allow disabling them Needs work
The contextual menu is another place this could be done, but i'd call that a separate feature request, whereas i really do feel the inability to disable a block from the main configuration page for that block is a usability bug. In particular because not having the disable link on the block configuration page makes the contextual links way less useful. You want to quickly disable a block—not remove it, which would lose all the configuration associated with it (including which pages to show on)—and you choose "Configure block" but now to disable it you would have to go to Block layout and find the block, which defeats the purpose of the contextual links.
Screenshots of the current situation.
Configure block page:
Block layout page:
As both a module maker and a site builder—with frighteningly close to an equal (large) number of each—let me weigh in heavily on the side of the sitebuilder here and let us please make no title the default, and module maintainers who want titles to be shown for their blocks by default should affirmatively add it.
The 4.0.x version does not fix my problem— toggles appear off even if they aren't.
Amazing agunjan085! I wish i could give you credit three times here.
Thank you for the review, Nidhi!
Taxonomy is installed on most Drupal sites so this does not seem like it would be an error that could happen, but sometimes when installing a site from an installation profile or directly from contrib this error can occur and break things. Straightforward fix!
Right, sorry: 118.0 (64-bit)
(Still have not closed it and restarted, which i really bet will fix it, but it's simply so weird i had to post to see if it has happened to anyone else and if there is some potential mitigation the theme can do.)
mlncn → created an issue.
Thank you Gunjan this is great fast work! I think it is pretty much ready to be added as a feature! You made a code improvement with the use of instanceof, you added the help page, rolling out this feature in the way you implemented it should not change the way existing sites work, and it makes it easy to opt out for specific content types— very nice!
It would be ideal if it could gather all bundles across content entities (so in Drupal core, taxonomy term vocabularies and users (single bundle)). While nodes covers the 80% use case, it's always ideal to cover everything in core, and also the config schema would probably have to change if we do this later.
That said if you do not have time for that the only thing i really want to change before adding this feature is quick cosmetic things:
- The title of the settings page can simply be "Trim settings"
- The description can be "Exclude content types from Trim."
- I don't want to add another permission to anyone's Drupal site but maybe we could use one a bit more targeted than administer site configuration— perhaps administer content types?
This is great thank you, and thank you Dustin for the suggestion!
Oh wow, that is so silly. I have been complaining about the extra hoops new contributors have to go through for a while. Before i complain too much more (and before we get you the authorized status you clearly deserve), could you help me understand exactly the situation?
I thought that you would be able to make releases (at least alpha and beta releases) but not be able to opt into listed security coverage until getting the project application authorization (for at least one project).
I'd really appreciate if you could follow this process:
https://www.drupal.org/docs/develop/git/git-for-drupal-project-maintaine... →
and send me screenshots where things break down (either here or at ben at agaric coop).
Thanks!
The approach both here and with Simple Styleguide → seems to be that an administrator enters in the hex code for the colors— is that the case?
I would expect a styleguide to get colors from class names. (It's more manual setup but the example for Style Guide (Admin) → takes that approach.)
In particular with CSS variables a styleguide that helps people (not only theme developers) see the effects of their changes is what i was looking for. (Sorry, asking all this because i did not use Styleguide Color Palette in Drupal 7.)
Bizarrely this change record does not link to the documentation for the table element, here that is:
https://api.drupal.org/api/drupal/core!lib!Drupal!Core!Render!Element!Ta...
The default Twig template for tables may also be helpful: https://api.drupal.org/api/drupal/core!modules!system!templates!table.ht...
The full list of render elements is here: https://api.drupal.org/api/drupal/elements/11.x
(Note that there are two pages of them, and table is on page 2.)
Agreed on this change; making a word all uppercase should be a stylistic choice with CSS while the source stays in normal case per best/Drupal practice (although reportedly it is not a major accessibility concern; most screenreaders identify words and only spell out acronyms).
Everything gcb said certainly makes sense dropping in without a lot of context. We are getting "Data too long for column 'menu_name'" (for insert into menu_tree) on pressing "Manage Layout" which… no idea how a menu could be getting involved in the preview? Maybe there's something hooking on entity create and trying to create it and it has nothing to do with layout builder? Except the result is a white screen of death from layout builder.
Agreed this would be very useful! Right now the orders listing is not nearly as nice as the receipt.
Hmm, maybe this only has to be better documented because given ✨ Expose "Receipt" link views field for completed orders Fixed a version of this (receipt at somewhere other than an `/admin` path) must be happening?
Confirmed that the merge request fixes this! Taxonomy import was running, i presume in circles, for more than an hour before i ended drush, added this merge request, and then it imported fine.
This looks great when set to add existing first, significantly better than IEF Complex Open.
A bug, however: If multiple bundles are possible (at least if the entity reference field uses an entity reference view) then the first bundle is used, rather than providing the editor with a chance to select (as is the default) or allowing the sitebuilder to limit to one ( ✨ Restrict bundles for "Add new" (taxonomy term, etc) when "Add existing" is powered by an entity reference view Active ).
… realized i was totally looking at the widget from IEF Complex Open but IEF will have the same problem when ✨ Prioritize 'add existing' in nested entity creation UX to prevent duplication. Needs work lands, and the feature may be useful independently, so updating the description and screenshot and leaving this here!
mlncn → created an issue.
Wanted to mention IEF Complex Open module → as a current partial workaround, putting an open autocomplete add reference form first and putting the "add new" button below it. (Not because i'm a maintainer but because i read through this issue and all its related ones looking for it after i misremembered it as "ief_open" 🤦)
Forum is gone now making the forum-specific parts of this contrib's problem now. As a former core module we should still coordinate but are forum module → maintainers comfortable with core getting this transition done ASAP? It's a real shock when this mystery description field shows up on the "Manage form display" but not the manage field list, given that the node body field has been removable for so long.
Not a great time in 11's cycle but maybe we can do this first thing in 12?
mlncn → created an issue.
Because Give has the key feature to allow people to register their intent to donate (with amount, name, and e-mail address) before finding their credit card, it is possible to have evident spam to remove at this stage (honeypot can be used here).
There can also indeed be thousands of actual spam donations, as Stripe pushes the responsibility for identifying mass credit card testing, which they could easily spot, onto small merchants and nonprofits that cannot easily fix this. (A minimum donation of more than $3 does seem to fix this.) Right now it is easier to mass return the transactions in Stripe though than to do the corresponding cleanup in Give.
It would be nice to make this a view and use core bulk operations or https://www.drupal.org/project/views_bulk_operations → to do mass deletion.
Thank you!
What Date Recur Search API is doing is creating a new index so that it can make copies of a piece of content for every recurring date. I don't know yet if Date Recur puts each occurrence into a separate delta like Smart Date Recur (at first look i thought it did), but the key part with Search API integration is that each of the dates (lets say multiple values in a multiple value field) produces a new item in the search index. So an event with ten dates gets added to the index ten times, once for each date.
If Date Recur does multivalue like Smart Date Recur it will i hope be trivial to modify Date Recur Search API, and then the question is should that be a bundled submodule of Smart Date or live on its own. But if there is another way to be able to see the same node multiple times for each datetime in a Search API listing, so that exposed sorts and exposed filters work as expected … well i probably should open / look for a feature request for that.
I have an issue fork going over in Entityqueue and would very much appreciate Search API eyes on an initial review: https://git.drupalcode.org/issue/entityqueue-3004722/-/compare/8.x-1.x.....
It still needs to be made configurable per entityqueue. Can that be done at the Views integration layer (or is it better off done somewhere else anyway)?
This issue fork could really use some initial review from people knowledgeable about Entityqueue and Search API.
It works for my purpose but definitely needs work (in particular needs to deal appropriately with the eventuality that the same entity gets added to more than one entityqueue).
mlncn → created an issue.
We are running into the same thing and it feels like a pretty major gap for a module that is supposed to look at paths and not care how the paths are created.
$trail_url->getRouteName() is views.people.page and $trail_url->getRouteParameters() is view_id: "people", display_id: "page".
$this->menuLinkManager->loadLinksByRoute(), called in getActiveTrailLink(), claims that the above is not in the main menu, but it is there as a Views-provided menu link as noted by sense-design.
This might be worth finding a way to warn people when the limit is hit, because it is very unexpected to run into say when you have 21 content types on the site you inherited and "Article" is no longer available from the menu!
When we ran into this issue it was for a piece of content that had maybe a hundred paragraphs, most with images in them— but i think it is reasonable to expect that what happens in any given media widget should be unaffected by the context from where that widget was called.
And the cause was this, as found in the Apache web server log:
Got error 'PHP message: PHP Warning: Unknown: Input variables exceeded 1000. To increase the limit change max_input_vars in php.ini. in Unknown on line 0', referer: https://example.com/node/16/edit
Increasing max_input_vars to 2000 fixed it for us.
mlncn → created an issue.
As of the forthcoming Drupal 10.3, we can include a Starterkit theme → .
Starterkit themes now use starterkit.yml file →
See also https://mglaman.dev/blog/improving-drupal-theme-starterkit-and-theme-gen...
This is awesome. Created a starterkit theme. Only issue is that any "dot" file was not copied over— .gitignore, .nvmrc —and these are pretty useful files for the new themes. Is this intentional or an oversight? Is there a way to override the behavior?