As I have used the Windows OS more, there are a few bits of information and small tips I have socked away. I’ve been most of this data over and over again as I have gotten to know the Windows OS as a development platform. A few of these things I feel like I have found better solutions to, but will continue to leave here for now. I will try to come back and update this list as I continue to learn Windows. It’s worth noting for now this list is based on my use of a Surface Pro 3 running Windows 10.
CategoryTechnology
The first time I powered on the Surface I didn’t quite know what to expect. It has been so long since I used Windows to do anything other than open up a web browser. I was a little nervous. After all, I’m supposed to be the “computer guy” in my family, but there I was with no clue what I was doing.
After running its welcome animation the Surface guided me through the setup steps. I put in my registration information, created an account, and got to the desktop screen. I’ve used Windows enough to have a general idea of how to find things. At that point, though, if you had said to me “Ok, now go make a website” I would have looked at you and laughed.
I gave a talk in 2013 at WordCamp Denver called Breaking Up with *AMP about using Vagrant as a development environment. The presentation was received well, but for me I was more excited about the following day. Sunday of WordCamp Denver was designated a hack day, and in short order, it was decided that the main focus of the day would be core contribution.
Many participants were struggling getting up and running with the toolset required to work with WordPress core code. So we made the decision to get everyone going by having them spin up an instance of VVV. This worked fantastically because all of the tools needed to contribute back to core were packed in the virtual environment.
It worked great for everyone in the room—except for one person. He was on Windows.
I recently had the opportunity to speak for to the Advanced WordPress group in Austin. Special thanks to Corey Ellis for putting it all together. Here are my slides and demo videos from the talk. We had two cameras on the room, so if I find a video of the presentation show up I’ll hook that in here as well.
The main idea: SVG is not so scary. If you know HTML and CSS, you have what you need in your toolbelt to start playing with SVG. This short light introduction focuses on using SVGs as Icons making use of the <use> element.
I started attending the Portland WordPress Meetup a few years ago as a way to make connections and improve my WordPress skills. However I quickly discovered simply attending meetings wasn’t helping my coding skills much. Then we had Lance Willett come and speak on breaking themes. The talk was excellent, and afterwards I made sure to introduce myself.
Lance was very gracious and offered me his contact information and told me to send him so code and he would be happy to review it.
I was excited!
I was terrified…
Shortcodes are very handy for WordPress developers. They are flexible and powerful. They can trigger complex functionality or provide fine tuned control when creating content. The biggest problem with shortcodes is that they are too much like code.
In the WordPress development world we are used to dealing with templates. WordPress themes for the most part are a grouping of a bunch of template files that make up the look and feed of a website. We use template tags in the form of short PHP function calls to insert data into the surrounding HTML so that many different pages, or parts of pages, can use the same markup.
While we are used to doing that in WordPress with PHP, I find moving that thought process to Javascript can be a bit of a stretch for some developers. The idea is almost the the same, a bunch of HTML with tokens in it to represent where data should go and how it should be organized.
There are various ways to go about templating in Javascript. There is a loose specification called Mustache which is implemented in many languages including Javascript. Extending that a bit is a library called Handlebars. The Underscore library has templating in it as well.
What you may not have realized, though, is that WordPress has shipped with a JS templating helper since WordPress 3.5. It is based on the Underscores templating engine, but it modifies the syntax of it to make it look and feel just a little more like the Mustache, but without dragging an entire extra library along for the ride.
Here’s a definition for the wp.template method.
Continue reading
Over the years WordPress has provided a myriad of tools to make ajax requests in WordPress a little easier. After the new media modal was introduced in WordPress 3.5, a new set of tools went in to WordPress core. The javascript object wp was extended with many things, including wp.ajax. This combined with the wp_send_json_success() and wp_send_json_error() helper functions can help make performing ajax requests with the admin-ajax.php processor very straight forward.
If you are not already familiar with the admin-ajax.php processor, it’s worth learning a little more about. It is not and should not be the only way you work with Ajax in WordPress, but it’s a very useful tool to have at your disposal and should not be overlooked.
Let’s start by defining what wp.ajax is and does. It contains two methods currently, wp.ajax.post() and wp.ajax.send(). I’m going to focus this article on wp.ajax.send() because wp.ajax.post() is really just a wrapper around the send method that ensures the request is sent as a POST request. Beyond the request type, both .send and .post work almost the same.
Continue reading
Ajax can be a confusing topic. I’ve spoken with developers who didn’t have a grasp of where Javascript ended and Ajax began. So before we dip into Ajax with WordPress, lets take a look at ajax itself.
Ajax is a request to your server
At it’s heart, Ajax is nothing more than an http request. It is a single request to a server which then sends back a response. This is very similar to typing in an address in your browser and hitting enter. It makes a request to a server which then sends back a response.
The magic of Ajax is that this is done without unloading the current page and loading a new one.
Continue reading
The way the plugin system works in WordPress, plugin files are included in whatever order they happen to be in when the list of active plugins is saved to the database. There are plugins to control the load order of your plugins, but these are somewhat glorified hacks. There is certainly nothing wrong with them, but it is a bit bothersome to me that they are needed at all.
Whenever I write plugins, I make an effort put off the set up of everything, including adding any actions or filters, until the plugins_loaded hook. This action happens immediately proceeding including the plugin files themselves, which in my mind makes it the perfect time to run set up.
Nothing else has run yet, but everybody’s been invited to the party.
If all plugins are written this way and one plugin needs to make a modification before another plugin sets up, or needs to load earlier than other plugins, or needs to make sure it loads after other plugins, it’s a simple matter of setting the correct priority on the add_action() call that registers the setup function.
By this same token, I wait to do any theme setup until the after_setup_theme hook. All theme files have been included, nothing else has run. This is somewhat less important since you’re not often running more than one theme, but in a child theme situation I still find it can be worthwhile.
Understanding when your code runs in relation to when other code runs can be very valuable. This little change in mindset when authoring code can help you keep your code just a bit more organized. It may also help another developer down the line when they need to get a bit of code running before yours does.
© 2024 Luke on Everything
Theme by Anders Norén — Up ↑