🇺🇸United States @mortona2k

I am also encountering this issue with checkboxes.

The field with checkboxes should be visible and required when a select list has a certain value. Hiding it is working, but making it required is not. Setting the field to required, and using states to make it optional is also not working.

I added a patch for altering the content before extracting tags.

In a custom hook, I rendered the entity and stripped tags to get the full text including paragraphs and layout builder content.

This works for now, but a better way to go would be to create a new plugin for the field widget. It's tricky because the javascript loads values from the form to pass to the controller.

Some additional logic might be needed, like a way to ignore certain fields or values that might be more like labels and not relevant for content tags.

mortona2k → changed the visibility of the branch master to hidden.

Instructions:

Add the github repo to your project's root composer.json.

    "repositories": {
        "tablesorter": {
            "type": "vcs",
            "url": "https://github.com/mottie/tablesorter"
        },
    }

Then run composer require mottie/tablesorter.

Updating description.

I started by checking if the config is set in a handful of places, but then realized it was easier to create a new config when not yet set.

This could use some adjustment, but it is working. Some code from the earlier approach may still exist.

Rewriting issue.

This actually does use batch, but takes a while to load it, and seems to hang first.

On previous attemps, with ES selected as a language to sync, it would hang after a few minutes and then crash.

It's difficult to tell whether it will work or not because there is no indication of activity until you see the batch or an error.

The RDF module was removed from core in Drupal 10. https://www.drupal.org/node/3307288 →

Is that needed for this module?

Fixed by setting default if empty.

mortona2k → created an issue.

Maybe treat that path as an alias, with a config form setting that checks if it's an existing route on save?

Upgrading to 2.0.0 fixed it.

I just got this with the 1.0.2 release and drupal 10.5.1.

Custom theme with patch:

This issue persists in the current version.

Without patch:

Notice the marker is up against the edge and the outline overflows the container.

With patch:

This issue is causing this to happen in my custom theme:

mortona2k → made their first commit to this issue’s fork.

As a workaround, when I want to override a css file, I extend the library and also override it and set it to false.

mortona2k → created an issue.

I'm not sure how to fix this at the entity level. Here's an entity reference selection plugin that works for the specific external entity type.

I fixed the link.

For consideration, there is a list link in the dropdown, but edit is shown by default. Maybe this should be the first link instead?

Another option is to link the external entity type label.

mortona2k → made their first commit to this issue’s fork.

mortona2k → created an issue.

Patch for the fix. I don't see this issue anywhere else in the code.

mortona2k → created an issue.

mortona2k → created an issue.

mortona2k → created an issue.

To test installing a module with a patched composer.json or info file, clone the issue branch somewhere, like modules/pinnned, then set up a path repository that points to it in your main project's composer.json.

Handful of improvements.

The main change is switching the library to load the stylesheet instead of the JS. https://git.drupalcode.org/issue/unocss_starter-3537725/-/blob/92c79d8d0...

Tailwind reset used instead of normalize: https://git.drupalcode.org/issue/unocss_starter-3537725/-/blob/92c79d8d0...

As a backup, the variable can be set in preflights with: https://git.drupalcode.org/issue/unocss_starter-3537725/-/blob/92c79d8d0...

Additional vite server settings for ddev: https://git.drupalcode.org/issue/unocss_starter-3537725/-/compare/0.3.x....

mortona2k → created an issue.

It looks like the order of libraries is fixed in the head for dev mode, but not the body.

Without the patch, it looks like my theme libraries are loaded in the body after component libraries.

With the patch, the styles in the head appear to be in the correct order, matching build mode.
The body styles are the same as without the patch, although they are different I think.

Seems to be working.

Here's what I'm seeing without the patch:

Without dev mode (all libraries in header):

