mortona2k → created an issue.
I added steps to create a view that triggers the error and is fixed with this patch.
mortona2k → created an issue.
Starterkit already has a dialog library that extends core/drupal.dialog, so I was able to just add the js in there for my theme without the library info hook.
https://git.drupalcode.org/project/drupal/-/blob/11.x/core/themes/starte...
I ran into this error, but replacing my site config with the default media library view fixed it.
I had changed the view display to use responsive grid.
But that display doesn't support row classes, relating to https://www.drupal.org/project/drupal/issues/2474491 →
I made a custom display that extends responsive grid to add custom classes back in, and it's working again.
Switching to select2 makes sense, and the patch looks good to me.
Works for me. Thanks!
Drupal's copy of jQuery UI Dialog is modified.
This line says it converts percentage to pixels: https://git.drupalcode.org/project/drupal/-/blob/11.x/core/misc/dialog/d...
Nice find @james.williams, I think your analysis is correct.
Seems like it happens when the height of the dialog exceeds the height of the screen. On a fresh install my first media upload didn't trigger it, but opening it a second time with a media item in the library causes the scrolling.
Here's an old post where someone claims a dummy link worked: https://forum.jquery.com/portal/en/community/topic/default-scroll-positi...
I've been trying some related things but they're not quite working.
I also tried https://www.drupal.org/project/dialog_native →
Doesn't seem to have this problem, but the default styles need adjustment.
Tested on a fresh d10 site:
[error] TypeError: Drupal\Core\Plugin\Discovery\AnnotatedClassDiscovery::__construct(): Argument #2 ($root_namespaces) must be of type Traversable, null given, called in /var/www/html/web/core/lib/Drupal/Core/Plugin/DefaultPluginManager.php on line 313 in Drupal\Core\Plugin\Discovery\AnnotatedClassDiscovery->__construct() (line 56 of /var/www/html/web/core/lib/Drupal/Core/Plugin/Discovery/AnnotatedClassDiscovery.php) #0 /var/www/html/web/core/lib/Drupal/Core/Plugin/DefaultPluginManager.php(313): Drupal\Core\Plugin\Discovery\AnnotatedClassDiscovery->__construct()
#1 /var/www/html/web/core/lib/Drupal/Core/Plugin/DefaultPluginManager.php(337): Drupal\Core\Plugin\DefaultPluginManager->getDiscovery()
#2 /var/www/html/web/core/lib/Drupal/Core/Plugin/DefaultPluginManager.php(213): Drupal\Core\Plugin\DefaultPluginManager->findDefinitions()
#3 /var/www/html/vendor/chi-teck/drupal-code-generator/src/Command/PhpStormMeta/Plugins.php(41): Drupal\Core\Plugin\DefaultPluginManager->getDefinitions()
#4 /var/www/html/vendor/chi-teck/drupal-code-generator/src/Command/PhpStormMeta/PhpStormMeta.php(73): DrupalCodeGenerator\Command\PhpStormMeta\Plugins->__invoke()
#5 /var/www/html/vendor/chi-teck/drupal-code-generator/src/Command/BaseGenerator.php(115): DrupalCodeGenerator\Command\PhpStormMeta\PhpStormMeta->generate()
#6 /var/www/html/vendor/symfony/console/Command/Command.php(326): DrupalCodeGenerator\Command\BaseGenerator->execute()
#7 /var/www/html/vendor/symfony/console/Application.php(1078): Symfony\Component\Console\Command\Command->run()
#8 /var/www/html/vendor/symfony/console/Application.php(324): Symfony\Component\Console\Application->doRunCommand()
#9 /var/www/html/vendor/symfony/console/Application.php(175): Symfony\Component\Console\Application->doRun()
#10 /var/www/html/vendor/drush/drush/src/Commands/generate/GenerateCommands.php(105): Symfony\Component\Console\Application->run()
#11 [internal function]: Drush\Commands\generate\GenerateCommands->generate()
#12 /var/www/html/vendor/consolidation/annotated-command/src/CommandProcessor.php(276): call_user_func_array()
#13 /var/www/html/vendor/consolidation/annotated-command/src/CommandProcessor.php(212): Consolidation\AnnotatedCommand\CommandProcessor->runCommandCallback()
#14 /var/www/html/vendor/consolidation/annotated-command/src/CommandProcessor.php(175): Consolidation\AnnotatedCommand\CommandProcessor->validateRunAndAlter()
#15 /var/www/html/vendor/consolidation/annotated-command/src/AnnotatedCommand.php(387): Consolidation\AnnotatedCommand\CommandProcessor->process()
#16 /var/www/html/vendor/symfony/console/Command/Command.php(326): Consolidation\AnnotatedCommand\AnnotatedCommand->execute()
#17 /var/www/html/vendor/symfony/console/Application.php(1096): Symfony\Component\Console\Command\Command->run()
#18 /var/www/html/vendor/symfony/console/Application.php(324): Symfony\Component\Console\Application->doRunCommand()
#19 /var/www/html/vendor/symfony/console/Application.php(175): Symfony\Component\Console\Application->doRun()
#20 /var/www/html/vendor/drush/drush/src/Runtime/Runtime.php(110): Symfony\Component\Console\Application->run()
#21 /var/www/html/vendor/drush/drush/src/Runtime/Runtime.php(40): Drush\Runtime\Runtime->doRun()
#22 /var/www/html/vendor/drush/drush/drush.php(139): Drush\Runtime\Runtime->run()
#23 /var/www/html/vendor/drush/drush/drush(4): require('...')
#24 /var/www/html/vendor/bin/drush(119): include('...')
#25 {main}. This is a UX issue. I'm still hopeful that something can be improved.
I did not know that you could modify the body or another field and then click save, that is working for me.
Is it possible to put an alert on the preview page when you click back?
Is it possible to check on the entity form if you've used the browser navigation to get here (I've never looked into this). There might be some indicator we could check.
mortona2k → created an issue.
My first instinct was to agree with @ressa.
CRM = Customer Relationship Manager. This is a well established term, like CMS.
However, CiviCRM refers to itself as a "Constituent Management System".
We could argue that semantically, "Contacts" is inclusive of "Customers", and so it is an expansion of the concept.
Although this only changes the intended purpose, not necessarily the feature set. A full suite of standard CRM tools would work for customers, constituents, and contacts.
Good thing those all start with C!
(I asked GPT for clarification/ideas: https://chatgpt.com/share/681a1f4d-bea4-8011-a184-9865b72e7b78)
That says it's ok to bend the C, and also suggested Community Relationship Platform.
The patch is now quite different than the line it applies to, and I think it's no longer relevant.
https://git.drupalcode.org/project/formtips/-/blob/8.x-1.x/js/formtips.j...
var $descriptions = $('.form-item .description,.form-item__description,.form-item .filter-guidelines,.fieldset__description')
.not(selectors)
.not('.formtips-processed');
However, I am still having some issues. I'm getting a formtips wrapping vertical tabs, and my fix above disables all tips, not just on fields inside the vertical tabs.
This patch was needed for the continuous scroll formatter to work without errors.
After setting up the repository in my root composer.json and requiring mozilla/pdf.js, the module is working for me.
Any reason not to merge what we've got? It should be set up to load the library automatically, right?
Having the module define the asset repo as a package in composer.json and requiring it should work.
If not, the instructions to set up composer.json are working fine and could just be pasted into a README.
@geoffreyr - use the composer why command (see the example above).
Or try why-not <package> <version>.
Hello, I suggested looking into this from the related ticket.
I'm interested in improving the site documentation experience, to make things easier for clients and developers as projects grow over time.
I've used both these modules a little so far.
Module Usage Documentation is great for taking notes on why I installed a module and how it's in use. This knowledge is very valuable years later, for example, when I need to know whether it's ok to disable for the sake of a D11 upgrade, or if I should wait for compatibility.
The tricky part is remembering to use it! I think some UI improvements could surface more info and encourage developers to fill it out.
I used Content Model Documentation as a tool for analyzing site structure during upgrades or extension projects. I'd like to start using it from the start of projects to document things from the ground up. It seems like there is a lot here that could help out a lot, but again more UI improvements are needed to smooth out the experience.
One quick opportunity for the combination of these modules is that the CMSD module report loads very quickly compared to the full extension page, so it would be easier to edit CMD info there.
Thanks!
mortona2k → created an issue.
+1 for this.
Currently, you have to navigate to Structure > CM Documents, select a field and add the documentation.
Then the field documentation appears in the content type documentation tab.
Would be great if it was a little easier to edit, and displayed in more places like the manage fields/display tabs on the content type.
Here's what it looks like with documentation created for one of the fields on Page:
mortona2k → created an issue.
mortona2k → created an issue.
Not OP, but I was looking into this recently.
Here is what I got for module dependencies on phpoffice/phpspreadsheet.
Notice views_data_export says conflicts < 1.23.0. This actually means it conflicts with versions under 1.23.0, so anything over that is allowed.
$ ddev composer why phpoffice/phpspreadsheet
drupal/complete_webform_exporter 1.0.4 requires phpoffice/phpspreadsheet (^1.1 || ^2.1)
drupal/feeds_xlsx 1.0.1 requires phpoffice/phpspreadsheet (^2.0)
drupal/permission_spreadsheet 2.1.1 requires phpoffice/phpspreadsheet (^1 || ^2 || ^3)
drupal/phpexcel 4.0.2 requires phpoffice/phpspreadsheet (^1 || ^2)
drupal/trucie 1.2.0 requires phpoffice/phpspreadsheet (^2.0)
drupal/vbo_export 4.x-dev requires phpoffice/phpspreadsheet (^2.2)
drupal/views_data_export 1.5.0 conflicts phpoffice/phpspreadsheet (<1.23.0)
drupal/views_data_export_phpspreadsheet 2.0.6 requires phpoffice/phpspreadsheet (^1 || ^2 || ^3)
mortona2k → created an issue.
mortona2k → created an issue.
mortona2k → created an issue.
Looks like Media Bulk Upload can be used without Dropzone, but this issue 📌 Make Dropzone fully optional Active says the dependency is still there.
mortona2k → created an issue.
mortona2k → created an issue.
Rebased the patch on 2.x.
It's great to see the eager collaboration.
Seems like Schema Form is becoming the contrib area for #3477363 ✨ Add a way to automatically generate basic config forms Active . I'll check it out soon.
Linking to related issues.
I see what you mean. However, if I was displaying the page title as an H1 in a separate hero block, I would disable the title block on that page entirely, so only one h1 exists in the html.
There's different ways to set up a page with a hero, but many of them are going to cause a disconnect between where you see the exclude node title checkbox, and where else the title can be displayed (which will take some manual config anyway).
There could be a situation where the hero is a display mode of the current page, placed as a block in a page region. What does the exclude node title option do in this case?
The two step option to choose between hiding and visually hiding could work, but I'm not sure if it covers all the ways we'd want to manage this.
@smustgrave, can you clarify what you mean?
I think in most cases, the title block is the single H1 on the page, and this is a viable solution for that case. But I'm not sure how to handle any others.
I thought about making a separate module for this, since the use case is so specific (although I think it's by far the most common).
Looks like the tests are passing, and the only change is for the version #.
Can you test the patch manually, and set the issue to Reviewed and Tested by the Community if it works?
mortona2k → created an issue.
mortona2k → created an issue.
mortona2k → created an issue.
mortona2k → changed the visibility of the branch 3301623-add-olivero-like-primary_10.4.x to hidden.
mortona2k → made their first commit to this issue’s fork.
mortona2k → made their first commit to this issue’s fork.
mortona2k → created an issue.
I pushed an updated experiment, using drawer in the page template.
Going back to having page-drawer.html.twig, which needs to be copied over page.html.twig to try this out.
If you put everything in drawer content, the height will be consistent. when sidebar is open/close.
https://play.tailwindcss.com/iXQCFV126E?size=610x428If there are header, footer, etc outside of drawer, you need to adjust the sidebar height manually (sidebar has not awareness of the height of elements outside of drawer, like header and footer)
https://play.tailwindcss.com/yBd78ekM7s?size=610x428
Sounds like it can work both ways, but could take some effort to get it working.
Removing v5 prefix from daisyui.com, it no longer redirects.
I think we would need to be able to run an extra service alongside drupal.
Getting a POC that works in DDEV would be cool.
Here's a contrib module to show/hide the whole toolbar: https://www.drupal.org/project/admin_toolbar_toggle → .
Maybe the Paragraphs Report → module has some inspiration.
I think this will be easier, since fences aren't content they aren't hidden in the database. We should be able to export site config and grep for uses of fences if needed. A UI for this would be nice.
mortona2k → created an issue.
The base theme compiles because it has no css, but the demo themes are broken until unocss issues are resolved.
Create new branch for tailwind 4.
Having trouble with colors.
Error: [vite] Internal server error: [postcss] Selector is expected
mortona2k → created an issue.
Does this consider themes with SDC? Templates that reference components as THEME:COMPONENT need the theme part updated.
Added CSS for --drupal-displace-offset-top.
I misunderstood how the component worked, no adjustments to the page template are needed. Only the button needs to be in the content slot.
Added a navbar drawer story to demo.
TODO: we need a class for the admin toolbar top margin.
Also need a way to manage additional utility classes, but I guess that should be UI Styles? Or additional props, IE selecting a background color for the drawer.
mortona2k → changed the visibility of the branch 3518682-incorect-depencency-nodenode to hidden.
Let's close this, I was just confused about how things worked.
The macro can be replaced with an SDC.
menu.html.twig would include system:menu component, which can include itself and pass item.below as items, just like the macro is doing.
Themers can set up different menu components for main/secondary/sidebar styles.
Added a navigation dropdown story.
How should we handle default styles that are not component props?
IE the dropdown example has: bg-base-100 rounded-box z-1 w-52 p-2 shadow-sm
background color, border style and shadow are styles, z-index, width, and padding are more layout, and z-index is pretty critical to get right within drupal's layouts.
Related ticket for adjusting navbar so dropdowns can be inline.
mortona2k → created an issue.
There are different dropdown methods, which have various quirks. For example, details/summary won't close automatically without additional js.
The issue fork has code for operating with css focus, which seems to handle interactions.
There is also a property to enable hovering.
Menu component has a dropdown option, which is a similar style, but needs js if not using details/summary.
https://daisyui.com/components/menu/#collapsible-submenu-that-works-with...
Configuration form for UI Patterns block:
mortona2k → made their first commit to this issue’s fork.
MenuSource is where the links are being loaded by MenuLinkTree->getMenuItems().
That's where I adjusted the parameters being passed in.
This is just like the default system menu block:
https://git.drupalcode.org/project/drupal/-/blob/11.x/core/modules/syste...
I recall finding out that active links are not the same as active menu trail. The active tab/local task is a good example of where .is-active is used. But I think active menu trail classes are generated by the menu tree, and don't need the js for anonymous users.
That makes more sense.
Linking another core issue.
I think there should be a more robust way to manage the vertical tabs, like on the manage display form. That would resolve a lot of related problems.
Linking a core issue.
mortona2k → created an issue.
mortona2k → made their first commit to this issue’s fork.
This is a duplicate of the related issue.
Looks like the composer.json file was added in that one, but it was never closed.
I posted a fix there to try.
Looks like there's some activity again on a 3.x branch.
The problem with composer install is that the elementor package name is incorrect - it should be elementor/elementor.
To get around this before the fix is committed, add this to your composer.json:
"repositories": [
{
"type":"package",
"package": {
"name": "elementor/elementor",
"version": "3.29.0",
"source": {
"url": "https://github.com/elementor/elementor.git",
"type": "git",
"reference": "main"
}
}
}
]
mortona2k → made their first commit to this issue’s fork.
Looks like I had a hand in this a while back: https://www.drupal.org/project/simplify/issues/3207027#comment-14243065 ✨ Hide last saved and author (meta) Fixed
Try testing in Stark, there are some differences in other themes. But both should be working.
Here in Claro, advanced and meta vertical tab groups are changed to container elements. Revision information is moved into the meta group.
https://git.drupalcode.org/project/drupal/-/blob/11.x/core/themes/claro/...
It was not totally clear using this module that the fields would get a visually-hidden class. That's something to consider whether there are other implications, like users being able to change things manually.
In the last push, I made some adjustments that seem to work in stark and claro. I don't know why this mix of type = hidden and class = visually-hidden are needed, but using one or the other did not work. I set path to be the same way.
Is it better to use access = false like path had?
I see it working for the Revision field, but not for the Status metadata or Menu settings.
This is in my custom theme, however this is working in Claro, like the screenshots above.
I do see the wrapper being rendered, as @dom. mentioned.
Doing it in SystemMenuBlock makes sense to me, that's where the "Expand all menu links" checkbox is. An additional checkbox for "Don't auto-expand items in the active menu trail"?
mortona2k → created an issue.
mortona2k → created an issue.
They read as duplicates to me, both are talking about confusion over the option and how it affects hardcoded behavior.
I was recently diving into how menus load, and learned about using MenuLinkTree service to load the menu. At first I was trying to stuff extra content into the items with a custom modifier for MenuLinkTree->transform(). But then I discovered that those are more for controlling the structure of the menu, like removing links you don't have access to, or changing the order. But loading additional content is intended to be in a preprocess.
I took notes on things I discovered here: https://www.drupalarchitect.info/articles/rendering-menus
I think the question is where we should make the decision on how menus render. If everything is available, the decision can be made in the template. If the child links are removed further back in the render pipeline, they take deeper development to modify. For example, adding a custom handler to adjust the link loading takes way more effort than deciding not to print level 3 items in a template file.
That said, I think default menu templates should be able to handle whatever links are passed in, and the UI should give us clear control over what is happening per menu display.
mortona2k → created an issue.
Linking to related Menu Block issue.
Adding related issue.
Some experimental config:
https://git.drupalcode.org/project/unocss_starter/-/blob/0.2.x/demo/unoc...
Some final updates to CORS settings.
Menu Item Extras adds a lot of extra suggestions, including region:
https://git.drupalcode.org/project/menu_item_extras/-/blob/3.1.x/menu_it...
The option in Menu Block to override the theme hook doesn't working with MIE because the hooks are out of order.
I've seen a handful of issues around theme hook ordering, including some in core. Here is one for MIE:
https://www.drupal.org/project/menu_item_extras/issues/3449110 🐛 Rendering wrong template after updating from 2.x to 3.x Active
I'm not sure how/where the order of these suggestions should be reconciled.
Linking to a similar issue in Menu Item Extras.
That one is asking for a contextual link for each menu item, whereas this one is for editing the menu itself.
Ideally there is support for both. But a custom source plugin may be needed to handle MIE that extends one by UIP.
Add to documentation:
The drawer component needs to be called with the drawer_id prop.
A button component with the same drawer_id prop is used to open it.
lg:drawer-open class is used to force it open on large screens.
lg:hidden hides the toggle button.
Still need to handle the margin top for admin toolbar.
Working proof of concept.
I removed the grid for the sidebar that was there, but intend to put it back. However another option is to use the drawer sizing instead.
There's some work to do to get menus, position, and padding working correctly.
To try this, copy the page--drawer template to page.html.twig.
The drawer is forced open on desktop with lg:drawer-open on the drawer wrapper element.