WordPress is powerful. It is hard for anyone to deny that fact. It has years of programming and thought put into it so there is no doubt that it is a solid project. Sure, criticize the code as I roll my eyes because everyone criticizes the code. Get past that point and you realize utilizing an existing platform that focuses on users might just be the right thing to do. Battle tested so to speak.
I am writing the Hacking WordPress series to help gather my thoughts on what I am learning each week in the hopes that I can assist a newcomer in the future. This first post is about using meta_query to modify WP_Query. Come on in! The water is warm… sometimes salty.
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_Checklistis 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.
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.
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.
While working with Aaron Saray I learned quite a bit about how to become a successful PHP programmer. This can be applied into other languages but I think you’ll like what I learned and what has made me a better developer since resigning from LPi.
Legacy 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.
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.
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.
Earlier last week I launched TrailStatus.io. 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.
I recently took a couple weeks vacation without access to cell service or the Internet. It was a good experience and something that I had no hesitation doing. My job depends on having an Internet connection but not my thoughts!
I wanted to share with something Aaron Saray taught me. When you need to solve a complex problem start flowcharting or writing it down. The solution eventually bubbled up before me as Aaron promised.
The only down fall to paper programming is no syntax checking or dependency injection in this iteration. 😛