When you’re developing, the solution to your problem might already exist. Many problems in code aren’t new, whether in debugging or creating new features. Ryan Kienstra, WordPress Engineer, shares his insights of borrowing from existing solutions and making your job easier.
I’m thrilled to announce that WP Engine has named Know the Code as a Top WordPress Education Provider. I’m incredibly honored to be listed as a recommended solutions provider in their Solution Center. Let me share why.
I often talk about not repeating your code. A member wants to know why. Why should you repeat code? What is DRY? Why is it important to you?
In the last episode, we parsed the URL and then used the host element to check if the URL is local to our website. Shouldn’t we use that same strategy for our version query string check? Think about it. Why search the entire URL for the version key pattern when we could just search the query itself? Plus, if the asset was enqueued with the version number set to null, then query may not even be in the parsed URL. Let’s improve our code. Then we’ll walk through all of the checks and make each one readable without an inline […]
If a stylesheet or script is not local to the website, then we do not want to convert or apply a version number to it. Right? The file for that asset does not reside on our website’s web server. Nope, it’s somewhere else. Examples of this are: Font Awesome Google Fonts Bootstrap Zurb’s Foundation As part of our checks, we want to verify if the asset’s URL is local to our web server. How do we do that? Think about what would make a URL local.
It’s time for you and me to think about how to make the shortcodes reusable. Let’s put our three shortcodes up side-by-side and identify what each has in common. We are looking for patterns, those clues to identify reusable opportunities.
Let’s stop and talk about our configuration architecture. Does it make sense to have the configuration files in the plugin’s config folder? Or should those be with the FAQ Module? Hmmm, let’s talk our way through both strategies.
What if someone needs to specify some of the labels, but s/he wants the remaining ones to be generated? Hmmmm, that’s an interesting notion. It seems like a valid optional feature that someone would want from your plugin. Let’s build that feature.
Whew, now it’s time to refactor the label generator function. Our labels are split apart into the three categories. What do we need to do? First, we need to know if we are generating labels for a taxonomy or post type. Then we can merge those together with the shared labels.
Right now our Custom Module is embedded within the Collapsible Content plugin. When is that the right decision versus building a standalone central plugin? You will have projects that need more than one custom post type. And these new types may not be related. That means the architecture dedicates separate plugins. FAQ is part of the Collapsible Content. But a Portfolio feature does not relate to the Collapsible Content. Therefore, it would require its own plugin. A testimonial feature is another solid example of an additional custom plugin. Each of these plugins needs the Custom Module. In this use case, […]