I have been very vocal in the WordPress community about the fundamental issues I see with the new visual editor being bundled with version 5.0. One response I keep hearing is “how would you do it differently?” So, I thought I’d outline a hypothetical roadmap for the Gutenberg that might have been. read more »
Gutenberg is the code name for WordPress’s new visual editor, which is designed to add block support to WordPress. Gutenberg is not currently earmarked for a specific release, but signs seem to point toward WordPress 5.0. It has a promising UI, and has been through a fair number of iterations already, but as work continues, I find myself more and more disenchanted with the solutions they’ve proposed. I find myself constantly taken aback by the incredible number of flawed premises that comprise the project. read more »
If you already know all about the WordPress editor, you can skip directly to the section on separation of concern.
The WordPress editor is a curious beast. It’s oddly tied down into the core codebase, despite being a completely external project (TinyMCE), and it has given rise to a significant number of hacks and workarounds, to try to support the various workflows of different WordPress users. Since 2017 is the year for WordPress core to focus on the editor, I thought I’d put down some thoughts, in the hopes that I might help inform some decisions. read more »
WordPress allows most HTML in the post_content field, allowing a fair amount of flexibility for formatting post content for browsers. However, when that content needs to be presented in feeds or excerpts, it is run through a set of sanitizing filters that strips this HTML, leaving bare text.
For the most part this works ok, but when WordPress strips block level tags like
<blockquote>, or even
<br>, the remaining text can be jammed together, causing words to run together.
It would normally be a fairly simple task to add a regular expression which would add whitespace around such tags, before stripping them. However, WordPress considers the functions in question so integral to the core functionality, that they do not include any filters to hook to at all.
To address this shortcoming, I needed to step back a few levels, and rewrite several WordPress core functions from the last place there is a usable hook. To save you all the trouble i went through, here is a single-file plugin that will insert the relevant missing formatting:
I’ve been writing a lot of WordPress plugins recently, and one task keeps popping up, that doesn’t seem to have a definitive answer in the WordPress core. I’ll need to show a message (confirmation, success, error, notice, warning, info, etc) to a user, after redirecting them through one of the scripts used to save changes, such as admin_post.php (for example, using the save_post action with a custom metabox).
Because I’m a strong proponent of DRY programming (Don’t Repeat Yourself), I wanted a universal tool to solve the problem, once and for all. I’ve created a small class that I call WP_Persistent_Notices. It’s a singleton, and is pluggable, so there should be no issues with simply including it in a theme or plugin, as is, and not worrying about another theme or plugin also including it. read more »