Radio Buttons With Taxonomies in WordPress

Build a Custom Walker for Radio Buttons With Taxonomies

Stephen Harris did a great tutorial in 2012 with a radio button and taxonomies. I found it a bit complicated for what I was trying to accomplish for the WP Event Calendar Plugin.

I was trying to simply replace the drop down list with radio buttons in meta boxes. The user can select a radio button and be on their way. This cannot be that hard! After doing my due diligence I found an object I could extend: Walker_Category_Checklist.  Walker_Category_Checklist is used to create hierarchical taxonomies in WordPress. I can leverage that to output radio inputs instead.

1. Add a Walker Class and Functions

The walker extends core, changes the input type to radio, and value to the name of the taxonomy. See line 44. The rest is a copy of the core walker functionality.

2. Change Drop Downs Based on Our Taxonomy

Line 61 assists us with wiring the plugin. wp_event_calendar_taxonomy_args() searches for the taxonomy we want radio inputs on and applies the post_categories_meta_box callback. This is necessary so we can pass in our walker in the next step.

3. Getting the Radio Buttons Working With Taxonomies

Line 79, wp_event_calendar_checklist_args(), does a final check that we are the correct taxonomy. It applies our custom walker and we call this with our hooks for the plugin like so:


WordPress has a lot of core classes and functions that can be extended. I found this one by digging through the documentation and feeling uneasy about reinventing the wheel. That’s what led me to Stephen’s article in the first place.

This still allows us to add new terms for the metabox and just extends WordPress’s walker functionality. You can see the full pull request for the WP Event Calendar on GitHub.


Choosing the Right Tool

Ian Baker

At work we get into discussions regarding the best tool for the job. It doesn’t necessarily have to be about programming. These are all good conversations to have, but there is a point where you have to make a decision and it might not be the best decision.

I am beginning to get to a point in my career where it doesn’t matter too much about the language we pick or which cloud service we use. It matters more to me that we are delivering on the customer’s needs and fulfilling our promises.

If you’re anything like me, when I started development, you will start looking at a few things. What is the best programming language? How quickly can I get something done? Do I need to learn Java to understand programming?

I’d encourage you to instead think about the problem. What do you need to solve for your customer? Don’t worry about the database or the code yet. What specific problem are we solving? Are you going to need real-world sensors to communicate with the customer’s manufacturing facility? Do you need to solve an inventory control issue? Do you need to publish product to an online store? Think about the problem first.

Once you have thought about the problem I encourage you to flowchart out what the solution is. It helps sort out the problem for your own sake and is an easy document to give to coworkers to validate an aspect of the problem. Have you notice we didn’t talk about which tool is the best tool to use yet? The only thing discussed was the problem at hand. I didn’t ask you to think about how the data is supposed to be stored, what language to use, what framework, etc, and honestly, it does not matter.

How to pick the right programming language?

Pick what you feel is natural and what you find accomplishes your personal goals. I originally chose PHP early on because it allowed me to create websites that could interact with a database and be dynamic. I continued using PHP until it was no longer capable of a customer’s demand: counting plastic pulleys rolling down a ramp.

For counting the plastic pulleys I chose an Arduino and learned the basics of C and eventually meandered over to Python. When Liturgical Publications had me evaluating the recent mobile application they purchased I made the choice to learn Angular and become more comfortable with Javascript.

I picked the language that I thought was best suited for the job at the time. You need to pick the one that is right for the job instead of debating over the perceived fallacies.

What Would Dad Do?

I am not sure why but I always imagine what my Dad would do. What tool would he use? He would definitely participate in the conversation or debate over a proper tool. In the end, Dad would not care what tool was used, he would only care that the job was done properly. I want to conclude with one of WordPress’s philosophies that highlights this point and am also curious what you think about this matter.

“Many end users of WordPress are non-technically minded. They don’t know what AJAX is, nor do they care about which version of PHP they are using. The average WordPress user simply wants to be able to write without problems or interruption. These are the users that we design the software for as they are ultimately the ones who are going to spend the most time using it for what it was built for.”

Your PHP Strengths and Weaknesses with Upwork

I have been freelancing more and more to test my strengths and identify my weaknesses.  I’ve found that the biggest challenge is to hold of on refactoring everything.  I find myself reminding myself to focus on the task at hand.  It is really, really hard.

For example, a recent client had a job posted with a budget of $15 and I need to increase my reputation so I can get decent jobs there.  The job posting was:

Change output from DOMPDF to 300dpi

“Wow, that is in the dompdf config file!” I said stupidly to myself.

Continue reading “Your PHP Strengths and Weaknesses with Upwork”

The future of contracting

I’ve owned my own business and have worked at development shops before.  I understand the challenges in running a business and understand the “daily grind” involved with working for a company.

The challenges involved with owning my own business has a lot to do with managing the things that I don’t particularly prefer to do: taxes, sales, following up with clients to collect, etc.  The daily grind occasionally becomes to slow to evolve and change with the fast paced development speed I prefer.

Continue reading “The future of contracting”

How to Separate Concerns with Legacy PHP Apps and Composer

logo-composer-transparent3Legacy PHP applications get a bad reputation.  They are constantly ridiculed for being hard to work on, lots of repetition, no unit testing, etc.  There is a straight-forward way to approach code when you come across it.  I’ll show you how you can start separating classes using Composer in this entry.

Continue reading “How to Separate Concerns with Legacy PHP Apps and Composer”

Open Cart 2.0 Invoice to PDF Extension


It has been a while since I lived in the OpenCart and ecommerce world.  I enjoyed developing and understanding the different aspects of each company I’ve worked with.  I would love to get back into that realm some day.  Here is my small contribution from 2012 to the Open Cart community to allow for invoices to be printed as PDFs.  The extension version for OpenCart 1.5.x (Invoice to PDF 1.21) has over 18,000 downloads! That makes me happy that my contribution was worth checking out.

Today I am releasing an OpenCart 2.x compatible version: Invoice to PDF 2.0.  Be sure to checkout the official release and support thread for more information.

Using Silex to Refactor a Legacy PHP Application

We have a legacy application here where I work, MRS.  In my last post I talked about putting in place a front controller as the next logical step.  I started to take a different, more thoughtful, approach after discussing with my co-workers.  I used Silex.

Continue reading “Using Silex to Refactor a Legacy PHP Application”

Launch your idea early

Earlier last week I launched  I have big plans for the website.  My thoughts are to grow it to help trail curators manage news for the trails in a central location.  I have been wanting to launch TrailStatus for about two or three months now but I didn’t.

I didn’t for the same reason that customer projects or work projects linger on, scope creep.  How do can you overcome scope creep? Here are a few tips to help you launch the app early.

Stick to the essentials

Stop worrying about what your app is going to be.  It is currently a fleeting thought in your brain, get coding on the essentials that you need to make it run.  In TrailStatus’s case, this was downloading and parsing out the John Muir trail information.

Focus on what you can do within a short period of time.  Short meaning one week or less.

Get feedback often

I originally had grand plans before even starting to code TrailStatus.  I asked for feedback on the Mt. Biking subreddit and received a lot of good feedback that helped me see more future feature implementations.  If I didn’t ask for feedback I could have very well implemented a feature not needed or not used.

Write, refine, reuse your code

Don’t focus on writing the perfect code the first go.  Write the code so it is clean and concise.  After the initial release you can focus on refining your code while keeping in mind the DRY principle.  I was trying to think too far out of scope with TrailStatus.  I know that I will need to have services in the future pulling down trail information, but do I need to program it now? No.

The parting words here have been echoed before: release early, release often.