Skip to content
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

Merged
merged 20 commits into from
Sep 13, 2022
Merged

Feature/entries with category features #11749

merged 20 commits into from
Sep 13, 2022

Conversation

myleshyson
Copy link
Contributor

@myleshyson myleshyson commented Aug 7, 2022

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 and craft\fields\Categories and merge it into BaseElementSelectInput and craft\fields\BaseRelationField.

As a result of this, the categories field no longer needs its own CategorySelectInput.js module, since the BaseElementSelectInput.js module covers everything structure related.

There are some things I'm unsure about, namely being:

  1. Branch limit and Limit in the base relation field settings. Branch limit effectively acts like limit for non structured elements, so not sure if limit should just be replaced with branch limit, or vice versa. For backwards compatibility sake maybe we can keep one of those settings and have it set the other on save?
  2. I moved craft\controllers\CategoriesController::actionInputHtml to craft\controllers\ElementsController::inputHtml. Was torn between this and moving it to craft\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?
  3. Kept the CategorySelectInput module in tact. Figured there might be people out there extending it. With this pull request though it's dead code.
  4. Also not sure what the protocol is for contributing to the js modules since the build fiels are included in the repo. I ran 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

@myleshyson
Copy link
Contributor Author

I'm also considering adding a migration script, maybe some thing like craft utils/migrate-categories-to-sections. If ya'll think that's a good idea I can add it to this pull request or create a new one.

@timkelty
Copy link
Contributor

timkelty commented Aug 8, 2022

Thanks @myleshyson! Will review ASAP

@timkelty timkelty self-assigned this Aug 8, 2022
@brandonkelly brandonkelly changed the base branch from develop to 4.3 August 8, 2022 14:24
@brandonkelly brandonkelly self-requested a review as a code owner August 8, 2022 14:24
Did you mean this?
    npm run build # run the "build" package script

To see a list of supported npm commands, run:
  npm help
@timkelty
Copy link
Contributor

timkelty commented Aug 22, 2022

@myleshyson Finally getting around to reviewing this – could you resolve the conflict in src/web/assets/cp/src/js/BaseElementSelectInput.js that has diverged since you originally made this?

No need to worry about the other conflicts.

@myleshyson
Copy link
Contributor Author

@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.

@myleshyson
Copy link
Contributor Author

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.

Copy link
Contributor

@timkelty timkelty left a 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.

src/fields/BaseRelationField.php Outdated Show resolved Hide resolved
src/fields/BaseRelationField.php Outdated Show resolved Hide resolved
src/fields/Categories.php Show resolved Hide resolved
@timkelty
Copy link
Contributor

Branch limit and Limit in the base relation field settings. Branch limit effectively acts like limit for non structured elements, so not sure if limit should just be replaced with branch limit, or vice versa. For backwards compatibility sake maybe we can keep one of those settings and have it set the other on save?

Since they do pretty different things, I would say keep them separate, but when branchLimit is set, we always set limit to null (and the corresponding setting for limit would disappear)

@timkelty
Copy link
Contributor

I moved craft\controllers\CategoriesController::actionInputHtml to craft\controllers\ElementsController::inputHtml. Was torn between this and moving it to craft\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?

I think where you have it makes sense.

Kept the CategorySelectInput module in tact. Figured there might be people out there extending it. With this pull request though it's dead code.

Yep, that's the right approach. Keep it in place but include an @deprecated comment.

Also not sure what the protocol is for contributing to the js modules since the build fiels are included in the repo. I ran npm run build before opening this but let me know if there's more I should do!

Nope, you nailed it!

@timkelty
Copy link
Contributor

Great work, @myleshyson!
Some remaining questions and issues in the preceding comments. Holler if you have any questions.

@myleshyson
Copy link
Contributor Author

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
@timkelty
Copy link
Contributor

timkelty commented Sep 6, 2022

@myleshyson could you also fix the ECS and PHPstan errors?

@timkelty
Copy link
Contributor

timkelty commented Sep 7, 2022

I think ideally, the instruction text is also dimmed when disabled (I realize that makes it harder, as it means using js to set a class on the parent):
CleanShot 2022-09-06 at 21 48 39@2x

@timkelty
Copy link
Contributor

timkelty commented Sep 7, 2022

@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

@timkelty
Copy link
Contributor

timkelty commented Sep 7, 2022

We should think about this scenario:

  • Existing field, w/o relateAncestors checked
  • Existing entry with a structural child selected
  • Field is edited, enabling relateAncestors

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.

@myleshyson
Copy link
Contributor Author

@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

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 getInputSources, but that would definitely be a breaking change for some people who extend the BaseRelationField class. Maybe I'll just pass an extra template variable called strucutredSources or something like that to keep things backwards compatible.

@timkelty
Copy link
Contributor

timkelty commented Sep 7, 2022

@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

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 getInputSources, but that would definitely be a breaking change for some people who extend the BaseRelationField class. Maybe I'll just pass an extra template variable called strucutredSources or something like that to keep things backwards compatible.

Sounds good. If you'd rather focus on the other issue, we can shop around approaches for this too.
I feel like it might be a good idea to start by validating this on the backend (on field settings save) so it isn't even possible, then deal with the frontend?

@timkelty
Copy link
Contributor

@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.

@myleshyson
Copy link
Contributor Author

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.

@myleshyson
Copy link
Contributor Author

@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 afterElementSave always runs if relateAncestors is checked, where before it only ran if the field value was dirty. Given the above scenario where the settings changed, not sure as of now how to get around that. Might not be a big deal though.

@timkelty
Copy link
Contributor

timkelty commented Sep 13, 2022

Hell of a job, @myleshyson!
Great work.

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:
Guessing you know this, but ideally we'd know when you checked a source that wasn't structured, we would know in JS and be able to disable the input. It looked like that would probably be overly complicated to pull off, and I think the backend validation is what's most important anyway.

@timkelty timkelty changed the base branch from 4.3 to feature/category-features-to-entries September 13, 2022 20:42
@timkelty timkelty changed the base branch from feature/category-features-to-entries to 4.3 September 13, 2022 20:42
@timkelty timkelty changed the base branch from 4.3 to feature/category-features-to-entries September 13, 2022 20:44
@timkelty timkelty merged commit 6da08a8 into craftcms:feature/category-features-to-entries Sep 13, 2022
@myleshyson myleshyson deleted the feature/entries-with-category-features branch September 13, 2022 21:07
@brandonkelly
Copy link
Member

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.

brandonkelly added a commit that referenced this pull request Feb 3, 2023
This was referenced Feb 18, 2023
@brandonkelly
Copy link
Member

Craft 4.4 is out with that change!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants