In the summer of 2012, I was visiting one of my best friends in New Orleans… cooking lots of tacos and mixing lots of margaritas. While there, one of my earliest clients contacted me and wanted to be able to sell his books for whatever the customer was willing to pay. Did I know a way to do that with WooCommerce he asked? Well no, but I’m only working on my taco recipes at the moment so maybe I can look into it?
I started to poke around and ask some questions at Github and someone else contacted me to tell me that he’d buy this right away if it existed. I took these two people as the least-scientific version of “Idea Validation” imaginable and decided to give this thing a whirl.
About a month later I had a working prototype up and for sale at WooThemes. It only worked on simple products and then with a little more effort on subscriptions. I was pretty content to leave it at that, but one request kept coming back… can this work with variable products?
For a long time the answer was no, or maybe, or I’m working on it, but mostly no. You see, I’m also a semi-professional athlete so I am not a full-time coder… and variable products are complicated! But after an extremely long “beta” process I am pumped to announce that Name Your Price 2.0 now supports variable products! You can pick and choose which variations will be Name Your Price enabled, so you can all customers to set a price on all a product’s variations or just one. This feature does require WooCommerce 2.1 or greater. Version 2.0 was a pretty major overhaul, so be careful if you were overriding any templates. There’s some documentation coming on that.
So if this was holding you back from purchasing Name Your Price, head over to Woothemes and pick up your copy!
Important: Support requests are not handled in the comments and must go through WooThemes.
This plugin has been out in the wild for some time now and it seemed appropriate to give it a post on my blog. Once upon a time I was working on a magazine site with a lot of authors and my client wanted to display all the authors in a cool way. Every other plugin I found was too rigid in its output, either markup or CSS or both. I needed to be able to customize and style this list to fit my theme. And while the original site I working on is now defunct, Simple User Listing lives on.
Once you’ve installed and activated the plugin you only have to add the shortcode to any page (or post) where you’d like to display a full list of all your blog’s users. By default the plugin will display all of the blog’s users and ‘paginate’ the list based on the “Posts per Page” setting.
I created this plugin to use templates that can be overridden and customized by theme developers. There are 4 templates in the plugin’s templates folder: content-author.php, navigation-author.php, none-author.php and search-author.php. The templates should be relatively self-explanatory and I suspect most of the customizations will happen in content-author.php which is responsible for how each user in the user loop is displayed.
To modify a template simply copy the template file from the simple-user-listing/templates folder of the plugin and paste it into a simple-user-listing folder in the root of your theme (so my-theme/simple-user-listing). Now you can change the markup any way you please and the plugin will know to use your template instead of the default.
It will be similar to template parts for post loops, except you will have access to each user’s $user object instead of the $post object. For more details on what is available in the $user object see the Codex reference on WP_User()
Simple User Listing relies on the WP_Query class and supports almost all of WP_Query’s parameters. Here’s a full list of all parameters:
Simple User Listings works with WP-Pagenavi out of the box. Simply activate WP-Pagenavi and your user lists will be paginated with numbers instead of the default previous/next links.
Search by Display Name
By default the search relies on username, but we can change this with some trickery via the pre_user_query hook. Similar to pre_get_posts this is your last chance to change the WP_User_Query query before it is executed. I’ve built in a query_id variable so that you don’t go willy-nilly filtering all user queries which could have some unintended side effects.
// Switch user search from user_login to display_name via query_where
And finally, I’ll try to walk you through setting up a custom search.
First we’ll create a new search-author.php template in our theme’s simple-user-listing folder. This template will have a pair of radio buttons that will allow the user to decide between traditional search and searching by a meta field…. in this case “city”, but it really could be whatever you want.
You don’t have to change your search template, but I thought it might be nice.
* The Template for displaying Author Search
if(!defined('ABSPATH'))exit;// Exit if accessed directly
<ahref="<?phpthe_permalink();"?>;<?php_e('Back To Author Listing');?></a?>;
Next we’ll register a query variable. This belongs in your theme’s functions.php or better still a site-specific mu-plugin, so that it isn’t tied to you theme. Remember that themes are for presentation. Plugins are for manipulating data in ways that should persist through theme changes.
Technically if you don’t change the search template you don’t need to do this either, but I’m going whole-hog here. Did someone say Bacon?
That should do it. This plugin isn’t in particularly ‘active’ development. Essentially meaning that I’m not looking to add features. However, if it breaks somewhere do let me know.
I apologize in advance but I can’t help you with your custom implementations via the comments or WordPress support forums. I am open to contract work though. Please contact me if you’d like to hire me.
Let me know where you are using my plugin. I’d love to see how you are styling it!
I found I constantly needed a way for clients to mark a post as something they wanted to feature and I’ve never found sticky posts particularly intuitive. In fact, the sticky post UI is about the least obvious thing possible for a WordPress newbie. The simplest solution was a checkbox in prominently located metabox.
So I packaged up a quick metabox, with some good quick edit support. The plugin, by itself, will not change how the posts are displayed. It just gives the UI to users and a meta key to theme developers to query for, though I am not 100% convinced that meta is the best way to go here. I have at times used a taxonomy for grouping featured posts, though this plugin is currently configured for post meta.
You can decide which post types should support this metabox directly from the plugin options. But of course, the best part of this plugin is that shortly after submitting it to the WordPress repo, I realized someone else had already built something practically identical! #Doh! Sometimes that happens, but it was a good exercise nonetheless. If you need a way to mark posts as featured, then grab it from the repo:
Over the weekend I was working on a project and my client needed to be able to hide certain menu links from non-logged in users. In the past I have just created 2 menus, one for logged in users, and another for logged out users. Not the most convenient thing ever, but simple enough. However, since this was at least the second, and possibly the third time this has come up in various projects I decided to dig further.
Adding fields to the menu item back-end
This was the trickiest part really, because there aren’t any action hooks in this part of the code. I have requested one with the following Trac Ticket, but until that gets added to we have to do it in a slightly less efficient way.
Thanks to this WordPress Answer I found that the whole menu item form is created by the Walker_Nav_Menu_Edit Walker, but that tucked away in the code is the ability to filter this and send a new Walker via the wp_edit_nav_menu_walker filter. Actually this answer got me about 80% of the way there so I can hardly claim to be clever or original. I just packaged it up. Couples with this Answer about front-end menu Walkers, the first beta draft of my plugin was born. At this point it really only handled different roles.
Before it was even added to the WordPress repository, Pippin Williamson did a quick video review, so I guess I am not the only person who has needed this ability from WordPress. Pippin also had the cool idea to add the ability to show an item to all logged-in users, or all logged-out users, so the video screenshots will look different from the end result of version 1.0. I think this was a cool addition, so thanks Pippin for the idea and for helping me work on it.
Install and activate the plugin like normal. Create a custom menu and add items to it just like you usually would. You will now see the extra fields shown in the screenshot. From here you select to show the item to all logged in users, all logged out users… or to customize by role. If you chose customize by role, then you can use the checkboxes to determine which roles should be allowed to see this particular menu item. If you choose customize by role and do not check any roles, then the item will show to everyone just like it used to. There isn’t any more to it than that. It should be pretty straight-forward.
Every now and then I run across a client who needs a taxonomy where the user is restricted to only allowing one term per post. I’ve also seen people wanting this a few times for categories, and I, myself, have wished for it a few times. Sometimes a post needs to be like a piece of paper in a folder… and only be in 1 dang folder at a time. Some might argue that categorization with a single, exclusive term is more-suited to post meta, and they might be right, but the ability to list all the existing terms is lacking from a post meta implementation.
So, the problem is checkboxes… checkboxes let users check more than one box. So, the solution is then radio buttons! Which enforce a single selection. There are a few tutorials floating around on the interwebs on how to do this.
Hands-down, the best tutorial on radio buttons with taxonomies was written by Stephen Harris, so I owe him a huge debt for providing most of the guts of my plugin. His OOP class implementation allowed you to define some variables, such as taxonomy and post type… and the class would do the rest, but only for a single taxonomy. Well the whole point of OOP-style programming is that you can re-use it! I set about building a standard plugin container with a settings page where you can check which taxonomies you’d like to convert to radio buttons. I would then create a new object based on each of these taxonomies. So I had to tweak Stephen’s class so that I could use it to create new objects (basically just switched his load method to __contruct() and pass those objects a parameter, namely the taxonomy. I scrapped the other parameters. The div id will just be standardized based on the taxonomy and the metabox will be changed for every post type that uses a particular taxonomy.
Go to Settings>Radio Buttons for Taxonomies
Check which taxonomies you’d like to convert to taxonomies and click Save Changes
Literally, that’s it. And now when you return to your edit your post you will see the new metabox. Hope you enjoy! I have a few ideas for improvements, such as better error handling when you try to add new terms and getting radio buttons in the quick edit, but this should get you started.