WordPress, tech crap, guns, and more stupid things with your host, @chairmanbrando!
Your heart may be in the right place. There's no point in thrashing the CPU for events like mousemove and scroll that are theoretically going to fire hundreds of times per second, right? But have you checked whether or not your throttling is actually necessary?
Keep on readin' on You may not need to throttle your JS event handlers⟶
I know you're not "supposed" to debug things by outputting them into or past the footer of a site, but sometimes you just need to check on something real quick, like the ID or some other bit of data about a post, and you don't feel like dealing with any proper debugging tools. The wp_footer hook then gets used and the results don't make sense. What happened?
As a purveyor of userstyles, I found myself wanting to change a tiny thing here or there on various sites without giving them each their own tiny stylesheet. I also didn't want to start adding random selectors to a global stylesheet and identifying them by comment; I wanted to identify sites by their domain, e.g. html.apnews-com and keep all styles for that site nested underneath. In order to do this, I think a userscript needs to be involved.
Keep on readin' on Add domain name to every site's root class list⟶
WooCommerce has a handy function you might like to include in your toolbag even when that plugin isn't in play: wc_enqueue_js(). It takes a string of JS code, wraps it in jQuery, outputs it in the footer of your site, and runs it when the DOMContentLoaded event fires. Neat? I guess!
Keep on readin' on Enqueue inline JS at the WordPress footer hook⟶
One day not too long ago I decided to read the entire list of common misconceptions on Wikipedia. Since then it has unfortunately been split up into multiple separate articles, but at the time it was one exceedingly long page that topped out around some 25,000 words and took me at least two hours to work my way through.
Remember that silly thing I did a couple posts ago to avoid looking for DOM changes properly for no particular reason other than not wanting to deal with the syntax of it? Let's take it another step by adding promises to the mix. If it's a step in the wrong direction but objectively makes it better, is it still wrong?
Keep on readin' on Extend MutationObserver replacement with promises⟶
By that I mean that the handy and heavily-used get_post_meta() function, and the get_metadata() function for which the former is a wrapper, do not call apply_filters() on the data they return. Of all the places I've found lacking support for hooks, this one is perhaps the most infuriating.
Keep on readin' on You can't filter meta data in WordPress for some reason⟶
Don't get me wrong: MutationObserver is a great addition to JS, but I find its API a bit clumsy and verbose. I always forget the specifics of its parameters and have to go look them up. Sometimes you just want to write simpler code without needing a reference, you know? Whenever I feel like I have a MutationObserver problem brewing, I go "Dang it!" and consider my options.
Keep on readin' on A simpler alternative to the handy MutationObserver⟶
This isn't limited to WPML (or even WordPress), of course, as it's about translating dynamic strings in general. But SEO best practices say you must have a very specific keyword focus in your title and whatnot or your words will never be seen by human eyeballs ⸺ that your efforts will be for naught but to train some unknown but all-knowing AIs that will never pay you for your contribution.
Keep on readin' on Limiting dynamic WPML translations to one instead of hundreds⟶
One thing you may notice after transitioning from Twitter to Bluesky is the lack of a "joined" or account-creation date on someone's profile. It's not like that data isn't tracked, but for whatever reason it's not displayed. I decided to display it.