I’ve been coding since 1998-ish and our industry moves fast. Every website I code tends to have some kind of structural improvement over the last. Some things, like my verbose CSS section comments, have stayed the same. I’ve been around here long enough to see enough trends come and go, that I usually have a good idea of what’s going to stick around!

So what are some of the major differences and changes I’ve made in the past decade?

Still no Gutenberg!

Yep and I still refuse to use React (sorry, not sorry!). Lest you think I’m just being a big meany and not wanting to learn something new, I have coded a few Gutenberg builds. ACF ties pretty nicely into Gutenberg, eliminating the need for actual React or build processes. But I still hate it and won’t use it unless the client asks for it. I still find it confuses a lot of users, isn’t very accessible, and introduces too many variables and opportunities to be buggy.

Post Type Variable Management

Back when I was working with multiple developers at Studio Simpatico, we ran into an issue with variable management for our loops. At first, I had an include file for each post type that assigned standard WordPress functions to variables. For example:

$title = get_the_title();

My thought process came from experience – we’d often have multiple loop/card styles for each post type, and if something changed (like the client deciding they didn’t want the title to be the actual title or to have an override), we’d have to go in and change every loop file. Not cool. 

So I started having post type variable includes, where I would include the variable file at the top of each loop file. The problem with this route quickly became apparent. Variable includes got messy when mixing multiple post types, they could be hard to find or forgotten when another dev picked up the project, and they were kinda unwieldy. So instead we put these functions into our own PHP class system, and while that required a heavy set up at first, now it’s super easy to add on more post types as well as overriding specific functions within them. So for example:

$the_post->get_title()

This might just echo out the regular post title on posts, but on another post type it might spit out an ACF field instead. Same functions, different post types, one place to change them all. I can’t claim credit for this piece of genius (thank you coworkers!) but I’m gonna keep on using it!

More Javascript, Less jQuery

Yep, you read that right! I spent a lot of time last year really digging into functional JS – which means I’ve been slowly replacing a lot of my jQuery! Never thought I’d be a fan of JS (and let’s be honest, I still have a love/hate relationship with it) but I am slowly coming to terms with it. I have a lot of difficulty grokking the more abstract languages. CSS and HTML? I can code that in my sleep, mostly because it’s more of a “visual” language and seeing the output is a whole lot easier. But I’m doing better in the abstract, I even managed to code some fun basic games!

From a development perspective, this change is pretty important – the less frameworks you use, the less overhead you have.

Still ACF all the way, but this time Extended

ACF is still my favorite plugin and I never thought it could get any better. Until a third party plugin, ACF Extended, came into being. An add-on for ACF, it gives you the ability to have post type archive groups, columns for admin layout, and just generally makes the regular ACF plugin even more powerful. It’s also seamless and makes sure the block editor stays gone.

My admins have only gotten neater – I love taking the time to set up module fields in a way that makes more sense for the user. Most of the sites I code no longer use templates, but are just modules in a Flexible Content field. Once I got into building much bigger sites that required a lot of different modules and styles, the admin started struggling to load those huge groups. I found that by making each module it’s own group and leaving it inactive (so it doesn’t show anywhere), and just cloning each group into the flexible content field, the admin now loads lightning fast. I wrote about this extensively last week.

I’ve also dropped having ACF in the database – it’s all synced via json files and access to the fields is cut off in admin to prevent someone from accidentally messing up the syncing. I can access them myself on the local install only.

Local, Local, Local!

Speaking of local, I now also use Local to build sites. Super easy set up and install, and I love the instant reload after saving your CSS file. If your site will eventually end up on WPEngine, you can push and pull directly from the server!

I also finally got on board and have all my files deploying from Github Actions. Yea, yea, I know I’m late to that party.

My Type A-ness and organization

I’m constantly trying to find ways to keep my codebases organized. Recently I’ve gone with keeping as much PHP and logic (usually just variable assignments) at the top of the module file and the echos in the actual HTML.

Each module is it’s own include, and within that module, if the various styles are different enough, those will also often go into their own files. While this has made a lot more folders in my WP theme, I’ve found it’s actually easier to find where stuff is.

CSS and HTML Changes

So many to list here!

  • I use variables for everything, which ensures consistent spacing, colors, and other globals. In order to do this though, you’ll need a designer who designs in a similar way or is at least fluid enough to let their designs fit in a consistent manner.
  • I use calcs for all font sizes and line-heights – using calc(24rem/16) tells me immediately that it’s a 24px size font, while keeping it in rems for accessible resizing.
  • I still prefer one long CSS file – it’s easier to jump around on and I use a minifier anyways so it’s not a big deal in terms of performance. I still prefer to arrange them as globals on top, header and footer styles, homepage (or builder) styles, then the archives and their single templates. Media Queries I still keep at the bottom.
  • More accessibility of course! I’m constantly changing my starter theme to be more accessible. I’ve switched from regular Slick Slider to an accessible fork of Slick Slider as my carousel of choice. My mega menus are now 100% keyboard navigable out of the gate, including all necessary JS and CSS styles. All animations are behind a prefers-reduced-motion MQ.

Phew

My biggest lesson from tall this? Make functions/variables for the code you repeat time and time again.  This makes things so much easier when you need to jump back into the codebase two years later and you don’t remember anything about it. These are just a few of the things I can think of off the top of my head, a lot’s changed in 10 years, and the next 10 years are sure to bring more!!

Amber Weinberg

Amber is a freelance front-end developer specializing in semantic and accessible custom WordPress themes. She works with agencies and other freelancers to bring their designs to life using custom ACF flexible layout builds - making them more performant and less buggy while allowing the client easy customization without breaking the design system.