WordPress, tech crap, guns, and more stupid things with your host, @chairmanbrando!
Sometimes some search or meta query you're trying to do refuses to cooperate and and return results. If you thus find yourself poking around WP_Query's request property, which is a copy of the SQL statement executed to create your query object, you may have noticed some odd and space-inefficient syntax when using the LIKE operator.
Keep on readin' on Remove hashed placeholders when debugging WordPress SQL statements⟶
This isn't the default behavior for whatever reason, and it's something I've just silently dealt with for years. Because of this default functionality, instead of using [keys Cmd-N] I've always used the GUI buttons for creating new files while working on some project. I didn't think an alternative existed, but I've finally found that one does.
Keep on readin' on Make VS Code slot a new file in the current directory⟶
Let's say you've got to position some element at the top of a page but that its top property will have to vary depending on the existence a couple other items that might also be up there. For instance, you want to position: sticky a menu bar but you have to contend with the possible presence of an announcement banner as well as the WP admin bar.
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⟶