For as nice and as powerful as ACF is, it’s not without it’s shortcomings (but I guess that could be said about any software). For the purposes of this post, though, this is the software about which I’m discussing.
Specifically, I’m talking about the following scenario:
You have a repeater field that’s defined programmatically and thus doesn’t show up in the WordPress administration area,
The data contained within the repeater field is so much that it exceeds the amount of data that can be efficiently stored in the postmeta table.
I was going to cover each of these in one post but given that they aren’t really related, it seems to make most sense to separate the content.
In this post, I’m going to cover how to import a programmatically defined ACF group. And in the next post, I’ll talk about solutions for migrating data into its own table.
One of the things I read – and learned – early on in my career was the term Architecture Astronaut. It was coined by Joel Spolsky (as far as I know) and it goes something like this:
These are the people I call Architecture Astronauts. It’s very hard to get them to write code or design programs, because they won’t stop thinking about Architecture. They’re astronauts because they are above the oxygen level, I don’t know how they’re breathing. They tend to work for really big companies that can afford to have lots of unproductive people with really advanced degrees that don’t contribute to the bottom line.
I really liked the definition because then, just as I am now, I am surrounded by incredibly smart people from whom I can learn.
And for those of us in this field, it allows us all to:
learn great engineering techniques,
the reason why engineers write code a certain way,
and how to approach problem solving in a pragmatic way (pragmatic being the keyword here, but more on that in a moment).
But that’s not how it always is, is it? Not in other fields; not in WordPress. And the more segmented WordPress is becoming between frontend technologies and backend technologies, the more different these discussions are becoming.
For the purposes of this post, the whole architecture astronaut thing is something I hope all backend engineers pay attention to regardless of where they are in their career. (Let’s avoid architecture astronauts of WordPress.)
I’m trying to branch out a bit with the stuff about which I write this year. And given the the rise in discussions on WordPress Certifications, I see an opportunity to do just that.
This isn’t much of a well-researched or academic article. Instead, it’s an op-ed by someone who’s been in the space for over a decade sharing his perspective on the idea of WordPress certifications in 2023.
If you’re not interested in reading the whole thing, I’ll save you some time and simply state: I’m not completely for it, I’m not completely against it. I think it purely depends on the goals of the person and the needs of any given company who is hiring the individual. Above all else, it needs to be collaborative.
If you run a search for “WordPress certifications,” you get quite a few results back. The thing about these programs is that I have no idea how to determine what makes for a good certification.
Who has vetted the curriculum (let alone who comes up with it)?
Who evaluates the end result of achieving certification?
Who determines what is a satisfactory certification in the program?
I don’t normally do retrospectives for each year for products, posts, work, or anything.
Given that I didn’t write as much as I have in years passed, I thought I’d share what the most popular articles I’ve shared over the last year in hopes of both of surfacing some older content but also setting the tone for the coming year.
Now that we’ve got the basics of the block built, it’s time to introduce some of the features afforded to us by the WordPress API that allow us to make changes to the visuals of our block. Namely, we want to using block attributes for custom colors.
Sure, up to this point, we’ve bee building the blocks using the WordPress APIs for block creation, serialization, and displaying, but we’ve also hard-coded a lot of our our styling. And when it comes to building custom blocks, sometimes that’s exactly what we want to do.
But other times, we want the users to be able to change, say, the color of their text or the background of their blocks, or maybe both. And the APIs for the Block Editor make this possible. As with the rest of the content of this series, though, it’s not without understanding what’s available to us.
Since this series builds upon itself, I recommend reading and following the previous articles thus far especially if you’re just now stumbling across this content.
If you are looking for WordPress guides and unbiased reviews, I recommend checking out WPKube. They also have an exclusive deals section.
Just Getting Started with WordPress? I write a lot about WordPress development but if you're just getting started, I recommend checking out WPBeginner. They have free training videos, glossary, and more.