<head>
<link rel="stylesheet" media="all" href="/themes/custom/mantra_starter/dist/unocss.css?szv5so" />
<link rel="stylesheet" media="all" href="/themes/custom/mantra_starter/dist/base.css?szv5so" />
<link rel="stylesheet" media="all" href="/themes/custom/mantra_starter/dist/layout.css?szv5so" />
<link rel="stylesheet" media="all" href="/themes/custom/mantra_starter/dist/progress.css?szv5so" />
<link rel="stylesheet" media="all" href="/themes/custom/mantra_starter/dist/messages.css?szv5so" />
<link rel="stylesheet" media="all" href="/themes/custom/mantra_starter/dist/branding.css?szv5so" />
<link rel="stylesheet" media="all" href="/themes/custom/mantra_starter/dist/page.css?szv5so" />
<link rel="stylesheet" media="all" href="/themes/custom/mantra_starter/dist/page_footer.css?szv5so" />
<link rel="stylesheet" media="all" href="/themes/custom/mantra_starter/dist/page_header.css?szv5so" />
<link rel="stylesheet" media="all" href="/themes/custom/mantra_starter/dist/page_main.css?szv5so" />
<link rel="stylesheet" media="all" href="/themes/custom/mantra_starter/dist/responsive_menu.css?szv5so" />
<link rel="stylesheet" media="all" href="/themes/custom/mantra_starter/dist/responsive_menu_toggle.css?szv5so" />
<link rel="stylesheet" media="all" href="/themes/custom/mantra_starter/dist/component.css?szv5so" />
<link rel="stylesheet" media="all" href="/themes/custom/mantra_starter/dist/node.css?szv5so" />
<link rel="stylesheet" media="all" href="/themes/custom/mantra_starter/dist/toolbar.css?szv5so" />
<link rel="stylesheet" media="all" href="/themes/custom/mantra_starter/dist/prism.css?szv5so" />
</head>

With dev mode (Initially loads in footer, then injects into header):

<body>
<script src="https://mantra.ddev.site:5173/components/branding/branding.css" type="module"></script>
<script src="https://mantra.ddev.site:5173/components/layout/page/page.css" type="module"></script>
<script src="https://mantra.ddev.site:5173/components/layout/page/page_footer/page_footer.css" type="module"></script>
<script src="https://mantra.ddev.site:5173/components/layout/page/page_header/page_header.css" type="module"></script>
<script src="https://mantra.ddev.site:5173/components/layout/page/page_main/page_main.css" type="module"></script>
<script src="https://mantra.ddev.site:5173/components/responsive_menu/responsive_menu.css" type="module"></script>
<script src="https://mantra.ddev.site:5173/components/responsive_menu/responsive_menu_toggle/responsive_menu_toggle.css" type="module"></script>
<script src="https://mantra.ddev.site:5173/components/responsive_menu/responsive_menu_toggle/responsive_menu_toggle.js" type="module"></script>
...
<script src="https://mantra.ddev.site:5173/libraries/global/base.css" type="module"></script>
<script src="https://mantra.ddev.site:5173/libraries/global/layout.css" type="module"></script>
<script src="https://mantra.ddev.site:5173/libraries/global/component.css" type="module"></script>
<script src="https://mantra.ddev.site:5173/libraries/drupal/node.css" type="module"></script>
</body>

And with the patch:

With dev mode:

