10 WordPress Things I’ve learned working with 10up

Reading Time: 8 mins

It’s been half a year since I joined the 10up team and I’ve been learning so much about the CMS I love so far. Working with a company where I can continue my WordPress adventures full time has been a rewarding experience. I’ve met new people, dived into open source, and made new discoveries in WordPress. Since it’s long past due for a new post here on RachieVee, I’d love to share 10 WordPress things I’ve learned working with 10up – a mixture of newly discovered tools, techniques and functions!

Spoiler alert, I’ve written more than ten and there are front-end related things too. Confession, I just wanted to use the whole 10 things with 10up title.

In no particular order, here is a list of things I’ve picked up either by directly working on projects or being exposed to new opportunities during the past six months. Enjoy!

10 WordPress Things I’ve learned with 10up:

1. WordPress has a Javascript templating language! WordPress has Underscore.js style template functions that feel like Mustache. This is created from wp.template and can be used to build WordPress templates with Javascript as an alternative or companion to PHP. If the info on the Codex isn’t enough, Luke Woodward has written a nice tutorial on using wp.template for front-end templating.

2. Never set up another development environment again. I can’t tell you how often I’ve worked on projects in the past that behaved locally, maybe even behaved on staging, but all chaos unleashed on production. Sometimes no matter how much we prepare our local environments, nothing can predict how a site will behave on a server more than being on an actual server. This is where Vagrant comes in.

Vagrant is an automated tool that builds development environments using virtual machines. Once you’ve set Vagrant up with your configurations, all you’ll need to do is check out the code that you’re working on, and bam, you’re ready to work.  What makes this even better? Varying Vagrant Vagrants (VVV) is an open source tool used with Vagrant for WordPress development. Once this is set up, not only will starting up new WordPress environments take significantly less effort than when you had to do it manually, but you can now contribute to WordPress core if you’d like.

3. Never manually create local WordPress sites again. Using Vagrant and VVV, there’s an additional tool that creates a new or existing project without having to do it manually. As in no more hunting down the latest version of WordPress, downloading it, setting up an empty database, going through the installation process, setting up urls for local development and so on? No more of that with Variable VVV. With Variable VVV, depending on how you configure your blueprint file, it can have your local urls set, your databases imported, your WordPress version installed, and even a repository checked out. You’ll usually have to go through some prompts in command line based on how it’s configured, but once you’ve given it the values it asks for, it’ll do the rest while you enjoy a cup of tea that’s still hot for once.

Use Vagrant, VVV, and Variable VVV so terminal can do all the work and you can finally enjoy that cup of tea Kermit style.

 

4. You don’t have to use intval(). I like using intval whenever retrieving data from custom fields or ACF when I want to ensure that data is an integer. Turns out though, WordPress already has a function that does the same thing, absint().

5. Escape and translate data in your WordPress templates. To prepare your WordPress theme for translations as well as ensure any data created by users ( think custom fields and ACF ) are safely escaped, make use of these three WordPress functions. These functions secure data being output from the templates before rendering it for the end user. Use one of these as an alternative to just echo’ing out data in your templates. Check out the Codex for more sanitization and escape functions.

esc_attr();

Assuming we don’t want the above attribute to be translated, we’d use esc_attr here instead of esc_attr_e. Thanks Sergey Biryukov, for pointing that out.

esc_html_e();

esc_url();

 

6. An object and an array are not the same. This is something I’m still trying to wrap my head around, but sometimes, when I’m using var_dump(); to see WordPress data, although I see the values I want to grab, I’ve had issues echo’ing them. The problem was that I didn’t know the difference between when I was looking at an array or an object. Depending on which I was dealing with, depended on how I would echo that data. In my example below, notice that the difference here is either using brackets or an arrow to pull the “ID” value from the array or object. Knowing that there is a difference definitely saves me from some of those “Y U NO” work moments.

Be sure to check whether you’re trying to pull from an array or an object.

7. Get the attachment url easily with the wp_get_attachment_image_src function. Okay, this might not be mind blowing to some, but I always love discovering a new function. I literally have an entire bookmarks folder dedicated to my favorite WordPress functions. Did I just admit that out loud? Yes. Yes I did.

