Tips and Tricks in working with Wordpress functions
Closed this issue · 4 comments
I love the idea of this project, and like how easy it has been to get started, but I'm struggling a bit with how to use wordpress functions in a way that works well with the tailwind concept of 'classes on everything'.
I'm having to re-acquaint myself with the ways wordpress works (done more Laravel last few years), so this might be more obvious as I go through the wp docs, but it feels harder to integrate tailwind then pure css because of the wordpress way of working.
As an example: wp_nav_menu()
- I can see how to wrap the ul in a div, or add classes to the ul, but not how you add classes to the li
or a
elements. In previous themes I would just add a class to the wrapper, and then target the child li a selectors etc, but tailwind would more naturally be putting classes on those elements itself. I'm not sure if I should be looking at custom walkers, or just running with @apply
and what the roadblocks down the road would be, yet I'd assume others have solved this before!
I feel like it would be nice to have a sort of 'tips and tricks' section to showcase ways that work well to work with wordpress features like this, or things that might trip people up etc to point us in a good direction.
This could be a page in the docs of tips you've found while using, or just using githubs discussions to house discussion from all users to see how others make the tailwind & wordpress combo work.
FWIW, I use the @apply route in these cases. you may need to look at adding some classes to your safelist if they are not being included in your built css.
You can also use arbitrary variants like [&>li]:text-white
.
Arbitrary variants looks like a nice approach, I guess making tailwind work with wordpress output might be easier then trying to control the markup before it's outputted. 👍
Thanks for posting this issue @paulhennell, and thanks to @AdamChlan and @Goodosky for the great responses! I agree with everything above: A mix of @apply
and arbitrary variants will handle most or all of these cases, and it's generally easier to use those methods than to fight against WordPress's markup.
I've also turned on discussions, and I'll convert this to our inaugural discussion.
I'm not against the idea of something like an FAQ or a tip and tricks section in the documentation. I've restructured the documentation to focus specifically on getting started with _tw, and I'm waiting to see if certain kinds of questions now come up more often. (My thinking was that the documentation was getting too specific about some topics where there are a number of potential approaches.)