<head>
<style type="text/css" data-vite-dev-id="/var/www/html/web/themes/custom/mantra_starter/libraries/unocss/unocss.css"></style>
<style type="text/css" data-vite-dev-id="/var/www/html/web/themes/custom/mantra_starter/libraries/global/base.css"></style>
<style type="text/css" data-vite-dev-id="/var/www/html/web/themes/custom/mantra_starter/libraries/global/layout.css"></style>
<style type="text/css" data-vite-dev-id="/var/www/html/web/themes/custom/mantra_starter/libraries/drupal/progress.css"></style>
<style type="text/css" data-vite-dev-id="/var/www/html/web/themes/custom/mantra_starter/libraries/drupal/messages.css"></style>
<style type="text/css" data-vite-dev-id="/var/www/html/web/themes/custom/mantra_starter/components/branding/branding.css"></style>
<style type="text/css" data-vite-dev-id="/var/www/html/web/themes/custom/mantra_starter/components/layout/page/page.css"></style>
<style type="text/css" data-vite-dev-id="/var/www/html/web/themes/custom/mantra_starter/components/layout/page/page_footer/page_footer.css"></style>
<style type="text/css" data-vite-dev-id="/var/www/html/web/themes/custom/mantra_starter/components/layout/page/page_header/page_header.css"></style>
<style type="text/css" data-vite-dev-id="/var/www/html/web/themes/custom/mantra_starter/components/layout/page/page_main/page_main.css"></style>
<style type="text/css" data-vite-dev-id="/var/www/html/web/themes/custom/mantra_starter/components/responsive_menu/responsive_menu.css"></style>
<style type="text/css" data-vite-dev-id="/var/www/html/web/themes/custom/mantra_starter/components/responsive_menu/responsive_menu_toggle/responsive_menu_toggle.css"></style>
<style type="text/css" data-vite-dev-id="/var/www/html/web/themes/custom/mantra_starter/libraries/global/component.css"></style>
<style type="text/css" data-vite-dev-id="/var/www/html/web/themes/custom/mantra_starter/libraries/drupal/node.css"></style>
<style type="text/css" data-vite-dev-id="/var/www/html/web/themes/custom/mantra_starter/libraries/drupal/toolbar.theme.css"></style>
<style type="text/css" data-vite-dev-id="/var/www/html/web/themes/custom/mantra_starter/libraries/modules/prism.theme.css"></style>
</head>

<body>
<script src="https://mantra.ddev.site:5173/libraries/unocss/unocss.css" data-vite-dev-id="/var/www/html/web/themes/custom/mantra_starter/libraries/unocss/unocss.css" type="module"></script>
...
<script src="https://mantra.ddev.site:5173/components/branding/branding.css" data-vite-dev-id="/var/www/html/web/themes/custom/mantra_starter/components/branding/branding.css" type="module"></script>
<script src="https://mantra.ddev.site:5173/components/layout/page/page.css" data-vite-dev-id="/var/www/html/web/themes/custom/mantra_starter/components/layout/page/page.css" type="module"></script>
<script src="https://mantra.ddev.site:5173/components/layout/page/page_footer/page_footer.css" data-vite-dev-id="/var/www/html/web/themes/custom/mantra_starter/components/layout/page/page_footer/page_footer.css" type="module"></script>
<script src="https://mantra.ddev.site:5173/components/layout/page/page_header/page_header.css" data-vite-dev-id="/var/www/html/web/themes/custom/mantra_starter/components/layout/page/page_header/page_header.css" type="module"></script>
<script src="https://mantra.ddev.site:5173/components/layout/page/page_main/page_main.css" data-vite-dev-id="/var/www/html/web/themes/custom/mantra_starter/components/layout/page/page_main/page_main.css" type="module"></script>
<script src="https://mantra.ddev.site:5173/components/responsive_menu/responsive_menu.css" data-vite-dev-id="/var/www/html/web/themes/custom/mantra_starter/components/responsive_menu/responsive_menu.css" type="module"></script>
<script src="https://mantra.ddev.site:5173/components/responsive_menu/responsive_menu_toggle/responsive_menu_toggle.css" data-vite-dev-id="/var/www/html/web/themes/custom/mantra_starter/components/responsive_menu/responsive_menu_toggle/responsive_menu_toggle.css" type="module"></script>
...
<script src="https://mantra.ddev.site:5173/libraries/global/base.css" data-vite-dev-id="/var/www/html/web/themes/custom/mantra_starter/libraries/global/base.css" type="module"></script>
<script src="https://mantra.ddev.site:5173/libraries/global/layout.css" data-vite-dev-id="/var/www/html/web/themes/custom/mantra_starter/libraries/global/layout.css" type="module"></script>
<script src="https://mantra.ddev.site:5173/libraries/global/component.css" data-vite-dev-id="/var/www/html/web/themes/custom/mantra_starter/libraries/global/component.css" type="module"></script>
<script src="https://mantra.ddev.site:5173/libraries/drupal/node.css" data-vite-dev-id="/var/www/html/web/themes/custom/mantra_starter/libraries/drupal/node.css" type="module"></script>
<script src="/libraries/prism/prism.js?v=10.5.1"></script>
<script src="https://mantra.ddev.site:5173/libraries/modules/prism.theme.css" data-vite-dev-id="/var/www/html/web/themes/custom/mantra_starter/libraries/modules/prism.theme.css" type="module"></script>
</body>

