Thanks for the feedback! It's a tough section to improve given the complexity but happy to hear its at least better.
In the widget settings, every field now has an option for the new "Hidden" widget type. Likewise, in the formatter settings for each field there is also a "Hidden" formatter type.
Thanks! I also updated the description and dependencies as well as the README.md to be consistent with project page.
apmsooner → made their first commit to this issue’s fork.
I will say that the decimal field is really the only one thats exceptionally taller with the extra fields and its probably not particularly common to have anymore than 1 row of fields in most cases. I could be okay with calling it good as is if you're cool with it. I'd like to put out another release tomorrow hopefully since there are several other fixed issues. Hopefully you'll have time.
Thanks
@ressa,
Maybe you can test out this patch with several fields of type decimal for example that would end up with multiple rows. If you feel strongly that this is still a better solution with columns, I can go with it. I'm just a little cautious I guess with not wanting to make it more complex than it already is... but if you still think its an improvement than let me know.
I removed the red danger class and changed the wrapper to a details that defaults to closed when there's data in the field (ie; its locked from editing). The idea being that once the field is locked, it doesn't provide any value really to see whats in the wrappers. Problem i still have though is this columns layout and long form for some field types. I don't think this really works well and I can't really make this work too well with the fields all inline as the variances in field types and layout of the remove button just doesn't work that well IMO. I'm leaning towards really just putting this back into rows but keeping the details element so at least it provides some clear separation and has a closed state by default when there is existing data so it will only look busy on initial setup. Later I could see if I could manipulate the ajax further to always have them closed but each one open as its in focus similar to how the widget settings works. Here is screenshot of the current state that I don't really love for example with decimal types:
The patch needs to be started over against the 3.1x branch. Alot has changed since and I havn't had a chance to revisit this. If not this next release, the one after I should get to it.
apmsooner → created an issue.
Merging this simple feature addition. If there are any issues, create a separate ticket.
This should be good to go if you wanna add review.
The patch should do what you need for now. I'll probably have some broken tests that may need fixing but otherwise it should just work.
Hey there, the rendering already supports a 'hidden' formatter option for all types. We can create also a 'hidden' type widget that could apply to all field types. Is that what you want so you can set the value via javascript or do you want a 'value' type widget in which you are setting via backend? I suppose we could have a single widget that could determine the element type of either hidden|value. Let me know what you think. Its a pretty simple task that I should be able to knock out pretty quickly.
I'm really not loving the columns. Set a sub-field type to 'decimal'. Theres more settings and makes the column really long and undesirable IMO. I just really don't think this is the best solution. I'd prefer to revert back to rows (although keep the other changes). I think the ideal solution would be to figure out a way to not have to submit the full form on ajax requests and preserve the state where we could have these fields in a details that open based on current item being worked on. This would be similar to how the widget settings work.
Thanks for the patch. Merged!
apmsooner → made their first commit to this issue’s fork.
Here's some more styling options with button classes to make them standout. This is a screenshot of gin theme. Feedback appreciated.
We could move the "Add another" button above the storage fields like screenshot. Maybe rename it to "Add field" or "Add column"? Thoughts on the machine name title? Is "Column name" intuitive or suggest something else?
The ordering of elements follows the same order as other fields. You can edit any other field type and see the same order. There's really only so much i can do with manipulating that anyway as there are multiple form sections that are merged into 1. Storage settings is a completely different subform from field settings (where the widgets are). So, I'm afraid its probably gonna have to stay as is for consistency.
You can test out the patch. For now, i just hardcoded a style using css grid. The ordering of elements is controlled by core. I didn't touch any of that yet as I really don't want to deter too much from default core behavior but play around with whats in there for now. I did also change the machine name field title to be more descriptive of its purpose and shortened the description to take less space in column layout.
Let me revisit and test out some of these suggestions and see if I can talk myself into them. At the very minimum i think we can strip away the outer fieldset and wrap the storage fields in fieldsets to provide some separation between them but I'll try the columns suggestion as well and will see if it can make better sense. Thanks
From my perspective, if you are not using it for multiple values, you're using it wrong. Sort of like the saying "if all you have is a hammer, everything looks like a nail".
I need to have a clearer module description perhaps because the impression you got here is completely wrong. I will soon be posting some videos that explain the Drupal field api in detail with how data is stored and you will then understand that this module is not just for multi-valued fields. It's essentially a correction to how content is commonly modeled in Drupal that leads to huge performance problems and database bloat.
Reworked the output. See if this works for you.
Closing this as I don't believe it makes sense to integrate Tagify with this module but feel free to comment back if you have any additional questions and I'll help as best as possible. Thanks
Assuming you've already been following this guide: https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... → , you probably want to extend the EntityReferenceAutocompleteWidget.php file.
I'm not familiar with the Tagify module, it looks pretty cool however I'm not sure it would be so useful as a custom_field widget considering these subfields are only ever going to allow a single value.
You might notice that the widget settings are in sync with the storage settings. When you tab out of the machine name field assuming you changed the value, you'll notice the widget settings get updated also with that new name as the machine name of storage is essentially the key for the field settings. Similarly when you change the field type in storage, the corresponding available widget types and settings get replaced. Perhaps moving storage settings back into its own configuration management page would be the best option but there would have to be alot of logic rework to make that happen and I'm a 1 man show maintaining this module. Hopefully it gets more popular and some other developers will consider contributing help :)
- The order already matches what you're requesting
- I don't want to set "Allowed number of values" to unlimited because I disagree that is what the user always wants and the default core behavior for fields is limit of 1. I have several use cases myself where a single item custom field makes sense to store like fields together in a single row.
- The machine name issue is addressed here: https://www.drupal.org/project/custom_field/issues/3515457 📌 Hide machine-name-suffix field Active
- I'm not crazy about turning the storage settings into columns. I for instance have a nutrition field with over 20 subfields and horizontal scrolling would have to happen in that case which would get really messy particularly when adding a new field. I was considering wrapping each one in a collapsible details element but the problem is after adding a field, I would want to set the open state for that new field and when core decided to merge storage and field settings into a single form, it's required me to trigger a click to the save button to make all this work together and update the default values settings and therefore I can't persist any temp values for setting the focus. For now, there's just not a whole lot better options. BTW, thats the same reason theres a default value programmatically set for the machine name. Ajax is REALLY hard to manipulate basically and Drupal's form structure here is a little less than ideal after they merged everything.
- I've also set the size to machine name field to 20 in this ticket: The machine name issue is addressed here: https://www.drupal.org/project/custom_field/issues/3515457 📌 Hide machine-name-suffix field Active
I appreciate the suggestions and please keep them coming. I know the storage settings form can seem a little overwhelming and perhaps we can continue to improve but considering its a one time setup really, I'd like to spend more time at least for now on new widgets and such.
@ressa,
I've removed the javascript aspect from this machine name type field as its just not really working right particularly with the dynamic parts of this form. This just always exposes the name field for all of them and eliminates the empty suffix that was causing unwanted space. Try the patch please and add a review.
Thanks!
I think its ultimately because these new elements are being added via ajax though and the javascript for the machine name field is not acting right perhaps after the ajax trigger. I will look deeper into this when i get a chance to see if i can figure out where its getting lost as I agree with you that the presentation is not desirable and consistent.
It shouldn't be hidden, it should be fixed in core. The suffix is what contains the label and edit button in place of the input field. The javascript appears to faulty on that core element which is causing an empty suffix.
This machine name suffix is a core thing i guess and I do believe there's a bug in core with multiple machine name fields in the same form. I think we could track down a core issue for this and fix it there, then it should get reflected here. Thats why the first field acts like a typical machine name field and the subsequent fields look different. I assume theres some javascript involved in core that needs some attention.
I don't think thats the issue cause the loop was just going over the settings which is configuration but anyhow its fixed and merged. Thanks!
Its a mystery to me how to get to the error but the patch should at least fix it if you can try out and report back please.
What kind of entity is this field attached to or is it being used in layout builder or something?
I am honestly not able to reproduce this. It shouldn't even get to that point if $items is empty. Assuming this is a multi-valued field, it seems like one of your items is for some reason not being considered empty. Is it just a: string, uri, and string_long subfield structure?
Ahh, thanks for the report. I need to check for the setting before comparison of value in:
$is_hidden = $settings['fields'][$name]['format_type'] === 'hidden' ?? FALSE;
Thats an easy fix. I'll have a patch up shortly.
Thank you for the resilience as I see exactly what you mean now and would indeed consider this a bug. I will work on a solution to fix this indeed!
It actually is behaving the exact same as table in that regard. The <li> is being output just like the <tr> in the sense that its wrapping the subfield which can technically have a wrapper around the entire subfield, around the value and label but all of these wrappers can be changed or removed in the 'styles' section of the individual subfield formatter settings. I think with the ability to manipulate the subfield wrappers, theres alot of flexibility to minimize html. I also think the use cases for this 'Html list' and the 'Inline' formatter types are probably not common and would defer to the 'Default' formatter as the general preference. We can document these as well to steer users based on example use cases.
Oh good to hear! Thanks so much for the encouragement and suggestions.
Some good suggestions here. I'll keep this task open and work on it. I do plan to create a video series on youtube that I will reference as well which will cover these topics and various use case examples.
I don't think this is a bug but rather perhaps a preference. The thing is, we're using 'item_list' as the #theme function and it behaves differently depending on the theme. In Olivero, it doesn't output the wrapper <div class="item-list"> as in your example where as with Claro, it does use the wrapper. I could I suppose not use the theme function and hardcode the html into a template but then might cause issues with modules like fences that and change or remove wrappers so I'm kinda on the fence with this one to be honest with you.
Hi, is there a particular display where you are seeing this behavior? Empty fields generally will not be displayed as there is already a check that looks for value = null or empty string and would just skip over it in those cases.
apmsooner → created an issue.
This now works good with ctools blocks, layout builder, etc... so merging and calling it Fixed!
Okay, i'm also unable to produce this issue on another site now and I think what we're seeing here is from another patch at https://www.drupal.org/project/graphql_compose/issues/3507357 🐛 Cannot return null for non-nullable field for Link Field in Paragraph Active so I'll modify that patch and I'm sure that will fix this issue and will close accordingly.
Let me see. It would need to happen in the RoutesTest.php I would guess since thats where we're seeing it.
apmsooner → created an issue.
apmsooner → created an issue.
@mrconnerton, I created a documentation page. Can you review this and improve if needed?
https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... →
Oh wow, thats awesome news! Yes, if you would create a new page there, that would be perfect and appreciated!
apmsooner → created an issue.
You could essentially have a valid name & url but null width/height which would cause issues with the schema expected. I stand by the PR as is.
@klausi,
I added the fallback because the values could technically be null if the image is invalid. Thinking with migrations and such, there could be bad images and the graphql_compose module expects a nonNull value in its schema. I mean theres nothing preventing anyone from setting the value for width/height to null so I felt it was better to have a safe fallback.
https://git.drupalcode.org/project/graphql_compose/-/blob/2.4.x/modules/...
Ahh, yeah theres no main property on custom fields. Relationships are supported in views if you can go that route. The dot notation stuff on referenced entities I guess is specific for entity references at the field level. So you would otherwise probably have to go with the database api select query.
I don't know for sure but try this:
field_custom.reference__entity.field_number
the custom field name with __entity appended (double underscore) is a computed property.
Thanks for the encouragement and happy the module is found useful! Good interim idea for your own custom widget. The documentation is here for doing that: https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... →
I honestly havn't used layout_paragraphs and therefore didn't have a chance to test this scenario. I will try to find time to test it and reproduce the issue but it also looks like theres a good number of issues with their module with at least a few related to media so really hard to say where the issue lives. I do know that in normal paragraphs, the media library widget has been working as expected. Layout paragraphs must be doing something a little differently perhaps.
I've never used twig_tweak but from the cheat sheet listed on the module page, it looks to be pretty specifically coded for the common fields in core and doesn't look to support custom fields with properties unknown to its own api. You might ask in their channel but I don't really know how I could help you for this module. Generally speaking, theres a ton of formatters that come with this module with some advanced display settings like being able to modify field wrappers and add classes so not really sure how much value twig_tweak would provide beyond that.
I can't merge this with renderRoot solution. The cache doesn't get invalidated. Clone your custom field to a node type and you'll see that a referenced entity when changed does not change the rendered result on the custom field. I'm gonna push a new release but will have to leave this on hold for now as I just can't reproduce the issue and I don't feel comfortable with the caching issue resulting from swapping out renderRoot for render.
I also just tested placing the block in a block layout (theme region) and not using layout builder. I have no issues with rendering as is with the patch. Not getting those errors and not having to convert to renderRoot. What version of Drupal core are you on? I'm on 10.4.3 locally. I can only assume you must have something considerably different going on than me with your configuration and I don't know of anyone else having this issue. I was previously getting similar errors when in layout builder but just moving the render up to the base formatter of the field resolved that. I assume also this is just a custom field directly on the block right? No paragraphs or other weirdness in the mix?
Thanks @benstallings,
If anyone finds any further issues with this, please open a new ticket but I think we are good to go so merging :)
@ultrabob, Something to note here is that with renderRoot and I assume also renderInIsolation, the cache tags don't get invalidated so if you had changed the referenced entity's title for instance, you likely didn't see that change reflected on the parent entity. Now, with the changes, you should see proper behavior. I was able to reproduce a similar error you were receiving prior to the change which was happening on updating the block in layout builder. I don't ever use layout builder so didn't catch this problem. I do think the updated patch should resolve your issues though and encompasses all the formatters that were using the renderer method.
renderRoot isn't working cause cache isn't getting invalidated so I moved the render call up the field BaseFormatter and it seems to be working fine with this revision both in layout builder and in normal entity context. Please test the revised patch and see if that works for you.
Filters, arguments and sort all available in the patch. Please test and add a review.
Thanks for the encouragement! I've tried to promote the module in slack and various other places to increase usage but I guess alot of devs like to do things their own way or just don't understand the value proposition.
I ran this through Grok to get suggestions and explain the impact of the suggested change. It suggested instead using renderRoot(). I need verification that the following would work and test out in both cases for working in layout builder while preserving cache invalidation in other contexts.
Your concern is valid: the difference between render() and renderInIsolation() (or similar methods) in Drupal’s rendering system can indeed affect how caching behaves, especially when moving from a node context to a Layout Builder block context. Let’s analyze the issue, explain why the error occurs, assess the caching implications, and propose a solution that balances functionality and performance.
The Problem
Normal Node Context: Your formatValue() method works fine because nodes are typically rendered as part of a full page render pipeline, where the renderer (RendererInterface) can process the render array ($build) and integrate it into the page’s cacheable metadata (e.g., cache tags, contexts, etc.).
Layout Builder Block Context: When this field is rendered inside a block used in Layout Builder, the rendering process happens in a more isolated or nested context. Layout Builder often renders components individually, and the renderer may expect the output to be "isolated" (e.g., not relying on the full page’s render pipeline). The error suggesting renderInIsolation() likely stems from this isolation requirement—Drupal’s renderer might detect that $this->renderer->render($build) is being called in a way that doesn’t properly handle nested rendering or placeholder replacement.
render() vs. renderInIsolation()
render():
Processes the render array, applies #pre_render callbacks, resolves placeholders, and integrates cache metadata into the current render context.
Relies on being part of a broader render pipeline (e.g., a page or a parent element) to finalize output and caching.
If called in an isolated context (like Layout Builder’s block rendering), it might throw an error or fail to handle nested dependencies correctly.
renderInIsolation():
Renders the element in a standalone way, bypassing some of the broader render context dependencies (e.g., placeholders or late-stage processing).
Often used for AJAX responses, previews, or isolated components where the full page context isn’t available.
Can skip certain optimizations (like placeholder replacement), potentially impacting caching.
Caching Concerns
In Node Context: Using render() ensures that the cache metadata (e.g., #cache['tags'] from the entity) is bubbled up to the page level. This means the node’s rendered output is cached efficiently, and cache invalidation works as expected (e.g., when the referenced entity changes, its cache tags invalidate the node’s cache).
With renderInIsolation(): If you switch to renderInIsolation(), the rendered output might not fully participate in the page’s cache bubbling. This could:
Prevent cache tags from being merged into the parent context (e.g., the block or page), reducing cache invalidation granularity.
Force the element to be re-rendered more often (e.g., if it’s treated as uncacheable or cached separately).
Potentially bypass Drupal’s BigPipe or lazy loading optimizations.
Your concern about caching being “negatively impacted in the first scenario” (node context) if you switch to renderInIsolation() is spot-on—moving away from render() could disrupt the seamless cache integration that works well in the node case.
Suggested Solution
To fix the Layout Builder error while preserving caching behavior in both contexts (node and block), you should:
Use renderRoot() instead of renderInIsolation(): This method is designed for rendering standalone elements while still respecting cache metadata and bubbling it up to the parent context.
Ensure cache metadata is properly attached: Explicitly add cache contexts or max-age if needed, though your current #cache['tags'] should suffice for entity-based invalidation.
Test for isolation needs: If renderRoot() doesn’t resolve the error, consider conditionally isolating the render based on the context (though this should be a last resort).
Thanks for the patch and reviews!
apmsooner → made their first commit to this issue’s fork.