This may not be true
isn't a good legal term... 😂 And there doesn't need to be any explicit mentioning
Where are the sources that can be shown at court to let them know that it's totally fine?
Furthermore, there might be good other reasons for local libraries, for example if you use Drupal in an Intranet.
So, would you be fine with it, if we implemented the functionality?
Thanks. we just ran into the same issue. If the paragraphs field is empty, for some cases we'd expect to entirely hide the field (and thereby the table).
Instead the table is shown with a result saying that no entries have been found.
I'd like to suggest adding two things in the field formatter:
- Add a setting to hide the table if empty
- Add a setting to override the "Empty text" (if visible empty)
That should also target the point from #3:
whether this would break some other functionality
The setting should keep existing behaviour so that nothing breaks.
Furthermore, #3 already takes care of the AJAX mode, which is important.
@dougiep could you create a MR from your patch posted?
Small regression can be found here: 🐛 Warning: Undefined array key 0 in ParagraphsTableFormatter.php on line 474 Active
Okay looks like this isn't just the case for empty paragraphs. It seems like a logical bug, maybe regression.
In these lines:
$target_bundles = array_keys($handler["target_bundles"]);
if (!empty($handler['negate'])) {
$bundles = $this->entityTypeBundleInfo->getBundleInfo('paragraph');
$target_bundles = array_keys(array_diff_key($bundles, $handler['target_bundles']));
}
$type = key($target_bundles);
array_keys() already returns the keys as array values. So we need to get the value to get the type machine name:
$type = reset($target_bundles);
Otherwise, $type is the numeric key ($type=0) and the following lines break.
The MR fixes that, please review.
@lazzyvn I created a MR for adding the classes, maybe that would be okay for you?
@lazzyvn thanks. We still have the issue that the button is visible for user 1 - the client - who is confused and complaining.
Do you see a chance to reopen this and allow disabling the add button entirely or at least add a possibility to alter it using hook_paragraphs_table_formatter?
Or would you at least allow adding a dedicated class to the button and its wrappers so it can be cleanly hidden by CSS?
Thanks @grevil! Confirming that.
Looks great, also very informative description @maxilein thank you! I'll link it on the module page!
Instead of posting patches and MRs can we please use merge requests and only post static patches of the MR current state? Thanks!
I can confirm this issue still exists.
I'm having a similar issue, maybe the same:
Having Hide the end date field unless it's different from the start date. widget setting enabled and I create a NEW node, the node creation form only shows the start date, unless I check "All day".
If the start date is empty, the end date should always show, I think. Otherwise, it's not even possible to select a different end date.
@thomas.frobieter Additional patch is now applied! Sorry my fault!
PS: Seems like other JS Errors cause the same issue with drag & drop, so if you come here, look into your browser console - it may have a different reason with the same visible issue!
TL;DR: Dragging from disabled to active, the mouse up doesn't work. Nicely documented @thomas.frobieter.
@Grevil could you have a look?
@lrwebks: Ping!
Totally agree that this is missing in the field widgets and just found that it's missing on many of them, also for example on integer & decimal inputs, so I created a generic parent task: 🐛 Field widget "size" setting is not available across all field types Active
Maybe we should consider adding this in a base class or trait?
Entity Browser + IEF integration is a good alternative, depending on the users needs.
Entity connect has a very nice explanation on the module page that could also be added here:
If you need more flexibility, Inline Entity Form → with Entity Browser provides a powerful full-featured way to create entities within entities and browse for the entities you want to add/edit. However, setup is not trivial. See this handbook → for more information.
If you need more flexibility, <a href="https://www.drupal.org/project/inline_entity_form" rel="nofollow">Inline Entity Form</a> with <a href="https://drupal.org/project/entity_browser" rel="nofollow">Entity Browser</a> provides a powerful full-featured way to create entities within entities and browse for the entities you want to add/edit. However, setup is not trivial. See this <a href="https://www.drupal.org/docs/8/modules/entity-browser/inline-entity-form" rel="nofollow">handbook </a>for more information.
Ok thanks, I thought this was for new entities, while using entity browser for searching existing (extended filtering)
anybody → created an issue.
Thanks for the fix @lazzyvn! That was fast!!
@mdranove thanks! Could you check if
🐛
It's possible to overflow the number of allowed items with edit selection
Active
is a duplicate or should also be fixed by the MR?
Then we could push (both) things forward. Thank you!
PS: Let's switch to using a MR instead of patches! Anyone else interested in pushing this over the finish line?
This functionality would still be really fantastic and a great improvement for Drupal!
Not being forced to decide for the easy and quick autocomplete widget, if you know the label of an entity, but also having the option to alternatively use entity browser alternatively on the same widget, would be absolutely best for more complex use-cases.
On top it would be a dream to have the option to create a new or edit the referenced entity in a modal, but that's a different topic. Having all that would make things really complete and useful!
I'd rate this as bug, as the tab for setting up the auto entity label is shown, but broken.
anybody → created an issue.
Confirming RTBC and the steps in #15. Should be merged.
Thanks @larowlan!
Then I'll have a closer look, if the module can help us, thank you!!
Here we go. Please review.
I don't think we should use an update hook to change existing pages, because we can't decide, if they want it?
Works!!
@Grevil found it!
It was a part of the generic test that tests the uninstall and then reinstall. As the configs don't have an enforced dependency on ad_content_js module, the configs were never removed so on re-install the problem occurred!
See the MR for a fix!
Let's see if this fixes the issue maybe...
Alright, understandable that we don't want to undermine the module's core concepts here. But the proposed solution should still work with that, wouldn't it?
Yes, it's just a clean bugfix, that still makes sense IMHO. Not changing the module logics at all.
PS: If you think that the settings are too specific for the Bootstrap table and for that reason shouldn't be added, that's fine. But then we should at least document a way to disable them cleanly, for example setting data attributes etc.
Also we could make these additional settings dependent on the selected formatter using Form #states API!
https://www.lullabot.com/articles/form-api-states
@lazzyvn: Would be great, if you'd think about our offer for the additional setting here again. At least for admins, the permission will never do anything (because they have all permissions) and it's not untypical that you simply don't want the Add feature, so I'd really expect a setting next to the existing line acton settings.
I think it would be helpful in sbx. But of course you decide as maintainer :) We'd sponsor it with our time.
Yeah this is clearly a bug with the (newer)
Exclude the selected below
setting on the paragraphs field. Should work in both directions and use the same logic as paragraphs itself uses, from my perspective.
Still @lazzyvn is totally correct with his point. It's focused on one type, otherwise creates separate tables due to the different fields = columns. We understand the reason and that shouldn''t be changed!
@lazzyvn what's going on here?
We tried helping to improve the module for the Drupal community with helpful settings (and we'd invest the time on our sponsorship). Why don't you like that?
Did you read the issue as criticism? It's just a feature request?
(Still it's fair for you as maintainer to decide, but that really looks sad)
We've had a similar issue in the past, maybe we can learn:
🐛
Configuration objects (cookies.cookies_service.analytics) provided by posthog_cookies already exist in active configuration
Active
PS: My implementation is untested, so please review and try carefully!
@lrwebks it's not that hard as you think, please review and test manually by time.
Guess it's a great chance to learn how it works (and be less in fear then for the future :))
@lrwebks thinks it's too heavy for him :)
PS: Maybe the "minimum" functionality is still more interesting than the "Unlimited" support and more in the focus of this module regarding UX.
Thank you very much for the quick response @marcoscano. Totally fine as your maintainer decision, I just wanted to propose that idea :)
anybody → created an issue.
anybody → created an issue.
https://www.drupal.org/project/edit_media_modal → might give us examples how to implement the modal!
anybody → created an issue.
anybody → created an issue.
@amaria still any plans? You're still (self-)assigned.
Yeah this would make a lot of sense!
We could try it simply this way: https://mark.ie/blog/very-basic-example-of-editing-drupal-nodes-in-a-modal/
Or take a look at similar modules and how they solve it!
I guess the most problematic part will be to only close the modal, if the entity was saved successfully (without errors) or we have to accept imperfect UX.
@Maintainer: D11 is out for long now, could we have a new tagged release, please? Thank you :)
I think #23 still is valid:
I think it still needs work to maybe address browser validation, or deal with field with default values being added.
Best would be to have tests for such cases to ensure it works as expected. Logically I think we're not that far from the finish line...
@dgilbert could you maybe incorporate your path into the MR on 3.x for push things forward here cleanly?
We shouldn't use patches anymore...
I believe this is still a very relevant issue for 3.x
Possible workaround: Don't use "Unlimited" (where possible) and this module and instead set a fixed limit for the field values plus https://www.drupal.org/project/sam → (if it works with paragraphs ... )
anybody → created an issue.
anybody → created an issue.
https://www.drupal.org/project/entity_sanitizer → might also be helpful. Still there doesn't seem to be a Drupal 8+ solution yet?
anybody → created an issue.
@anruether definitely yes! I'm also absolutely not against making this editable - the point is just about complexity, because we either have to set the option per bundle or ensure the field exists in the enabled bundles.
I also don't like the hard-coded body field that much, but it's at least a simple >80% solution. What about maybe introducing the setting in config first and do the UI later? Anyone interested to implement that?
Thanks @lazzyvn so if Bootstrap CDN is no option and Gin is used, would you suggest forking this module or fixing https://www.drupal.org/project/entityreference_modal_create → then?
Where would you suggest to start from, with your experience? We need the functionality, but can't use Bootstrap or CDN in the admin theme.
Thank you!!