Without dev mode (same?):

<head>
<link rel="stylesheet" media="all" href="/themes/custom/mantra_starter/dist/unocss.css?szv5wu" />
<link rel="stylesheet" media="all" href="/themes/custom/mantra_starter/dist/base.css?szv5wu" />
<link rel="stylesheet" media="all" href="/themes/custom/mantra_starter/dist/layout.css?szv5wu" />
<link rel="stylesheet" media="all" href="/themes/custom/mantra_starter/dist/progress.css?szv5wu" />
<link rel="stylesheet" media="all" href="/themes/custom/mantra_starter/dist/messages.css?szv5wu" />
<link rel="stylesheet" media="all" href="/themes/custom/mantra_starter/dist/branding.css?szv5wu" />
<link rel="stylesheet" media="all" href="/themes/custom/mantra_starter/dist/page.css?szv5wu" />
<link rel="stylesheet" media="all" href="/themes/custom/mantra_starter/dist/page_footer.css?szv5wu" />
<link rel="stylesheet" media="all" href="/themes/custom/mantra_starter/dist/page_header.css?szv5wu" />
<link rel="stylesheet" media="all" href="/themes/custom/mantra_starter/dist/page_main.css?szv5wu" />
<link rel="stylesheet" media="all" href="/themes/custom/mantra_starter/dist/responsive_menu.css?szv5wu" />
<link rel="stylesheet" media="all" href="/themes/custom/mantra_starter/dist/responsive_menu_toggle.css?szv5wu" />
<link rel="stylesheet" media="all" href="/themes/custom/mantra_starter/dist/component.css?szv5wu" />
<link rel="stylesheet" media="all" href="/themes/custom/mantra_starter/dist/node.css?szv5wu" />
<link rel="stylesheet" media="all" href="/themes/custom/mantra_starter/dist/toolbar.css?szv5wu" />
<link rel="stylesheet" media="all" href="/themes/custom/mantra_starter/dist/prism.css?szv5wu" />
</head>

Rewrote issue.

I have been pondering about tables in Drupal for quite a while.

We have all kinds of tables. HTML tables in the editor, or in templates. Views tables, and admin UI.

There is a table theme hook, which can make the header sticky. But views does not use this.

There are draggable tables for multivalue fields, and responsive tables that make columns disappear.

There are different styles and layouts for tables, like scrolling horizontally when they don't fit, or a small/compact version vs full width.

Lots of fixes are implemented in themes like Gin, and need to be rebuilt for your own. Try using your custom theme as the admin theme and you will encounter UI challenges that can be tedious to fix.

Views has a pretty powerful table display, but it's still limited. Modules like Views Aggregator Plus and Views Table Rowspan add additional features, but they can't be combined.

This issue started as a suggestion to use the table hook or something similar. Then it was asked if views could render the table. What seems to be missing is some kind of unified table API.

