WordPress

I should note that I continue to remain positive about the direction of the Gutenberg project (the new WordPress editor, coming to you as of WordPress 5.0). My feelings on this are numerous and expansive, but the long and short of it is that I believe WordPress core needs a major shakeup to help the community (re)develop focus and draw in engaged and effective technical participants. Gutenberg represents a wonderful opportunity to do that as it brings a new paradigm to the core editor (and likely elsewhere as the foundational technology expands into other areas of site management) and has the potential to draw in a new wave of web developers.

That said, the introduction of Gutenberg into core has been an interesting thing to watch. From afar, the concerns of the Accessibility Team seem to clearly show the divisions between WordPress as an open source project (WordPress.org) and as a commercial one (WordPress.com). Here is a report from the WordPress.org team on the current state of accessibility in Gutenberg.

Like many technical specifications on the web, RSS (which stands for Rich Site Summary or Really Simple Syndication depending on who you talk to) has a confusing history that seems to only get more confusing as time goes on. The format became popular in the late 1990’s as the need to standardize information held on websites became a pressing concern with the rise of blogging and dynamic websites. The influx of information and content, all organized in different ways, was exciting, but without a standard way to consume the content, you were left with just a few options:

• Bookmarks, and lots of them
• Memorize a handful of URLs and visit only those sites
• Build a custom web scraper

The goal of RSS (as I see it) was to provide each site that created dynamic content a specification to follow to make that content available at some address so the rest of the internet community could easily monitor this address for updates. For example, this blog’s RSS feed is available at https://www.jsulz.com/index.xml. You can take this URL and drop it in Feedly or your RSS reader of choice and every new post I publish will end up there alongside any other blogs you regularly read.

This post was written using Gutenberg, the code name for the WordPress core team’s effort to overhaul the WordPress post editor.

One of the things that we strive to do at LexBlog is help data drive decision making processes. The fetishization of data in business is somewhat akin to the fetishization for new specs and frameworks in development, but data is still a helpful tool (just like arrow functions in ES6) and should not be ignored. And so we track actions in the admin – clicks, navigating to a certain page, performing an action – all the data that a product manager like myself craves. One thing I’ve noticed in watching how our customers use the LexBlog platform is that people post. A lot.

That simple fact shouldn’t be surprising. We run a network of digital legal publications. Lawyers are trained writers, so they write constantly. Basically, if you give a lawyer a blog, be prepared to see them log in, go to Posts -> Add New, and begin writing away. So when I heard that Matt Mullenweg included the editor in the list of primary focuses for the core team, my interest was piqued. When I saw Aaron Jorbin’s post on using Gutenberg last night, I had to try it out for myself.

At LexBlog, my team is responsible for keeping a lot of sites up and running. We help manage the reputation of lawyers and law firms, where each pixel matters. As a result, our product team performs a host of functional tests before launching updates, and we lean on test driven development practices to catch things that functional tests cannot.

An unfortunate blind spot is that humans aren’t machines. We’re prone to miss simple things, and after staring at a screen for hours on end, our brains and eyes get tired. To help catch things that we may gloss over, we use an internal application built using Node.js, React, and Selenium that integrates with the WordPress REST API and an external service, Applitools.

A few weeks ago, Matt Medeiros published a post on the Matt Report that is still making some waves in the comment section on his blog, as well as over on Hacker News. The tl;dr version of the post is that WordPress isn’t easy, in fact very little on the web is, but WordPress confuses the issue by seeming so easy.

On Hacker News, the argument, not surprisingly, is different. In front of a more technical audience, WordPress, and the professional services market that taps into  the software, is quickly the source of derision for any number of reasons:

• Outdated technology stack
• Slow (see above)
• Prone to security issues
• Spaghetti code programmers
• Etc., etc., etc. (read the entire thread if you’re interested, but some of the comments are downright silly, so I’m not going to rehash them here)

REST stands for Representational State Transfer. Defined and described by Roy Fielding in his doctoral dissertation while at the University of California, Irvine, REST is the underlying architectural style of the web as we know it today. RESTful systems, specifically APIs (Application Programming Interfaces) in the context of this post, are those that follow four (or five) basic principals:

• Stateless
• Make use of HTTP verbs
  • PUT, GET (hence the capitalization of the ‘GET’ in the post title – hilarious, I know), DELETE, POST, UPDATE
• Provide a uniform structure/interface
• Properly formatted responses – JSON/XML
• Responses are cacheable

At LexBlog, we make use of a variety of different RESTful APIs – Cloudflare, Twitter, Typekit, and MailChimp to name a few. These APIs allow us to tap into deeper levels of functionality that are only exposed through APIs – an end user that was not aware or capable of using these systems would have a difficult (or likely impossible) time replicating this functionality.

The oEmbed standard is a wonderful development if you’ve ever had to struggle with taking clunky <script> tags or <iframe> embeds and add them to a piece of content. Essentially, the technology makes it possible for a consumer (that’s you!) to add a request, usually in the form of a link, to the provider (such as YouTube or Twitter) so that a piece of rich media can be displayed within a webpage. In layman’s terms, it means that to embed a YouTube video on a WordPress site, all you have to do is add a link to the post, and voila! You have Rick Astley, making sure you know he’s never gonna give you up.

In WordPress, this standard has been implemented in a pretty slick fashion. Not only does WordPress do all the heavy lifting for you in recognizing when a request is to a known oEmbed provider (you can check out the list of “whitelisted” providers that WordPress supports in the Codex), but the UX for actually adding an oEmbed to a post is fantastic.

The order of questions in the title is important. From general to specific. Why blog? Why am I blogging?

First off, I like to hear myself talk. It’s a failing, vanity at its worst, I know, but the sound of my own voice and thoughts is something that’s soothing. A child of Montana, being alone and in my head is a comfort. Blogging, in many ways, affords that same comfort. My internal voice gets a chance to stretch its legs while writing – a meditative exercise.

This is also a natural progression. After working at LexBlog full-time for going on three years, going from Account Manager to Technical Product Manager, my lack of a blog has always struck me as hypocritical – especially since I truly do believe in the power of blogging. For me, this blog is purely about love and knowledge – love of knowledge? Either/or, really. As my understanding of various technologies has grown, so has my desire to keep track of all these bits of information that come my way. Beyond being a place to record my thoughts, this blog is a way for me to grow professionally through writing about the subjects that are near and dear to my hear. Hopefully, if you’re reading this, you feel the same way about these things that I do.