This is good to go!
Perhaps this could be done with an inbound path processor?
mlncn → created an issue.
Wow, thank you! I guess i forgot to implement this more straightforward option entirely.
Merged this in, hope more people can review the branch and will make a release soon.
Uh, in case i forget, @jacobupal are you interested in being a co-maintainer?
Thanks!
mlncn → created an issue.
mlncn → created an issue.
Have this for two columns now! (which is all we have so far, #3480393 )
mlncn → created an issue.
mlncn → created an issue. See original summary → .
mlncn → created an issue.
With PHP 8.3.12 i am getting:
Error: Undefined constant "MENU_CALLBACK" in /var/www/html/web/modules/contrib/drupalmoduleupgrader/src/Routing/HookMenu.php(73) : eval()'d code on line 24 #0 [internal function]: ark_menu()
#1 /var/www/html/web/modules/contrib/drupalmoduleupgrader/src/Routing/HookMenu.php(87): call_user_func()
#2 /var/www/html/web/modules/contrib/drupalmoduleupgrader/src/Plugin/DMU/Converter/Routing.php(70): Drupal\drupalmoduleupgrader\Routing\HookMenu->getSourceRoutes()
#3 /var/www/html/web/modules/contrib/drupalmoduleupgrader/src/Commands/DrupalmoduleupgraderCommands.php(188): Drupal\drupalmoduleupgrader\Plugin\DMU\Converter\Routing->convert()
#4 [internal function]: Drupal\drupalmoduleupgrader\Commands\DrupalmoduleupgraderCommands->upgrade()
#5 /var/www/html/vendor/consolidation/annotated-command/src/CommandProcessor.php(276): call_user_func_array()
#6 /var/www/html/vendor/consolidation/annotated-command/src/CommandProcessor.php(212): Consolidation\AnnotatedCommand\CommandProcessor->runCommandCallback()
#7 /var/www/html/vendor/consolidation/annotated-command/src/CommandProcessor.php(175): Consolidation\AnnotatedCommand\CommandProcessor->validateRunAndAlter()
#8 /var/www/html/vendor/consolidation/annotated-command/src/AnnotatedCommand.php(387): Consolidation\AnnotatedCommand\CommandProcessor->process()
#9 /var/www/html/vendor/symfony/console/Command/Command.php(326): Consolidation\AnnotatedCommand\AnnotatedCommand->execute()
#10 /var/www/html/vendor/symfony/console/Application.php(1096): Symfony\Component\Console\Command\Command->run()
#11 /var/www/html/vendor/symfony/console/Application.php(324): Symfony\Component\Console\Application->doRunCommand()
#12 /var/www/html/vendor/symfony/console/Application.php(175): Symfony\Component\Console\Application->doRun()
#13 /var/www/html/vendor/drush/drush/src/Runtime/Runtime.php(110): Symfony\Component\Console\Application->run()
#14 /var/www/html/vendor/drush/drush/src/Runtime/Runtime.php(40): Drush\Runtime\Runtime->doRun()
#15 /var/www/html/vendor/drush/drush/drush.php(139): Drush\Runtime\Runtime->run()
#16 /var/www/html/vendor/drush/drush/drush(4): require('...')
#17 /var/www/html/vendor/bin/drush(119): include('...')
(And i still get the same error if i throw define('MENU_CALLBACK', 0x0); into the module i'm trying to upgrade.)
Are they visible to Search API?
Looks good, thank you!
Hmm, actually we do need a bit more of an API than #gin_action_item or the code needs to be changed to allow an explicit ['#gin_action_item'] = FALSE to override Gin's hardcoded $include (used in includes/form.theme around line 90).
Currently there is no way to move, say, the Save button into the Kebab when, say, the "Save and Edit Layout" should be primary.
The merge request in 🐛 Cannot opt out buttons using #gin_action_item = TRUE Active restores an ability for third-party code to place buttons to the emphasized area outside of the kebab menu by adding in a form alter hook:
$form['actions']['example_button']['#gin_action_item'] = TRUE;
So as things stand the resolution to this issue is for that issue to be committed and closed as fixed and then for us to document it somewhere here –
https://www.drupal.org/docs/contributed-themes/gin-admin-theme →
– and i think in gin.api.php also.
Ah fantastic fix for the Preview button i thought i was losing another bit of my mind!
Confirmed that the restore of #gin_action_item setting works also. Excellent fixes, thanks!
Code changes are simple and clear. Curious if an alter hook or other API would be a more consistent way of keeping but that is a different issue and it really it does not matter so long as it is documented: 📌 Document clearly how contrib modules and/or site builders determine which content form buttons are primary Active
Per comment #2 there is
> an API available to show the buttons outside of the kebab menu
Let's get what that API is documented in 📌 Document clearly how contrib modules and/or site builders determine which content form buttons are primary Active
Changing this to a feature request, since as covered above we can avoid this error if we can exclude custom (but content-extending) forms from Gin's enhancement of content forms.
Note that the ability to exclude by route will not help because the check for base_form_id, while mixed in with the check for routes, is independent and if it returns true the enhancements get applied.
Also, even where restricting by route can work, the route as in the example is for all entities of a type, so for all nodes, not by content type, so in many cases definitely too broad.
Allowing the $form_ids_to_ignore variable to be modified by third-parties (the same way routes already can be, in the same method) seems a very straightforward improvement.
Merge request forthcoming.
Ah but excluding the form means the buttons do not show up at all.
Seems that the modifying/placing and the removing should be handled in one spot.
The reason this is getting applied when it is not expected is because the base form is a node form and so the condition $form_state->getBuildInfo()['base_form_id'] ?? NULL) === 'node_form' (line 375 of src/GinContentFormHelper.php) is evaluating to true.
The reason we cannot opt out of it is because the $form_ids_to_ignore (line 335 of src/GinContentFormHelper.php) is hard-coded, with no alter hook.
Given this is a pretty custom one-off case i'm not sure we should look more into automatically ensuring this does not apply when it might break things, but it seems that might be possible (check for edit_actions somewhere)?
mlncn → created an issue.
Wanted to note that there is no mention of this primary / secondary (kebab menu) distinction in gin.api.php, and while it may be a different sort of thing than a classic API that's still a good place to document or point to other documentation.
Also i can see that $form['actions']['submit']['#button_type'] = 'primary' but changing this value and setting other actions to primary does not affect anything Gin does.
Now that themes can declare dependencies on modules → , could we make a tiny, low-weighted module that Gin depends on that sets 'primary' to the actions that Gin thinks should be outside the kebab 'other actions' menu? Then regular-weight modules could further form alter this easily.
mlncn → created an issue.
johnpicozzi → credited mlncn → .
No one has said there's anything specific wrong with this code, and it solves the problem. Setting back to needs review for the bots to confirm it applies, but if this does i still say it's RTBC.
Was evaluating building on this module and seeing all the issues reviewed and worked on by anybody and knowing their work in Drupal elsewhere, strong endorsement.
Do note that enabling "Override the field template for all themes" at /admin/config/user-interface/fences/settings also works.
Probably we could basically adopt the template, bringing in all the <{{ field_tag|default('div') }}> style HTML element replacements.
OK that question still stands, as far as best practices for contrib themes to play well with Fences, but the big green box on the module page that links to this issue really needs to be updated to say that one can go to /admin/config/user-interface/fences/settings and enable Override the field template for all themes!
This issue seems to persist for the Bulma theme: 🐛 Bulma's field.html.twig overrides and is incompatible with Fences module's Active
Is there anything themes should do or refrain from doing to be compatible with Fences?
mlncn → created an issue.
mlncn → created an issue.
mlncn → created an issue.
Nothing like writing ones own Better Exposed Filter plugin -
https://www.drupal.org/project/bef_links_filter →
- to get a better sense of how this all works. Implemented a workaround in
🐛
Prevent collapsible fieldset from showing when facet is empty
Active
but the fix here should be to put the wrapping of facet into a details element on line 254 of better_exposed_filters/src/Plugin/better_exposed_filters/filter/FilterWidgetBase.php in a if (!empty($form[$field_id])) { … } block, unless that does not work for all better_exposed_filter plugins?
Accidentally referenced the BEF issue in my commit message, but here's the code: https://git.drupalcode.org/project/bef_links_filter/-/commit/500cbac2674...
This is really a BEF bug: 🐛 Collapsible details element not hidden if "Hide filter, if no options" is selected. Active
But we can implement a workaround for now.
This fix does it!
Ah thank you, i did not find that one!
Was that already merged in? Because i am getting the opposite experience, where if i select the entity but no bundles, i always get "[error] Message: The export couldn't be completed since it contains disallowed content. Please check the configuration of the Single Content Sync module, or export only allowed content."
Once i select the bundles explicitly, it works as expected.
mlncn → created an issue.
We have a module built on Extra Field Plus (and friends) - https://www.drupal.org/project/create_referencing_content → - that seems to be running into this for entity view display, not only the form as described here, with Field Group 3.x. Is there any similar special markup as described here for the widget that that needs to be part of the formatter for it to work as expected?
I'm pretty confused about this issue too… definitely needs either better documentation across the Extra Field ecosystem or if Extra Field can non-intrusively ensure pseudofields always work with Field Group module, that's ideal?
Yep that's right.
Configurable Views Filter Block shows Better Exposed Filters facets-sourced Details elements (label, no options) even when not selected in the block if that is helpful for pointing me at where to try to fix this. Thanks!
Thanks, i realized that after posting and upgraded, and it is still the case on 7.0.2 at least.
This is still an issue, at least when used with the latest Facets 3.x
- Configure facets within Views as documented in https://project.pages.drupalcode.org/facets/exposed_filters/
- In Better Exposed Filters settings on the view, under Exposed Filter Settings, open Advanced filter options and enable Make filter options collapsible ("Puts the filter options in a collapsible details element.")
- Visit the view and filter by another facet so one set to be in a Details element has no results.
- Note that the facet label is still there as the summary for the details element, but nothing is inside.
- Change the Exposed Filter Settings option to not make filter options collapsible.
- Reload the view and see that now the facet label is gone, as expected.
The version of the patch in the merge request avoids trying to update existing labels. Instead, it allows the stored labels to stay blank, and keeps exactly the same behavior as before if that is the case. Now that we have a label base field where labels can be stored, however, this module can now be used with Auto Entity Label, which i think should be the main goal of this issue.
https://www.drupal.org/project/auto_entitylabel →
There is not a need for this module to provide its own UI for altering the label pattern when Auto Entity Label exists.
With this merge request the only thing happening in the update hook is the necessary addition of the label field to the profile entity base, so there is no longer a risk of errors or timeouts when the update hook is run. Also, if people do not run the update hook right away, everything continues to work.
Yes, the patch is in the dev branch.
i really need to do a beta release of 3.x and i guess this probably needs to be backported to 1.x?
Thank you! Updated the test since the point is that link it is checking is wrong!
(Is there an easier way to see test failures than clicking six layers deep through the pipeline reports in code.drupal.org?)
Tested no-patch workaround; it's good.
mlncn → created an issue.
Hello Muhammad, hello Melissa! Thank you both for becoming maintainers— if you do plan to actively maintain, could you update the project page to reflect that? Thanks!