Fixed.
I did test this and it does work as long you are on Drupal 11.
Fixed!
Complete
@michaellander I have finished the code for this but not tested it fully.
Marking this as related to a core issue where supported types are hard coded currently.
I wonder if instead of a select it could be an autocomplete entity reference field.
In addition to @parkerc #7 solution. If you see TermForm.php around line 37 it seems to be known that this could be the case. There is a comment there:
// \Drupal\taxonomy\TermStorageInterface::loadTree() and
// \Drupal\taxonomy\TermStorageInterface::loadParents() may contain large
// numbers of items so we check for taxonomy.settings:override_selector
// before loading the full vocabulary. Contrib modules can then intercept
// before hook_form_alter to provide scalable alternatives.
you can manually change the override_selector setting in taxonomy.settings.yml as well instead of a form alter.
The code indicates not loading the full entity for each term.
So this issue could maybe be considered not a core issue and more of a problem to solve with a module since the use case is potentially unique to have a monstrous amount of terms.
thoughts?
@tanc I have revised the lookup to include the whole module or theme. Unsure how performant that is looking in the whole directory so someone chime in about the efficiency of that. We could optionally pass one more arg in the twig function to designate what directory to look in with the default being /components.
I have this same type of issue where I have a term id or multiple term id's and one of my setups comes back with ['1071\t'] nothing I do in the ui will remove it. This change does solve it for me tho. @ian.ssu can you set a merge request on that change you made?
I added a small twig extension. Probably be nice to harden validation. I think this will be very helpful in creating stories!
Here is something I am curious what others are doing.
Backstory, I was originally passing most things as properties to an include when @Pierre (pdureau) pointed out it would be better to use slots for most things and prevent prop drilling of sorts. I think this is a great idea and I am on the path to solving it and wrapping my head around it completely and refactoring as we go. Here is what I am coming across:
Property context may get contaminated when not using ONLY or with_context:false.
When using ONLY or with_context: TRUE I am blocked from passing a content.field_item to a embed block.
// block--component.html.twig
{% embed 'theme:my-component' with {option} %}
{% block slot_1 %}
{{ content.field_item.0 }} // when ONLY is used I can't do this if not then contamination happens.
{% endblock %}
{% endembed %}
What is everyone doing in this situation?
Here is what I thought of as a workaround for the time being maybe
// block--my-component.html.twig
{% embed 'theme:my-component' with {
option,
_content: content // create a namespace that shouldn't collide only in files inside the template dir //(drupal templates not sdcs)
} only %} // add only back
{% block slot_1 %}
{{ content.field_item.0 }} // when ONLY is used I can't do this if not then contamination happens.
{% endblock %}
{% endembed %}
Here is another thing I am wanting a solve for but it doesn't fall inside the scope of this ticket so sorry about that:
When I have the render of an embed slot area twig calls for this type of syntax to wrap it with html. The thing is i want the the dom to render conditionally which obviously i can check if the block is empty or not but seems like we could create a new embed area called something that handles that use case for more concise conditional block areas. Of course i can use regular twig and or css to make sure that space don't have a height or render but I am curious if we should solve it.
<div class="desc">
{% block description %}
{{ description }}
{% endblock %}
</div>
Try out the patch i created just removing a comma in the manager constructor. @SirClickalot
I have encountered this issue in tandem with https://www.drupal.org/project/drupal/issues/3464719 🐛 Twig embed leads to recursion and InvalidComponentException Needs review . If the only keyword is forced that would be good but we gotta make sure blocks from embed still get passed down and not blocked. Let me know if I need to post an example. I find myself needing to pass down a block for an embed to a nested embed block basically. Maybe thats bad practice. let me know. Cheers.
I created a branch off of the automatic updates called: https://git.drupalcode.org/issue/components-3428529/-/tree/3428529-upgra...
WIth the dev branch on 10.3, php 8.3, Upgrade status is happy and site runs.
brayn7 → changed the visibility of the branch 3428529- to hidden.
brayn7 → created an issue.
@ashooner, I have a themes/custom/
/source/ I have this here bundled with my global styles, js and other assets. This is just subjective but how i would like to structure my theme and not have to have another folder i "theme" in for components. So in that i have a dir 02-components. I symlink that directory to "components" and, its been awhile now, but I was running storybook from the 02-components directory and thats where I wanted to generate the json file as well. Maybe I don't need to do that tho. If you have a suggestion im all ears. Sorry for the late reply.
I tested this on php8.3, D10.3, Looking in Upgrade Status it removes the warnings. I created templates and could place them.
This doesn't apply for me with drupal 10.2. Additionally, and I should probably create a ticket for it, but removing a facet selection via the summary just resets all the filters because it is just a link to the view page im currently on. In ViewsExposedFilters.php there is a comment "We don't build real urls here. Views will handle this part for us." But thats not happening. Could be a conflict with ajax maybe idk.
brayn7 → made their first commit to this issue’s fork.
Added a module to handle this and other extras we may want to add.
brayn7 → changed the visibility of the branch 3443303-add-storybook to hidden.
@bander2 You have to patch the vendor dependency too.
"e0ipso/twig-storybook": {
"Feature allow global server url": "https://github.com/e0ipso/twig-storybook/pull/11.patch"
}
This works great for me.
brayn7 → changed the visibility of the branch 3305640-add-block-restriction to active.
brayn7 → changed the visibility of the branch 3305640-add-block-restriction to hidden.
Advagg does not work with > 10.1
Going to mark this fixed in terms of the schema is fixed but not using slots yet to be more flexible. That is tracked in the related issue.
Not sure if we need this anymore when we are doing less preprocessing after switching to using slots more.
Fixed in the slots over props work.
Do not need this with slots over props work.
brayn7 → changed the visibility of the branch 3432798-slots-over-props to hidden.
@pdureau taking into consideration your comments. Thank you for that. I feel that it could end up being a new ticket that revolves around making our base components more flexible and use slots but this would be more of a change than just schema. So TBD.
Need to add in the readme that points out the new breakpoints.js file.
I made some more changes. I think we should have a different issue for considering things to be slots rather than props for things mentioned like accodion-item, ctas and the like. I wouldn't mind being pointed in the direction of some examples and articles to see what best practice is for those items. The current mindset is that we want to be super defined about what is accepted in certain places like ctas where we don't necessarily want just anything passed there. That being said @pdureau we are open to learning and changing our mindset.