8. Create test data with the WP Test. WP Test has test data you can import into your WordPress installation to help resolve styling and structure issues that may arise with quirky content. Definitely a lot more useful than copying and pasting lorem ipsum – well unless it’s Batman Ipsum. Batman Ipsum always has a use.

9. There is UI for shortcodes with WP ShortcakeAlthough shortcodes are generally discouraged, for custom client-specific themes that will likely never change, having a UI to use shortcodes enhances the UI experience. WP Shortcake creates visual representations of shortcodes in the text editor instead of that cryptic and intimidating code that gets dropped in without the plugin. It also makes managing shortcakes less mistake prone due to having fields to edit versus working with code.

10. Use wp_localize _script to load PHP data for use in your JS. Have you ever had PHP data that you wanted to use in your JS, but didn’t know how to go about it? Turns out you can use wp_localize_script to do just that. This function prints your data and when you enqueue your script, you can access that data. It’s mind-blowing. There’s a great tutorial written by Pippin Williamson called “Use wp_localize_script, It is Awesome,” if you’d like to learn more.

There you have it, ten of the many things I’ve learned so far working with 10up. I’ve also been strengthening some back-end skills and have been exposed to creating custom fields from scratch without resorting to my former beloved ACF plugin. Definitely a lot of work, but worth the deeper understanding that comes with it. The WordPress toolbar has also re-surfaced in my front-end adventures. The toolbar does effect styling so definitely take it into account whether it’s showing or hiding on the front-end, and take advantage of the admin-bar body class.

If you want to learn more about how 10up’s Engineers write code, check out the 10up Engineering Best Practices on Github.

