In this post, I want to introduce you a soon-to-be-launched productized service. It helps designers to convert their beautiful work into a fully functional but also light-weighted WordPress theme.
I know it doesn’t sound that charming, but if you are a designer who’ve ever sworn you’ll never purchase from any theme shop again, please read this up, I might have something for you.
The following snippet saved me a bunch time when dealing with a recent project. The scenario was I created 2 custom post types and they share the default “category” taxonomy with Posts. On the post type archive page, I have to display the category links so users can filter the posts.
The difficult part was I wanted to only show categories that have posts in the current post type. The following snippet came from StackExchange, with the function hook to the
terms_clauses filter, now we can use a custom argument called
post_types in the function
post_types can be an array so you can get terms like this:
get_terms( array( 'post_types' => array('post', 'cpt1', 'cpt2'), 'taxonomy' => 'category' ) );
get_terms( array( 'post_types' => 'cpt1', 'taxonomy' => 'category' ) );
Please go to StackExchange to upvote the answer if you find it helpful to you too.
When working with Gravity Forms, to get your post data updated at the front end, it can’t happen without this great plugin: Gravity Forms: Post Updates.
While it’s really awesome (and free) but like every (free) plugin in the wild, there is always one or two (…or three) things just can’t work as we expected.
The problem I met is, when updating the post, the post tags and some custom fields kept got wiped out. Because the post tags field was not added to the form and I hide those custom fields conditionally, I thought they got wiped out just for they didn’t exist in the form.
But soon I found the custom fields were in the form but got hidden with inline CSS “display:none” (added by Gravity Forms). Then I went back to the source code, realised the Post Update plugin deletes meta values if you check the “Unique Custom Field?” box in the field settings. By unchecking this box, my data is safe now.
As to the post tags, I had to add it to the form and applied a CSS class “
gform_hidden” to get it hidden. (If I just set it to “Admin Only”, it still got wiped out after form submission.)
So lessons learned here:
- When using conditional logic for “custom fields” and would like to work with the Post Update plugin, DO NOT check the “Unique Custom Field?” box or you’ll lose the data while user who can’t see these fields update the form.
- Even if you just let admins to apply post tags at the post editing screen, the post tags field has to be added to the forms. You must hide it with the CSS class “
gform_hidden“, set it visible to “Admin Only” won’t work, it would still get wiped out.
With the following snippet you can change arguments for the built-in taxonomies in WordPress:
To modify arguments for the built-in taxonomies might not be a good idea unless you really know what you’re doing. I’m doing this because (not sure since when) now WordPress won’t let me display links from the
link_category taxonomy (remember Links Manager?) on its own template page (
One symptom I’ve noticed is that when I visited the link_category term page (like visiting http://SITE.COM/?link_category=links), it showed the index page template but not 404 page, which meant such route did exist just the data couldn’t be shown public.
After some time-wasting trial and error I realized it’s the default arguments keep the template from working. And the snippet above did the trick perfectly.
Hope it could save someone thirty or so minutes someday in the future. 😉