-
Notifications
You must be signed in to change notification settings - Fork 642
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature/entries with category features #11749
Feature/entries with category features #11749
Conversation
…er::inputHtml to ElementsController::inputHtml. extract field element listings to their own twig files.
…guage from base relational field
I'm also considering adding a migration script, maybe some thing like |
Thanks @myleshyson! Will review ASAP |
…e/entries-with-category-features
Did you mean this? npm run build # run the "build" package script To see a list of supported npm commands, run: npm help
@myleshyson Finally getting around to reviewing this – could you resolve the conflict in No need to worry about the other conflicts. |
@timkelty alright fixed that conflict. not sure what that bit of code removing hidden input names addresses, but I added it for structured elements as well so there's parody. |
Ah ok so that was to address this #11789, which should now be addressed for structured elements as well after I resolved the merge conflict. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@myleshyson One aspect that is currently broken is when you have multiple section sources selected.
I think the best approach would be enforce that relateAncestors
is only possible when a single structure source is selected. On the settings page, that option would only display when that condition was met.
Similarly, I think the branchLimit
option only becomes available under those same conditions.
Since they do pretty different things, I would say keep them separate, but when |
I think where you have it makes sense.
Yep, that's the right approach. Keep it in place but include an
Nope, you nailed it! |
Great work, @myleshyson! |
Awesome thanks! I'll address these either tonight or tomorrow morning. |
…t relational fields. Update logic in BaseRelational field to clear limits depending on whether relatAncestors is checked or not. some minor cleanup
@myleshyson could you also fix the ECS and PHPstan errors? |
@myleshyson "Relate Ancestors" currently remains enabled when selecting a non-structure channel. It should only enabled when a single structure source is selected, right? Should probably also remain disabled if nothing is checked |
We should think about this scenario:
With the current implementation, when you load the entry, the single entry will be related, and the relations are not filled in on save. The ancestor selection is only enforced on selection. I'm thinking we should enforce the setting on save as well, to support this scenario. |
I need to think some on how to implement. Right now the only thing passed are source keys to the twig template. If I instead pass the source arrays from within |
Sounds good. If you'd rather focus on the other issue, we can shop around approaches for this too. |
@myleshyson hey there! Just checking in where you are with the remaining things and what you still plan on working on. Asking because we're planning the coming 4.3 release, and I wanted to see if we should try and fit this in. |
Hey @timkelty. The goal was to work on it over the weekend but a lot of stuff came up this weekend unfortunately. The plan is to work on this between today and tomorrow. |
@timkelty alright updated the branch. Instructions are disabled out. There's a validator for sources now when relateAncestors is checked. I'm forcing the relateAncestors setting on element save now. Only downside is that |
Hell of a job, @myleshyson! I'm going to change the target of this to my PR, merge it, so I can add changelog, etc – then I'll recommend it for 4.3 🥳 We will likely work on a CLI command to migrate an existing category to section – let me know if you have any thoughts/ideas there. One note: |
This is now merged for Craft 4.4 🚀 The setting has been renamed to “Maintain hierarchy”, and it’s now hidden whenever a non-structured source is selected. |
Craft 4.4 is out with that change! |
Description
This is a continuation of the work @timkelty started. Since the logic for the categories field already works so well, my goal here was to take the existing ancestor logic from
CategoryInput
andcraft\fields\Categories
and merge it intoBaseElementSelectInput
andcraft\fields\BaseRelationField
.As a result of this, the categories field no longer needs its own
CategorySelectInput.js
module, since theBaseElementSelectInput.js
module covers everything structure related.There are some things I'm unsure about, namely being:
craft\controllers\CategoriesController::actionInputHtml
tocraft\controllers\ElementsController::inputHtml
. Was torn between this and moving it tocraft\controllers\StructuresController::actionInputHtml
since this really is structure specific. However the StructuresController has a required elementId param for all requests currently which doesn't make sense for this specific route. What do ya'll think?npm run build
before opening this but let me know if there's more I should do!Would love feedback on this! All in all this pull request is more moving pre-existing code around than adding anything new.
Related issues
#9781
Initial Pull Request: #11088