-
Notifications
You must be signed in to change notification settings - Fork 21
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
Add nav menu field to scf #44
base: trunk
Are you sure you want to change the base?
Conversation
haseebnawaz298
commented
Feb 28, 2025
- this is a very common field that is used a lot, and it is not in scf.
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.
This works seems to work well. A couple of questions:
- Themes without nav menus (e.g. Twenty Twenty Four) will output a notice on the post editor that the theme doesn't support it. I'm curious if there's a better way of handling it (notice on the field group editor? Disable the Nav Menu field when using a theme that doesn't support it? Hide the field on the post editor if the theme doesn't support it, etc.
- Could you walk me through how you're using this? I'd just like to understand the user journey on it. Something like "this post is about Cats, so I want to display my Animals-specific navigation menu under the top nav" with more flexibility than, say, logic by category?
I mainly want to ensure I'm understanding the need properly.
There are a couple of version updates needed (this will go in 6.5) and tweaking the docs with a typo. [I'm happy to make those edits myself before merge, so no worries there].
With the tutorial, please feel free to be more verbose. The docs, overall, are really spartan but I hope to flesh them out so someone could follow the tutorial from start to finish to add a field, use a field via the post editor, and output the field.
some of the common use case that i normally use is.
|
I would also love to help with the docs, just need a direction on how deep we want the docs to be. eg: do we need to give code examples etc, or just basic instructions? |
Awesome; are you good with making those changes on this branch before merging? (note that I did commit the suggestions I made in the initial review so please pull before new commits)
I'd say basic code examples. I'm thinking of two types of users using the docs:
For the latter person, if they said "I want to add a new field to my site" and stumbled upon SCF, will the tutorial provide them enough information to be able to add the field and output it? Until we have better integration with blocks, that's going to almost always be with small php code. So, for the nav menu, I would say it could be something like "To output this field, add this code to the theme template, functions.php or elsewhere as needed for implementation Then with a small tutorial showing "As an example, using a child theme of the Twenty Twelve default theme, if your nav menu field is "special-menu", add [code] to the such and such template.php" Does that make sense? Obviously few people would need the specific tutorial exactly as written, but enough where someone could get it work in that generic place and be enough to hopefully connect some dots for them. Additionally, I am okay with merging this (with the notice update) without the docs being 100% and accepting a follow-up PR for it. Thank you! |
i will work on this hopefully today or tomorrow, will get back to you soon |
also updated the docs to be a bit better |
- hide field in post editor if there is no support - show notice in field group editor
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.
I haven't actually tested it yet, but a couple of comments from reviewing the code.
Co-authored-by: Brandon Kraft <[email protected]>