Improving WordPress Part 3 SoC & The Editor (A suggestion to Core)

字体大小 | |
[开发(php) 所属分类 开发(php) | 发布者 店小二05 | 时间 2017 | 作者 红领巾 ] 0人收藏点击收藏

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.

First, let’s talk about what the editor does, and walk through some of the different workflows it supports.

The WordPress editor, at its heart, is just a way to get the body of a post, whether text or html, into the database field “post_content”. That field is designed to be the sole, canonical source for WordPress post/page content, whether accessed by excerpt, search, feed, api, or any other method.

The simplest way to insert content into post_content is via “Text Mode”, where the user enters plain text, to be published as-is. Of course, unless the content is wrapped in <pre> tags, that content would look terribly unformatted to viewers, if loaded directly, so on save and output WordPress runs several regex-based filters to produce readable content, such as wpautop.

Text mode isuseful for bloggers and writers who want to focus on content, and get their work out quickly and cleanly. The fact that it renders as plain text also makes it a breeze to use other editors and either copy/paste when complete, or hook into the WordPress API, and publish content directly from your editor of choice, such as MarsEdit. However, it leaves the author with very little control over appearance and formatting.

This lack of control is addressed in a few ways. Firstly, for formatting, text mode supports inserting HTML directly into the body of the post. Secondly, dynamic content can be added to the post via “shortcodes”, which are a bbcode-like language that theme and plugin authors can expand on. Both HTML and shortcodes, when entered, are stored directly in post_content .

Since adding HTML in plain-text isn’t all that intuitive (and because formatting it runs afoul of wpautop ), WordPress also provides a visual editor, which renders tags as HTML, and provides easy access to several inline elements and headings.

Now, in 2017, the WordPress core is working on revamping the visual editor to focus on “content blocks” (user defined formatted areas). This project is codenamed gutenberg . However, there is a deep-rooted issue with these plans, which is cross-compatibility. The sad fact is, none of these modes actually work smoothly together.

Pitfalls of the unified post_content system

To maintain the tagless flexibility of text mode, html is added to posts at run-time, based on whitespace that would otherwise be ignored. However, because of that, it is impossible to effectively and legibly enter raw HTML or even shortcodes in textmode, because basic formatting and indenting of HTML (or shortcodes with content) will cause all kinds of <p> s, <br> s, and &nbsp; s to be inserted into the output. Yes, this can be turned off withfilters, but it leaves the two modes incompatible, as you can’t switch from one to the other without changing filters.

Next, visual mode escapes raw HTML that is entered into it, and if you switch to text mode to add HTML, then back to Visual, the code is often “Normalized” by the browser, in ways that can absolutely destroy functionality. In addition, certain valid html5 constructs (such as links that wrap block-level elements) are not supported by the visual editor, and will be converted to block level elements that contain links, in a way that often breaks both semantics and accessibility. In addition, some HTML is filtered out by WordPress’ sanitization functions, arbitrarily removing javascript handlers and some advanced attributes. So, now Visual Mode is also incompatible with text mode, or raw HTML.

Also, any HTML or shortcodes added topost_content becomes visible to the WordPress search functionality. This can lead to confusion for users, as the shortcode [fusion-gallery class='cold'] might appear on pages that have nothing to do with cold fusion, or the tag <marqueetype="odeon"> might appear on pages that have nothing to do with the Odeon Theater’s front visage. In the worst case scenario, this type of search ambiguity can be used for penetration testing, as you can search for strings like [ngg_images , to search for plugins with known security flaws.

Starting with WordPress 4.4, Images added to posts also run through filters to add responsive source sets (formerly RICG responsive images). These filters match images based on their class attribute, while images in visual mode are displayed by their src attribute, meaning that an image’s source can be modified in text mode and saved, without modifying its class attribute. As a result, the image can look great to the user a a specific resolution, but other viewers on other devices may be served an entirely different asset. Furthermore, as these image sizes are chosen from the theme’s defined thumbnail sizes, themes with poorly chosen thumbnail sizes can serve extremely undersized images to certain screen sizes, and none of this is presented to the user.

The new idea with content blocks (project gutenberg) is to add sections of HTML with special markup into the content, to allow users to insert columns or images or other custom blocks, as defined by themes or plugins. I believe this idea, will further compound the core issue that the WordPress editor is dealing with: Lack of separation of concern .

What is Separation of Concern, and why is it Necessary?

Separation of concern is a concept in programming (and several other fields) which says “let different pieces of a project serve specific tasks”. Normally, with web design, it means that your HTML should be clean and semantic and clearly describe your site’s structure, your JavaScript should be minimal and well documented and offer additional functionality, and your CSS should be logical and offer visual styling. However, when it comes to WordPress, people usually mean it as “let the theme handle presentation of data, and plugins handle exposition of functionality”. The problem is that the entire concept breaks down, when it comes to post_content .

post_content only makes sense as the sole source of data for posts, when it is only serving raw text. That made sense when WordPress was a new system just for bloggers, and still mostly made sense as individual features were added, each compromising SoC, but in 2017, we’ve gotten to the tipping point, where WordPress is no longer a blogging platform with bolt-ons, it’s a Website Platform with great blogging capabilities. As such, we need a change of approach.

Most people who still use post_content for pages other than blogs are relying heavily on shortcodes and html in text mode to meet modern formatting needs. This clutters search, and (as I mentioned in my last “Improving WordPress” post) damages auto excerpts and feeds. In addition, when themes/plugins break or web-standards change, they are left with potentially hundreds of pages of broken code. As far as I can tell, content blocks are still subject to this issue.

Those who have abandoned post_content for ACF or Beaver Builder or Widget Areas or flat HTML templates are heavily reliant on plugins that fight the core for every inch, and still fa

本文开发(php)相关术语:php代码审计工具 php开发工程师 移动开发者大会 移动互联网开发 web开发工程师 软件开发流程 软件开发工程师

主题: HTMLWordJavaScriptJavaHTML5CSSSoCCG
tags: content,WordPress,HTML
本文标题:Improving WordPress Part 3 SoC &amp; The Editor (A suggestion to Core)

技术大类 技术大类 | 开发(php) | 评论(0) | 阅读(130)