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?
One issue here is we want the trimming to happen before any other validation (at least, that is what makes sense in most use cases i have used this for or can think of), and presave happens after.
For example, if we trim a blank-spaces-only input down to nothing, that should trigger the warning on required field.
And if we clean up easy things without the person submitting the form having to do the cleanup (no leading or trailing spaces would be a reasonable constraint to have in custom logic apart from what trim does, but more than that requiring a phone number or identifying string to match a format or number of characters is common validation) and presave would force the form filler or API provider to clean up the data first as the validation would reject it before presave could happen.
We could do both, but there really should be a way to do pre-validation cleanup for both form and API data in a consistent way.
Got this working with the package.json and gulpfile.babel that can be found here: https://git.agaric.com/agaric/peceful
Main thing was dropping node-sass and using Dart's sass. Also using yarn install and yarn start instead but that probably isn't needed.
(works at least up to NodeJS 18; separate error on Node23)
This change is breaking body inject on one of our sites, causing the div we are injecting to be put inside a paragraph tag that then never closes:
<p<div class="body-inject body-inject-simple_block:example">
<div>Example stuff</div>
</div>
(That is, the paragraph never closes if you view source. Browsers resolve the open paragraph by closing it into the div bizarrely like this: </p<div>.)
Oooh very interesting. Could you describe how the event can be intercepted/used?
Surprised i could not find a follow-up but i created one here: ✨ Make easier & document validation of required fields in non-form (programmatic API) contexts Active
mlncn → created an issue.
mlncn → created an issue.
gulp causes:
Error in plugin "sass"
Message:
node_modules/motion-ui/src/util/_unit.scss
Error: Invalid CSS after " $dividend: math": expected expression (e.g. 1px, bold), was ".abs($dividend);"
on line 17 of node_modules/motion-ui/src/util/_unit.scss
from line 14 of node_modules/motion-ui/src/motion-ui.scss
from line 47 of scss/peceful.scss
>> $dividend: math.abs($dividend);
-----------------^
Which per the Foundation Motion UI issue queue seems to be some sort of problem with this setup.
But in the spirit of that one, maybe we can work out all the gulp problems here? Starting with a copy of the starterkit theme generated by my patch in ✨ Support automatic subtheme generation in Drupal 10+ / Drush 12+ Needs review
This is probably a duplicate: 📌 npm install fails if not using node 12 or 14 (as per foundation requirements) Active
But realizing i think this whole approach should be obsolete now? 📌 Making a theme compatible with core's theme generator is too difficult Needs work
Here is a patch for the composer script approach.
All right if acbramley had been listened to four years ago → i'd have avoided a few days of intermittent Drupal upgrade pain:
I'd highly recommend you revert this and instead specifically install the fields that this module is interacting with. What's currently committed is basically what was removed from core - automatic entity updates. This could cause issues on sites with other definitions that are out of whack and could in extreme cases lead to data loss.
Surprised this did not bite more people able to find there way to this issue queue.
in function hide_revision_field_apply_updates() Hide Revision Field seems to be processing fields that it is none of its business to process? It loads every field of every type of entity.
mlncn → created an issue.
This comes up on so many sites we inherit as rescues of attempted migrations, so added the work from this issue to Migration Helpers module → as a few functions available ✨ Add helpers to remove leftover field storage config Needs review to use in an update hook or a deploy hook (not drush, at the moment anyway).
If there are safe-ish ways to automatically remove invalid configurations from entity definitions bundle_field_map i would happily experiment with them there.
Two additional methods on ExorciseGhostConfigEntity:
removeFieldStorageConfig($entity_type, $bundle, $field_name)cleanUpEmptyEntityType($entity_type)
The latter is called by removeBundleFromFieldStorageConfig($entity_type, $bundle) automatically.
Really need to stress that none of this code checks if what it is removing is safe to remove. It will totally remove a completely still-in-use set of config. That it is truly no longer of use is an exercise for the user of this code.
Example of usage in an example.install:
/**
* Remove ghostly remains of old 'resources' content type (renamed resource).
*
* Implements hook_update_N().
*/
function example_update_9002() {
\Drupal::service('module_installer')->install(['migration_helpers']);
\Drupal::service('migration_helpers.exorcise_ghost_config_entity')->removeBundleFromFieldStorageConfig('node', 'resources');
\Drupal::service('module_installer')->uninstall(['migration_helpers']);
}
If this is going to happen we probably switch to building on Commerce → , which i am not against, but would be a big shift / new branch.
mlncn → created an issue.
In trying to see what would be needed for this to work, i did some quick hard-coding in /js/ckeditor5_plugins/detail/src/detailediting.js:
// Convert the <detailSummary> model into an editable <h2> widget.
conversion.for('editingDowncast').elementToElement({
model: 'detailSummary',
view: (modelElement, { writer: viewWriter }) => {
const summary = viewWriter.createEditableElement('summary', {
class: 'card-header',
});
return toWidgetEditable(summary, viewWriter);
},
});
// Convert the <detailWrapper> model into an editable <div> widget.
conversion.for('editingDowncast').elementToElement({
model: 'detailWrapper',
view: (modelElement, { writer: viewWriter }) => {
const div = viewWriter.createEditableElement('div', {
class: 'details-wrapper card-body',
});
return toWidgetEditable(div, viewWriter);
},
});
and those classes do show while editing, but they get stripped by CKEditor. I have tried making changes to allowedContent in /js/plugins/detail/plugin.js but it is not helping. I would like to help contribute an admin UI for setting classes and set up the possibility for content editor added/modified classes, but fighting with CKEditor5 and its lack of documentation for something as basic as "how do i let my plugin allow people to add classes without getting them stripped" really saps my motivation. Kudos to the module developers here! (When my search terms went from 'ckeditor5 plugin "allowedContent" any class' to 'ckeditor5 plugin development' and went through the examples and still no answers, i gave up.)
(My use case is adding classes for a CSS framework that will always be the same, not an editor setting a class, but the initial steps of wrangling more flexibility out of CKEditor5 are the same.)
related need: ability to add a class through a template?
Drupal 9 is End-of-Life so this is major.
Nice!
Advice from the search api side very welcome!
Looks good; onward toward media!
Have the same need, in this case would want to filter as well as sort— only show items that are in a given queue. A single processor plugin should handle both, right?
Note that this has also been raised from the Entityqueue side, ✨ Search API/ SOLR integration Active
And probably the processor should live there?
See also ✨ Sort by Entityqueue Active
Display order not being used for attachment order is a bug in modern Drupal: #2943293: Views attachments are not rendered in the specified order → (seems to consistently use alphabetical by machine name for order, so editing machine names is a workaround)
Filename (no path, no extension) is definitely needed as a token, and this issue has the patch that does that. Maybe it needs to be done differently or the issue refocused, but it really is a key token to have.
mlncn → created an issue.
mlncn → created an issue.
Should we document that if there is a mix of text in paragraph tags and not in paragraphs tags, the content that is not in paragraph tags will be lost? (That's how it's going to work here, correct?)
Also DuaelFr, would you be willing to be a co-maintainer for this module?
Wow! Good catch!
mlncn → created an issue.
This looks promising: https://www.drupal.org/project/drupal/issues/2835825#comment-15237330 📌 Add d8 media migration Postponed
And separate from that, we have successfully done it with an approach that doesn't use the migrate module, MigrationHelperFieldTransformations in the Migration Helpers → module, used like this:
function example_deploy_move_files_to_media() {
$transformations = [
[
'node', // entity type
['field_attachments'], // old file/IMCE fields
'field_media_attachments', // new media reference field
['page', 'forms_resources'], // bundles on the entity type that holds both the old file and new media reference fields
'document', // the destination media bundle
'field_media_document', // the destination file field on the media bundle
],
];
\Drupal::logger('nchfa_custom')->log(LogLevel::INFO, "Transformation started.");
foreach ($transformations as $transformation) {
[$entity_type, $image_field_names, $media_field_name, $bundles, $media_entity_bundle, $media_target_field] = $transformation;
/** @var \Drupal\migration_helpers\MigrationHelperFieldTransformations $field_transformations_service */
$field_transformations_service = \Drupal::service('migration_helpers.field_transformations');
$field_transformations_service->fieldToMediaEntity($entity_type, $image_field_names, $media_field_name, $bundles, $media_entity_bundle, $media_target_field);
$source_fields = implode(', ', $image_field_names);
\Drupal::logger('nchfa_custom')->log(LogLevel::INFO, "Data in image field(s) $source_fields of $entity_type entity moved to $media_field_name media reference field.");
}
}
Don't worry about the references to image in the code it works for all files!
Another vote for Kasey's comment #14 ✨ Show entity title after autocomplete selection instead of internal route (e.g., /node/123) Needs work , especially because acbramley's comment #5 ✨ Show entity title after autocomplete selection instead of internal route (e.g., /node/123) Needs work still holds five years later:
While filtering showing the title is great, and showing the alias too when filtering is cool. But i can see the alias (or the entity canonical URL) in the href field of the edit link dialog anytime.
But that fine title i could see while filtering?
I cannot get that back. I have media/5 and have to try to remember the media name or filepath!
So i agree with klidifia ✨ Display node title (a text) in by default when creating link in ckeditor5 Closed: duplicate that ✨ Display node title (a text) in by default when creating link in ckeditor5 Closed: duplicate should be re-opened, or this issue re-purposed and re-titled to distinguish the various needs:
- What is shown in the "Link URL" field when autocomplete is done? (For the record, i think that absolutely should be whatever is going to be in the final
href, which perhaps should be consistently configured via URL Substitution, and should usually be the content alias, but would be the filepath for media when URL Substitution is so configured → .) - What is used for the link text, the words that are shown between the
<a></a>tags, that can then be edited like other text in the WYSIWYG textarea. - Would be great to be able to configure what metadata to stick in as the default
titletoo, but that's definitely a different issue!
Again, especially for the use case of media with URL Substitution for the filepath, having /media/5 be what is inserted into the document and linked is singularly not useful— it loses all the context that was available a moment ago when autocompleting the document to insert as a link.
So sorry for the noise— yes, Mark, that is exactly the documentation i needed! Thank you so much!
mlncn → created an issue.
If this works in Drupal 8 can we document how? Not able to get linkit to autocomplete Drupal core media module file paths at least.
mlncn → created an issue.