I recently looked into front end table components like DataTables (https://datatables.net/). But that made me question whether this (still jquery) library is any better than what we can already do with the views table (sort/filter/search via ajax).

There is the TanStack table (https://tanstack.com/table/latest), which is a different paradigm since it's sort of a full stack component, but unlike views, is not a query builder.

The thing I like about these libraries are that they are quite robust and fully documented. Making complex tables in Drupal can be pretty rough if you don't know about things like views development or advanced theming.

I can't quite visualize the solution I'm looking for. But I think these two libraries represent the major paradigm shift for drupal and web development. We used to render a table in the back end and sprinkle it with jquery on the front end. Now we want a unified component on the front/back end so we can reasonably work on more complex components without things becoming tangled or inconsistent.

A further question is whether tables are the right choice for these admin screens. Are they really tabular data, or are we just trying to display info in a grid? Responsive tables that collapse (IE tablesaw library) are generally preferred on mobile devices vs horizontal scrolling, especially for an interactive UI like a content type's fields config. I like the ability to copy and paste field settings into a spreadsheet, but having a usable UI on my device is more important.

I'll experiment some more next time I get a chance, but this was with an entity reference on a node, referencing an external entity.

I have not tried it between two external entities.

Fix default image paths.

SVG and images get inlined in the css. Large image files get copied to dist.

Seems like settings the base path in vite.config.js to './' is working. Needs some testing.

By setting the base path to './' in vite.config.js, component images are working with relative paths.
https://git.drupalcode.org/project/unocss_starter/-/blob/0.3.x/demo/unoc...

--un-bg-opacity was not being set, so I added /100 to the color class, and that seemed to work.
https://git.drupalcode.org/project/unocss_starter/-/blob/0.3.x/demo/unoc...

The issue description is a bit confusing.

What I'd like to do is have an entity reference field that can reference external entities using the external entity ID.

This seems similar to annotations? I just tried that and was not able to reference an external entity by ID using autocomplete. There are a list of items that I loaded so far if I use the select element, but it throws an error that I can't use them.

Patch for 3.0 beta 5.

I updated the External Entities Drupal.org submodule to demonstrate how this works.

Just enable external_entities_drupalorg and go to the route for an issue:
/drupalorg-rest-issue/3536965

You should see the Title, Body, and Status for this issue.

Switching from NestedArray:mergeDeep() to mergeDeepArray() with $preserve_integer_keys = TRUE seems to work.

This will need testing to see if the change breaks anything.
NestedArray:mergeDeep() is still used in many places and may need further review.

I'm able to map the integers to text for a text field.
Also able to map integers to taxonomy ids for term reference field.

Still can't create new taxonomy terms from the mapped text (#2), but that can be a different issue.

https://www.drupal.org/project/drupal/issues/2115245 →
....?

This call to mergeDeep() is clobbering the array keys:
https://git.drupalcode.org/project/external_entities/-/blob/3.0.x/src/Da...

I switched to a text field to simplify, but still having trouble. Looks like importing numeric keys from config doesn't work around it.

I'm able to bypass the config form by editing the yaml file and importing.

Now mapping the key to value is working, however only for IDs for existing terms.

It's not able to create new terms from text, even though the field allows it.

I tried using the automatic detection plugin, hoping that would convert it if needed. Maybe that's where the logic should go for an entity lookup, or should it be another plugin? I'll make another ticket for it, but still hashing out how things work in this one.

mortona2k → created an issue.

I was wondering why composer was installing a joomla package, and traced it to this issue. (not hating, just curious)

Looks like that's being used to determine similar terms?

Here's what I got when I ran it on a site:

I tried a merge, the UX is pretty good, but it should redirect back to the list. Currently just shows a blank merge page.

Using other logic to determine similar terms would be great, like when you have terms that are often applied together.

Can anyone shine some light on how/why external entities are bypassing those hooks?

Do we need some way to determine what to do in different scenarios? IE if an API call for data with an ID returns nothing, do we assume it's deleted, or something else?

That's it.

There is also the Menu Block module, which extends the SystemMenuBlock plugin and adds extra functionality. Not saying these features should not be in core, just pointing out the convention that's been around for a while.

I like the idea of setting a "don't expand menu item" property on the menu link item, and allowing overriding in the block settings. However, there currently is no UI for adjusting settings for individual menu links within the block config. Would it just be for all links?

Presumably the use case for this is when you have a main menu that you want some items to expand, but others will be shown differently, like a sidebar menu that renders the links that are hidden from the main menu. Alternatively, you could just make another menu.

I encountered this debate on where to configure complex menu settings before. When using Menu Item Extras to make a mega menu, we add fields to menu items and configure the display of the top level links to be a dropdown panel with content and the sublinks.

My UX/DX complaint with this is that making adjustments is clunky. To change content on a panel, you would edit the menu, then edit the menu link, then click the layout tab. Changing any menu display settings has to happen in the block config.

What I would prefer is a way to jump from the front end straight to an interface where I can adjust all aspects of the menu structure and display.

The disconnect is that we adjust the menu hierarchy in the menu settings, but the display of that hierarchy is split between the menu link checkbox and the menu block config.

What if the menu did not dictate display settings at all, and that's handled entirely in the block display? This gets tricky. If a menu link is added or removed, the block config has to get updated to account for it.

One in-between approach is to use a custom block with layout builder to create the menu. If there is a layout section for the menu container, the menu links and sub trees could be blocks placed in the layout, with additional settings on each one. We can't adjust the menu structure or create/delete links from within layout builder, but it would expose a ton of display options at different levels. For example, one top level link could be configured to display 2 levels, and another could display 5.

Sorry for the long rant, I've been thinking about this for a while.

@ressa that would be fantastic, with the option to proceed and delete the view if I don't need it anymore.

Highlighting the part that will break is a huge step forward.

I was also considering disabling, but adding it as a note to the view config, ie disabled_reason: Content type article does not exist.

And also, if this is going to be considered "works as designed", then the feature request (as mentioned above) is to add a menu setting that determines if selected menu options appear expanded.

Agree the resolution here should be to clarify the setting.

It's a bit tricky since people will see the menu item option separately from the menu block configuration.

Can you clarify your suggestion? I'm not sure where you're saying it should go.

Would it be an option to never expand the item, even if in the active trail?

Unchecking "Show item as expanded" does not prevent it from expanding. It just means that it's not expanded by default. Clicking on the menu item or it's active trail will still expand it.

People are confusing this as a toggle for enabling/disabling expanding, when it is actually a toggle for whether or not to display when you're not in the active trail.

It says that when checked it will always expand. It does not say that it will never expand when not checked.

If selected and this menu link has children, the menu will always appear expanded. This option may be overridden for the entire menu tree when placing a menu block.

Good to know this one is working. I recently did a deep dive on these kinds of views aggregation and calculation features.

This looks similar to Views Aggregator Plus, but that one can only do single row aggregation results.

One pattern I am seeing is that the data is too tightly coupled with the display. I haven't looked at this module's code yet, but for example, Views Aggregator Plus handles the calculations in the display plugin. I would like to instead have views plugins that do the calculations and then provide variables that could be used in any display template. This is a tricky problem from a UX/DX perspective since views is quite complex under the hood. I also pondered what it would be like to integrate views with a library that can handle this on the front end, but it seems like a full stack solution is the best way to go, especially when handling pagers with dynamic sorts/filters.

Here's a collection of modules, issues, and notes related to the effort: https://contrib.drupalarchitect.info/task/advanced-views-calculations

I was attempting to build a financial/accounting dashboard, where these kinds of summaries would be nice.

Hey sorry that wasn't it. Composer files in modules aren't strictly necessary unless you need a specific version or extra dependency.

The issue is in the info file dependencies, drupal core modules should be prefixed with "drupal" instead of the module name:

dependencies:
- drupal:layout_builder
- drupal:block_content

If I delete my Article content type, I'd want to delete my Articles view.

If I have a Search view with multiple content types, and delete one, I'd like it to be removed from the filter.

If I uninstall a module that provided a view display... revert to safe default? Ask me to disable? Ask me what to change to?

I am dreaming of some kind of config quick fix UI where you get some kind of dialog for making necessary adjustments. I thought that's what #2575547 (formalize patterns) was about.

Disabling the view is ok, but sometimes they are recoverable, and sometimes they can't be edited without breaking, and take some dev hacks to fix.

Is this related? https://www.drupal.org/project/drupal/issues/2575547 →

Assuming "patterns" refers to the patterns we encounter when modifying config, and defining a UI to support the decisions to be made.

mortona2k → created an issue.

mortona2k → created an issue.

mortona2k → created an issue.

mortona2k → created an issue.

Having random machine names in views is quite annoying for developers. I think this should be fixed in core.

I think it should be included just under the setting for administrative labels. That is in a collapsed element, so to me this increases functionality without adding clutter.

I want this for fields as well, where you can have duplicate fields that just have _1 _2 at the end, with no way to differentiate semantically.

This is still happening in the 2.x version.

Please create a release for the 2.x branch so we can create merge requests for it.

Can this module be replaced with a menu and icon api?

There are plenty of open source icons on iconify, so Iconify Icons and UI Icons modules will set you up.

Splitting the ticket into the UX issue vs the "Term" label issue.

mortona2k → created an issue.

This is working for me on a Drupal 10.5.1 site with UI Icons Backport.

Drupal 10 support was removed from iconify_icons_provider in: https://git.drupalcode.org/project/iconify_icons/-/commit/eca5c1f4b6b1a9...

There is no mention of why it was removed in the issue: https://www.drupal.org/project/iconify_icons/issues/3495277 📌 Add a link to Iconify Icons Provider configuration in Allowed icon packs settings from UI Icons Field module Active

Seems like it was removed by mistake?

The type declarations were added in https://git.drupalcode.org/project/vite/-/commit/56f50a4067536e8b756e1a2...

Here's a patch made by reverting the commit, which includes some additional changes in test files.

I agree with @vegardjo's proposal. This seems like a good time to investigate whether this can be rolled into the main module.

I had to save the node display form after creating a content type, or else the default display mode is not available for selection.

For the clone displays tab, both the default display and form mode need to be saved, or else they don't appear.

I don't see another issue for this.

Field formatter settings look a little broken too:

I cannot get the separator field to appear.

mortona2k → created an issue.

I'm having a much better experience with Tagify, which I see has become the default widget for entity reference fields in Drupal CMS: https://www.drupal.org/node/3513534 → .

I have been happy with Config Devel for updating install/optional config in my custom modules.

You list the config you want to export in the module's info file, under config_devel: install/optional, and then run drush cde (config devel export). That will export your site's config that is listed into the module's config directory.

This issue is for allowing Config Devel to export to recipes: https://www.drupal.org/project/config_devel/issues/3472623 ✨ Allow writing configuration to recipe's config directory Active

mortona2k → created an issue.

The setting appears on the views display config form as a Table Tools checkbox, under Widgets & Elements.

The tabletools code is in the 1.9.3 zip file linked on the project page, but not the 1.10.x version that gets downloaded with composer by datatables/datatables in the 2.x branch.

Fixes the warning.

The datatables/datatables package is the jquery plugin, distributed on packagist.

This puts it into the vendor directory, which is why the readme says to copy it into /libraries.

It also says to use mnsami/composer-custom-directory-installer to automate that setup.

Buy why use this instead of a more common method like composer merge plugin, or providing instructions to set up the repo in your composer.json so that it installs in /libraries instead of /vendor?

This corrects the spelling of viewed, from "viewd".

Any interest in integrating with UI Styles?

+1 for media support.

Here's a start for the orientation and year filter.

With ajax enabled in the view, the date picker pops open again after the refresh.

I tried to use autoclose: true, but it gets reopened. I'm wondering if using once would prevent this from happening.

mortona2k → created an issue.

I find composer.libraries files to be the most reliable and best DX.

Sometimes asset packagist is out of date, or has weird names/differences between npm and bower.

I just ran into an issue with fontawesome. While waiting for a patch to composer.libraries.json to get accepted, I can just copy the repository definition into my root composer.json.

Can you please also create a 2.x branch for further development?

mortona2k → created an issue.

The problem is that the Drupal.org packaging script info is in the actual repo file (should only be added when installed by composer).

https://git.drupalcode.org/project/edit_media_modal/-/blob/2.x/edit_medi...

That needs to be removed separately, it's conflicting with this MR.

Here is a patch that doesn't have that change.

v17.4 just came out.

Referenced stripe compatibility issue in Give module.

Ha, now this has leapt ahead of other stripe modules and still can't be installed.

drupal/commerce_stripe 2.0.1 requires stripe/stripe-php (^15)
drupal/stripe 2.0.1 requires stripe/stripe-php (^7 || ^8 || ^9 || ^10 || ^11 || ^12 || ^13 || ^14 || ^15 || ^16)

Are you able to allow multiple versions, or does that cause compatibility issues in the code?