Oh! And did you know WordPress Core has a “Good First Bugs” list? This is great for anyone looking to contribute to Core and not sure where to start. 10up is big on being active in the community and discovering that list definitely made the entry to Core feel more feasible. It does have a learning curve and takes some time, but once you have Vagrant and VVV set up on your computer ( see #2 on my list above ), then you’re ready to tackle Core bugs with this list.

I’ve been having so much fun learning, I realized I couldn’t just keep this post to one list with only WordPress related items. As a front-end engineer, I’ve been discovering and picking up other cool things that I wanted to share as well. So here’s another ten!

Bonus! 10 non-WordPress Related Things I’ve Learned with 10up:

  1. PostCSS is a tool to transform your styles with JS plugins. I like to use the auto prefixer and the SVG fragments plugins.
  2. Repeatable Fields is a jQuery plugin that helps to create, well, repeatable fields. If you’re ever creating custom fields from scratch, this can come in handy without having to miss using a plugin like ACF.
  3. Practical ARIA Examples is a list of realistic code patterns. It’s a good starting point in getting to know ARIA and how to apply it to things we build all the time like modals, tab menus, and alert messages.
  4. Explicit and Implicit Labeling in forms. This is one of those “new” terms I discovered during my accessibility journey that I hadn’t known before. The article I linked to in this number four, titled “Labeled with Love”, is actually about how to properly use labels in your forms. However I specifically mention explicit and implicit labeling here because this was the first source I read that really explained to me what those terms meant. Whatever fuzzy understanding I had before, cleared once I finished reading this.
  5. Never have trouble naming colors again! If you’re using Sass or LESS to create color variables, then you know how difficult it gets to name colors until you end up with grey-1, grey-2, sorta-grey, whatever-grey. There’s a tool called Sip where you can eye drop any color from anywhere on your screen and it will give you the hex number along with a clever name – a name better than “super-dark-blue”. For those with vision disabilities who might not see colors the way they were intended, naming colors can be tough too. What’s “blue” to me, might not be blue to you. So there’s another tool called Color Name & Hue where you can use the Hex/RGB/HSA to return a name for the color, as well as the “hue” to get a general idea of what this color should be, even if your eyes aren’t able to perceive it that way.
  6. Test all the things in Browserstack. Unfortunately it’s not free, but there is a trial. If you want to put your sites through serious QA and don’t have a million devices lying around, this can be a great option for browser testing. Test on many platforms and browser versions, you can even test local urls.
  7. Styling Ranges is hard. Not every browser handles range inputs the same and for those not wanting to resort to a JS library, trying to use CSS only is tough. It might not solve all your problems, but this style generator for range inputs definitely helps.
  8. Trying to ditch jQuery for vanilla Javascript? Me too! However, the transition can be difficult. Getting your mind to wrap around how to do things you already know in jQuery, except with Javascript instead is a challenge. Ditching jQuery and You Might Not Need jQuery have been my two most frequented go to references so far and they’ve been making that shift just a little less painful.
  9. Do you truly understand Flexbox? I confess that I don’t yet. While “A Complete Guide to Flexbox” is a great head start, it’s still a lot to digest. Sometimes it helps to “do” more than to read about it, and why not have fun at the same time? Flexbox Froggy is a game where you write CSS and learn about using flexbox. Sounds like a win win to me. No pun intended.
  10. CSS only animations without manually having to write them? Yes please! Animate.css is a library of animations you can apply to your code using classes. Using a library like this takes out the guesswork and speeds up the process compared to having to create them from scratch.

That makes twenty-ish things I’ve learned. In the past half year, I’ve been going through a lot of personal and professional shifts. Going from in office agencies to freelance to full time remote. Going from working on a variety of projects and platforms like Magento and Drupal, to primarily focusing on WordPress. I’ve come from places that discouraged open source to contributing to WordPress for the first time by discovering bugs in Trac, and helping out with the Accessibility Handbook when I can.  I’ve come from knowing zero about web accessibility to writing on RachieVee as well as writing “What is Color Contrast?” on the A11y Project. It’s really cool to see how far I’ve come from a fine arts degree right out of college a few years ago.

These past 6 months with 10up have been an amazing experience so far. I work with a lot of awesome people who enjoy knowledge sharing and I couldn’t be happier growing with them. I’m excited to see what lies in my future and to someday compile another list on RachieVee of things I’ve learned. Look forward to it. Until next time – happy WordPressing!

12 thoughts on “10 WordPress Things I’ve learned working with 10up

  1. Nice post!

    It’s probably worth noting that esc_attr_e() should only be used for translatable strings, not as a replacement for echo esc_attr(), so if 'red-class' is not meant to be translated, echo esc_attr() should be used there.

  2. Nice post.

    One point of clarification: You state, “I like using intval whenever retrieving data from custom fields or ACF when I want to ensure that data is an integer.”

    PHP’s intval function (and by extension absint, which is just a wrapper for calling abs on intval) does not ensure type. Per the docs, intval (and absint) return 0 if the argument is not an integer or 1 if it’s a non-empty array or Boolean true.

    To ensure type, call the PHP functions gettype or is_int.

    • Thanks for stopping by, Doug, and thanks for the tips! I’m a front-end developer who is trying to pick up back-end magic so I love getting PHP tips. I was always under the impression that intval converted values into integers. So the string of 5 would become an integer of 5. Will definitely run some tests now so I can solidify my understanding. Thanks again. 🙂

      • Welcome to the dark side. Also, full disclosure: My employer is a 10up customer and I’ve worked some with your back-end devs.

        I sometimes use absint the way you do. If I am fairly confident that the value I am requesting is supposed to be an integer that’s not zero or 1, I’ll just evaluate if absint( $var ) > 1. For example, if I call

        $postid = absint( wp_insert_post( $postarray ) );

        Then if $postid = 0, I know it didn’t insert. Which is a perfectly acceptable way of error trapping if you don’t care about why the error happened. Which is often the case.

        Again, nice post.

  3. having package.json in theme folder will speed the development. When you have npm installed and put this command npm run build:all will minimizes all css, javascripts and other stuffs. And then put the git command will push your code to github or bitbucket. Vagrant is better choice definitley.

    • Agreed. I’m still fairly new to using grunt/npm and having all the packages installed just by running npm install in the theme has been awesome so far. Vagrant has a bit of a learning curve to set up with VVV/Variable VV but once it’s all working, it’s such a time saver. Thanks for sharing your thoughts.

    • Thanks Carrie, happy you enjoyed it. WP Test has definitely become a regular process for me every since I discovered it – especially the markup and image alignment posts. Super helpful!

Leave a Reply