The universe has been telling me to write this post for a very long time. The first time was a year-ish ago, when I googled how to get WooCommerce category data with an ID and couldn’t find a clear answer. “Hey, this is a pain to find an answer for – this should be a blog post!” The second time was after I had posted a question on the WordPress Stack Exchange to find an answer, and then I answered it myself. “Whoa – I figured this out! I should tell people about this!”
Then that question eventually ended up earning me a “most popular question” badge. “Damn it, Rachel, people want to know about this – write a damn blog post!”
Okay, so I didn’t do it. Time passed and it was exactly yesterday ( when I began writing this post ), I was working in WooCommerce again, in the zone, went to google, and this happened:
Today's fail: Google how to do something in #WordPress. End up at the Stack Exchange question that you answered yourself. *face palm*
Yep, that’s right everyone. I ended up googling the same problem I had already once resolved and ended up at the same Stack Exchange question I both asked and answered. All right, universe. You win this round.
To make sure I never ever forget I know how to do this again, I’m going to write it down! How to get the WooCommerce product category name, link, image, all the things with PHP so long as you have an ID to use, step by step, in tutorial form.
Before We Get Started:
This assumes you’re familiar with PHP loops, objects and variables.
I am using Advanced Custom Fields for this walkthrough, but you can use other methods like a regular Custom Field and re-work this solution to your purposes.
I am getting category information on a page other than the category archive. If you’re on a category archive, check this WooCommerce documentation first for a head start. I found that the method there and the method I’m writing here are a little different depending on the template you’re working in.
WordPress has this handy theme review handbook. On my quest to learning about accessibility, the requirements in this handbook seemed the next logical step. Since accessible links have been an overwhelming topic for me, learning requirements first give me a head start in addition to learning about making links accessible via context.
The handbook has three required rules for accessible links:
We’ll go over all three in this post. This post is on the lengthy side, but it’s all pretty easy to pick up. What’s difficult is making these techniques a habit in your everyday coding. That, I think, is what takes practice. This post also assumes you’re familiar with basic Css and comfortable with minor edits in theme template files.
I confess. I reached a point in my learning accessibility journey that I became overwhelmed by how much there is to learn. My intention was to start a few posts about links, but there is just so much about accessible links, I didn’t even know where to start. I became discouraged.
Here I am again though, and I’m back on it! I’ve decided that I can’t tell you everything there is to know about accessible links in one post. I can, however, at least introduce the concept and offer resources to wonderful people that have written great things already.
In this post, I’m going to focus on why accessible links matter, how to know if our links are accessible and what we can do right now in our text-editors. Text-editor changes are what’s helping me ease into the concept of accessible links – hopefully it will be helpful to you as well.
Those wonderful people and resources will be sprinkled throughout for those eager to dive into making the most accessible links ever!
I recently faced planning a site that was extremely image heavy. I mean big beautiful heroes and HD videos everywhere – the works! It was like going to an IMAX movie except in website form! Anyway, the point is, there was a lot going on and it was very important that the site remained just as beautiful when the screen shrinks down to mobile as this was a responsive site. The thing is – the images were huge! Trying waiting for a 1400px image to load on a your 5+ year old LG Android – you’re gonna be there a while.
So the problem was, how do I properly code responsive images in WordPress without one, torturing users with slower internet connections and two, still maintaining good practices?
Can I just say that command line and I aren’t friends? I think we have this odd relationship where we pretend we’re friends and then when it gets down to the nitty gritty, we just don’t get along.
I’m new to the Foundation framework. Although I’ve used Bootstrap in the past, for a recent WordPress project of mine, Foundation seemed to be exactly what I needed. I specifically wanted to work in Sass, and I only needed some of the framework. Extra brownie points, Foundation also supports accessibility – hurray! To set up Foundation normally with vanilla ( or just plain old css, not fancy Sass ), the instructions in Steve Zehngut’s WordPress.tv video made sense. To use the Sass version however, this is where my brain was melting…
All of a sudden I was on all these sites, Bower, Node, Ruby, use this command in terminal, then that one! What the hell are all these files in the Foundation Sass version? Which ones do I even need?! Apparently Foundation, Underscores and Sass are quite the combination and it has yet to be documented on how to integrate them together manually – until now.
Yep. With some tinkering ( and frustration ), I finally figured it out. If you’re thinking of using Foundation with Sass in your WordPress theme, and would like a step by step set of instructions all in one place, then this post is for you. And the good news – no command line necessary!
Before We Begin:
For this tutorial, I’m using the Underscores starter theme. You don’t have to use this theme, but for the sake of reference, this is what I’m using.
I’m not using Bower. So we don’t need Node since apparently that’s only necessary if we’re using Bower.
These instructions are tailored for Macs. I’m sorry. T^T
You will need a Sass Compiler if you don’t already have one. I’m using Koala. Don’t use Scout because it’s deprecated. Here’s a handy list of supported compilers. This tutorial assumes that you already have Sass installed and know how to use compilers.
For reference, this is Foundation 5 that we’re integrating.