Blog

Posted on by Edwin Cromley

WordPress, the power of Community, and a vision of a new connected WordPress

I was inspired to blog from @photomatt’s birthday blog post. WordPress has reached a huge market share of the web. If you want to build a website, WordPress is a great option, if not the best option. We have also seen the web at large become dominated by a few platforms namely Meta’s Facebook and Instagram, Twitter now X, and the new comer TikTok. There is a rising interest in decentralizing social media as many feel the web has been lost to these major gated platforms. These platforms reaching massive scale has brought up many thought provoking questions and has impacted society tremendously. I was a kid when Facebook first came about and at the start it seemed like a nice way of connecting with people I knew. Unbeknownst to me at the time these platforms were harvesting our personal information and using it for various purposes like targeted advertising. Privacy and control over our personal data were compromised. What platform out in the world is open, independent, at scale and free? WordPress! WordPress can become the bedrock for an open social web liberating us from the control of the major platforms of today.

Moving forward with WordPress as a deeper connective tissue of the web

Inspired by Gary Pendergast’s talk on Connected WordPress I think now is the time to see this venture move forward. I will be dedicating my free time to working on making this a reality and would love help from fellow people who are interested in moving WordPress as a platform forward. We see efforts from Jetpack for reblogging and following and liking, but it does not really seem to have gained a lot of traction and I think misses the needs of people today as a social network. There is also BuddyPress which has many of the features of a social network, but is essentially centralized to your site and does not inter operate out of the box with other sites running Buddy Press, so not really a social network for web scale.

We see platforms like Slack being used to host communities, like Post Status, but this is yet another centralized closed service. Imagine if we could turn WordPress into a hub for communication, publication, and data ownership. Instead of Post Status using Slack it would natively host the same functionalities using WordPress. Now you might be thinking I am suggesting we somehow use native WordPress APIs and build this the WordPress way. No. I am proposing that a new decentralized/federated network is built on top of the massive scale that WP has reached.

The decentralized social network

There are a number of projects in the decentralized and federated social network space. It is a hot topic among developer circles but has not really caught on with general population. I think it will be very hard for mass adoption of these platforms as the onboarding and UX is not better than any of the major players. We are simply in a different landscape and I am not sure if the promise of decentralization is enough to attract people to these platforms. This is where WordPress could be a great platform to piggy back off of. WordPress is already federated and decentralized as this is how the open web works.

There are projects like Mastodon, Nostr, Gun.js, Matrix, SSB, and the AT Protocol, to name a few. I am sure there are many more that I am missing, but these are definitely players in the decentralized social network space. Most of these are protocols, and what I am thinking is we could get WordPress to speak one of these protocols. Then we would develop a client that operates on these protocols. The client could be run via Web Assembly to bootstrap it in a browser session or run on a native application. Spinning up a pub/relay would be as simple on WordPress as installing a plugin and configuring a few settings. If done well this would mean that the network could scale up very rapidly and go from unconnected nodes to a more rich mesh.

Which Protocol?

I think out of all of them Secure Scalable Scuttlebutt would be the ideal. It is a protocol that supports End-to-End Encryption a flexible schema for supporting applications, and is truly peer to peer and offline. The p2p and offline capabilities I think would be great in developing countries where internet is not always there but devices like cell phones are relatively common. With SSB over Wi-Fi you could connect directly with others on the network. WordPress again is the platform to build the network on top of as a bootstrapping point.

Task at hand

With PHP 8.1 Fibers were introduced as a low level way of starting to support asynchronous code in PHP. By default they will run synchronously but with a scheduler PHP can be made to operate asynchronously. So if someone has PHP 8.1 and WordPress, the goal would be to install the plugin and configure some settings and you are up and running. The first step would be to replicate ssb-server in PHP and then have a WordPress plugin that would be a thin wrapper around running that process. Then each WordPress in the world could quickly be turned into what is known as a pub in the SSB ecosystem. If you are running a community like Post Status, you could then send out invite links to users and/or make a public open invite to your community.

The second hurdle is to develop a truly first class client app to read and interact with the SSB network. This is where the magic happens. Imagine a new app that anyone can load up into their browser or run natively that will connect them to this new network. This will put the power for people to own their own data, have privacy over their data, and interact with people the way they choose. A four freedoms might include:

  1. Freedom to Create and Manage Your Data and Feed
  2. Freedom to Create and Moderate a Community for any Purpose
  3. Freedom to Extend and Redistribute
  4. Freedom to Communicate Privately

If the project is successful, a future would support any open source client, which could be paid or free. It would also support a plugin ecosystem like WordPress where different applications could be run over the network, for instance in SSB people have implemented Git, and chess as applications that can be run on the SSB protocol. The vision is to create a global network that would be vivacious and put all of the power into the consumer’s hands rather than have the power be held by giant tech corporations.

Leveraging WordPress

WordPress also serves as a great public way to distribute content on the internet. There are potential synergies by choosing WordPress as a piggy backing jump off point. WordPress could be leveraged to have a public facing site that could also publish to the SSB network certain content. This also means that via the WordPress REST API, there could be integrations where certain posts you make to SSB would also could end up on your public WordPress site, creating a loop of possibilities between the public web and a private network running on SSB.

WordPress also has Gutenberg a great editor that could be used to post rich content to SSB or be directly embedded into clients.

Democratizing Publishing

If we really want to democratize publishing and commerce, I think WordPress needs to become a platform for how everyday people are using the web. A protocol like SSB would open up future possibilities and a client could be your homepage for the web; your portal to a new kind of web free of control of any one company more in line with the vision of the open web. I will be posting my progress on this blog and if you are interested in this project feel free to reach out to me in comments or on WordPress slack; username chopinbach.

Posted on by Edwin Cromley

Learning Docker – A WordPress set up

In my last post about Docker, we saw the basics of setting up images and running containers. Now we are going to build on this with another tool from Docker known as Docker Compose. We will use Docker Compose to set up a WordPress project. If you want to check out the code you can go to the GitHub Repository and play around yourself. WordPress is one of the main technologies I use on a daily basis for work and I thought it would be a good way to dig deeper into Docker.

Docker Compose

Docker Compose is a tool for Docker that let’s you automatically orchestrate containers. In our first foray into docker we manually started and ran each container from the command line. This works great in a small setup or for testing something out, but as soon as you have many containers that all talk to each other and you want a quick way to setup and tear down your project Docker Compose is the way to go. Docker Compose makes use of a docker-compose.yml file to organize the project. Here is our WP setup:

docker-compose.yml

version:                     '3.3'

services:
  db:
    image:                   mariadb:${MARIADB_VERSION:-10.2}
    environment:
      MYSQL_ROOT_PASSWORD:   somewordpress
      MYSQL_DATABASE:        wordpress
      MYSQL_USER:            wordpress
      MYSQL_PASSWORD:        wordpress
    volumes:
      - db_data:/var/lib/mysql
    restart:                 always
    networks:
      - back

  wordpress:
    depends_on:
      - db
    image:                   'wordpress:${WP_VERSION:-5.6.1}-php${PHP_VERSION:-7.4}-apache'
    ports:
      - "8000:80"
    restart:                 always
    hostname:                '${DOCKER_DEV_DOMAIN:-project.test}'
    volumes:
      - ./themes:/var/www/html/wp-content/themes:rw
      - ./plugins:/var/www/html/wp-content/plugins:rw
      - ./mu-plugins:/var/www/html/wp-content/mu-plugins:rw
    networks:
      - front
      - back
    environment:
      VIRTUAL_HOST:          '${DOCKER_DEV_DOMAIN:-project.test}'
      WORDPRESS_DB_HOST:     db:3306
      WORDPRESS_DB_USER:     wordpress
      WORDPRESS_DB_PASSWORD: wordpress
      WORDPRESS_DB_NAME:     wordpress

  proxy:
    image:                   jwilder/nginx-proxy:alpine
    restart:                 always
    ports:
      - '80:80'
    networks:
      front:
        aliases:
          - '${DOCKER_DEV_DOMAIN:-project.test}'
    volumes:
      - '/var/run/docker.sock:/tmp/docker.sock:ro'

networks:
  front:                     {}
  back:                      {}

volumes:
  db_data:                   {}

To spin up the WordPress set up you can run docker in detached mode. You can then navigate to localhost, or project.test (if you added it to your hosts file). You will see a fully operational WordPress setup.

docker-compose up -d

At the very top of the docker-compose.yml we see a version declaration. I am only familiar with Docker Compose 3, but there are more details on the differences on Docker’s website. The next area we see our declaration of services. Each of these services is essentially going to be a Docker container. Within each service we see various properties assigned to each container.

Image

Each container has an image specified here we have 3, mariadb:10.2, wordpress:5.6.1-php7.4-apache, and jwilder/nginx-proxy:alpine. These images all get pulled in from DockerHub, the official repository of Docker images. We have a db container running MariaDB, a wordpress container running WordPress & Apache, and lastly an Nginx server setup as a reverse proxy.

Environment

In our WordPress and DB containers we see an environment property where we are setting up our database. In a production environment you would not want to use these values and instead use real passwords and usernames that are secure. For a local setup, this works just fine.

Networks

We also see a property for each of our containers called networks. These are used by Docker to allow containers to interface with each other. In this example we have two simple networks, front and back. In our docker-compose.yml towards the bottom you will see this code:

networks:
  front:                     {}
  back:                      {}

This sets up the two Docker networks that our containers will communicate on. You can see that the db container only is on the back network and not the front. This is because we want the database to be on a network with other backend services. The wordpress container is on both the front and back network so that it can talk to the database, as well as talk to the Nginx reverse proxy. Lastly we see the Nginx proxy runs on the front with an alias set to whatever our domain for the project will be, making it so that this network is accessible by that domain name. By default this is set to project.test, as long as your hosts file points to localhost, you will be able to use that domain to access WordPress. Pretty neat.

Depends On

We have the wordpress container setup to depend on the db container. This means that the WordPress setup will not fully run until we have set up and have a running db container. This makes sense as WordPress cannot work without the SQL db backing it. depends_on allows us to have complex orchestration of containers and as more services get added there may be more dependencies that are needed.

Restart

If a container crashes, what should happen. This is the goal of the restart property which tells Docker what to do when a given container crashes. In this case all three containers are set to always restart.

Volumes

The volumes property is one of the most important. We will look at two different types of mounts. First we bind our local file system to the wordpress container filesystem for the themes, plugins, and mu-plugins directories:

volumes:
      - ./themes:/var/www/html/wp-content/themes:rw
      - ./plugins:/var/www/html/wp-content/plugins:rw
      - ./mu-plugins:/var/www/html/wp-content/mu-plugins:rw

The first part of volume binding is where we want to locally bind the folder, here it is the current directory themes folder. The next part of the binding is the folder on the actual container’s filesystem. In this case WordPress is installed at /var/www/html, making the themes folder available at /var/www/html/wp-content/themes. The last part of the binding is what type of settings are set for this binding. In this case each of the volumes for the wordpress container are set to Read Write. Allowing us to read and write to the files on our host machine’s filesystem.

Another type of volume we see is just a regular volume mount. Volumes are what Docker uses to persist data. In this case we are using a volume for our database, so that when we stop our containers and restart them the WordPress database will be what it was. Volumes unlike bind mounts are easier to share between containers and are great when you do not need to locally edit the files but still need persistence. Let’s look at two parts of our docker-compose.yml to see how to specify a volume.

volumes:
      - db_data:/var/lib/mysql

volumes:
  db_data:                   {}

The first property is a property on the db container. It is a volume named db_data being bound to the /var/lib/mysql folder on the db container’s filesystem. This is where MariaDB stores the database so we are essentially creating a volume to store all of our db data for the project.

The second volumes property is at the top level of the file and is simply declaring that there is a volume and its name is db_data the {} signifies we are just using the default properties for the volume.

Wrapping Up

I really like how quickly you can set up projects with Docker and how each part of the project can be quickly spun up and down without ever having to install anything on the host machine. If you want to run some PHP code you could spin up a Docker container with an image of PHP installed allowing you to run the code. Then when you are done simply stop and remove the container and nothing was installed directly to the host machine. With Docker Compose you can set up complex projects with different services set inside of containers that can all communicate with one another. Managing this locally can be cumbersome. Managing this with Docker Compose is a breeze. Next I am going to be digging deeper into Docker, and how to use it for actual production deployments instead of just as a local development tool.

Posted on by Edwin Cromley

Learning Docker – Starting with the basics

Docker is a tool I have been looking to incorporate into my development process for sometime. I have used it many times glossing over the basics and hacking my way through it, but I have not dug in to the finer details of how to operate docker until now. This guide assumes you already have Docker installed.

What is Docker?

Docker is an open-source project for automating the deployment of applications as portable, self-sufficient containers that can run on the cloud, on-premises, or locally. Docker is also a company that promotes and evolves this technology.

Docker allows you to run code inside a container that communicates directly with the host operating system through the Docker engine. Containers are like a computer with an image that is ready to run. The image is like a ready to go hard drive for a container. One of the biggest appeals of Docker is that it allows you to create and run consistent environments, meaning you will not run into situations where code works on someone’s machine but not yours.

Getting started with the basics

Docker is a big topic. We will be exploring it piece by piece and hopefully by the end a clearer understanding of what Docker is, and how to use it will emerge.

Dockerfile

Dockerfile is used to build a Docker image. It is a basic file that contains sequential instructions on how to build an image. The name must be capitalized for it to work. Let’s create a project directory with a Dockerfile in it with the following code:

FROM ubuntu

MAINTAINER edwin

RUN apt-get update

CMD ["echo", "Welcome to Docker"]

Now let’s breakdown each line.

FROM

Generally you use an official image on which you build a new Docker image. In this case ubuntu is our base image, which is called the parent image. You can find images hosted here on Docker Hub. If we want to create a base image, we use ‘FROM scratch’ in the Dockerfile. Any other instructions mentioned in the Dockerfile are going to modify the Docker image.

MAINTAINER

Who the maintainer of the image is.

ENV

ENV is a way to create key value pairs. There are two syntaxes one being a one liner.

ENV APP nginx
ENV PORT 80

The above is equivalent to the following:

ENV APP=nginx PORT=80

Then those values can be used in the rest of the Dockerfile.

RUN

RUN apt-get update

This line runs code on the shell and allows us to modify the docker image. Multiline instructions can be built using the \ character.

RUN apt-get update && apt-get install –y \
package1 \
package2 \
package3

CMD

The CMD directive defines what will be executed when a container is created using the Docker image. We should define only one CMD in a Dockerfile, however if we define multiple CMD instructions in a Dockerfile, only last CMD will get executed. If we specify any command while running the container, the specified command will take precedence and CMD instruction will not get executed. In this case it is a simple echo using the following message provided in the args.

Building the image

Now that we have gone over the basics of our example Dockerfile, let’s build the Docker image using above sample Dockerfile using below command:

docker build -t my_image .

This will build the image named my_image at our current working directory . where the Dockerfile should reside. You will see a whole bunch of output in your terminal, following the pulling of the base image, you will see the RUN command run and finally some more output around building the image. The -t flag is what allows us to tag this image with a name my_image.

Running the image on a container

Now we will run the image on a container. Remember the container is like a computer, and the image is like a special hard drive ready to go. We can run a container with the following command.

docker run --name mycontainer my_image

We should see the output Welcome to Docker on our terminal. Meaning the container started and ran our CMD. This is kind of like a Hello World example of Docker. We will explore more together in future posts!

Wrapping up

Docker uses containers to run images of predefined files, libraries, and code. Images can be built using a Dockerfile which is essentially a list of instructions for how to modify the image. Images can be built on top of parent images allowing ease of extension. Containers are like a computer that runs within the Docker engine to communicate with our host operating system.

Posted on by Edwin Cromley

Advent of Gutenberg – 7

For me personally, one of the main improvements in Gutenberg, compared to the classic WordPress editor, is the speed at which you can create content. A lot of this is due to the keyboard efficiency. There are a lot of hidden keyboard tools that we will look at, and some tips on how to quickly get content going in Gutenberg. I am on a Windows PC, so the quick keys mentioned will be different for MacOSX users. My daughter tried out the mobile experience as well for her website and thought it was relatively easy to use as well. I am very excited about getting more youth involved in using WordPress, which will be covered in future posts.

Back to the topic at hand.

Keyboard efficiency

Microsoft Word was in many ways the killer app of early PC days. It was most likely the culprit leading to the end of the typewriter. The typewriter in many ways has never died, as many are still stuck using the QWERTY keyboard layout, designed around the mechanical functionality of the typewriter, not the ease of human typing. Alternatives of keyboard layout have received minimal adoption. The speed at which we type can have a great impact. Time is the most valuable resource. Although most of us may be tied to a slower keyboard layout, we are definitely tied to a slower method of expressing thought. Gutenberg is a step in the right direction towards a more responsive interface for quickly getting our thoughts onto a canvas.

When I first started using Gutenberg I used all of the visual graphical elements to insert content. Now I have dug a bit deeper into the keyboard shortcuts, and do almost all of my posts entirely via the keyboard. It is an incredibly fluid experience, that will only improve from here. One of the biggest speed increases is using the slash commands (/). When a new block line is inserted you can access a list of blocks to insert by pressing /, similar to Slack.

Typing in forward slash on a new line opens the slash command palette.
Type slash on a new block line to open the command palette.

Once you type in the slash you will see a list of the most recently used blocks tailored to your needs. The pop up window will not be a complete list of every command available, and you will need to find those out for yourself, generally the name of a block is also the name of a command to insert a block. As you type after the slash command you will get an autocomplete functionality of the potential block command you are trying to do. So typing /media will bring me to creating the media and text below.

Typing after the slash command drives an autocomplete functionality.

Typing a command will start to trigger an autocomplete. Very nifty.

When dealing with images and other layout elements I noticed it was sometimes tricky to create a new block, and relying on hitting the “Enter”/”Return” key was not always feasible. Luckily there is a keyboard shortcut to add a block either above or below the currently focused block. I typically add one after by using “Ctrl + Alt + Y”. To add a block before you can do “Ctrl + Alt + T”. Knowing these two commands coupled with the slash command has greatly increased the speed at which I can get my thoughts out. No more, cut/copy paste. Very fluid.

Another cool thing is duplication, by using “Ctrl + Shift + D”.

Another cool thing is duplication, by using “Ctrl + Shift + D”.

Keyboard shortcuts

You might be wondering where the shortcuts are found, and it was not super apparent to me where most of these are found. The quickest way to view all shortcuts is to type “Shift + Alt + H”. It will look something like this:

Keyboard shortcuts menu accessible via Shift + Alt + H

How did we get here in the first place though? In the top toolbar there is a “Show more tools & options” menu, represented by three dots. Under the Tools section there is the Keyboard Shortcuts menu, with the keyboard shortcut displayed next to it.

From here we get an extensive overview of the keyboard shortcuts for the editor. These really open up a lot of keyboard efficiency, and will greatly reduce the amount of time we spend creating content. I am not aware if there was anything similar in the classic WordPress editor experience.

Speech to text

I can also see some cool improvements in the future surrounding a speech to text interface for Gutenberg. It would be cool to be able to say a command like, “Gutenberg, insert an image block”, which would trigger an image block to be inserted below the current block selection. Due to our new access to the underlying data model of content, new interfaces for creating content beyond keyboard and mouse will become more feasible. It’s all about the blocks.

Wrapping Up

One of the many gifts that Gutenberg is bring to the web is a new more efficient medium of representing our thoughts and ideas. I think the level of creativity we are going to see over the next years will profoundly shape the future of the web. As always stay tuned for the rest of the series and drop some comments for ideas of your own.

Posted on by Edwin Cromley

Advent of Gutenberg – 6

With the block concept coming into WordPress, we will see new opportunities to share content. Services like Gutenberg Cloud will most likely pop up, and of course the WordPress.org plugin repository will also be available. One thing about something like Gutenberg Cloud is that you could potentially just grab blocks directly from within the editor. Pretty neat.

Due to Drupal also adopting the Gutenberg editor, any CMS that implements blocks the WordPress way, will be able to leverage the content from both ecosystems. This is very exciting and interesting.

Block sharing

For the most part, I am excited about this new idea. Unfortunately, there are people with malicious intention, and I definitely fear that with an explosion of small reusable pieces, we will see an increase of security vulnerabilities around the sharing of blocks. More on that later.

The positives are very exciting. There is the potential to limit how frequently you will go to the plugins tab. It’s definitely also possible that themes themselves will go away as well. I think a lot of this will be due to block sharing. Let’s say I build a block that allows you to apply a snapchatesque filter to your images. Since this would most likely be implemented in JavaScript (not necessarily the filter itself), it will be easy to share to all of the different platforms that support the block model present in Gutenberg. That would be a specific block and if you wanted to build a lot of weird goofy dog face pictures on your site, it would be perfect.

There will be many niche blocks, but there will also be general purpose blocks. Much like the internal parts of WordPress itself, the nav menus, widgets, shortcodes, etc. are all reasons why we use WordPress. They allow us to create content quickly and with relatively minimal headache. Blocks will supplant the need for a lot of these core APIs. There has been worry over the reduced role of meta boxes, but most likely it will all succumb to a block based implementation, which will probably be better anyways.

Currently, which we haven’t touched on too much in Gutenberg is the concept of reusable blocks. This is where I am the most excited about block sharing.

Reusable blocks

Right below is the first reusable block I am using on my site.

There is a weird bug, currently where I get an extra list item. Oh well not too big of a deal. The main exciting part is that I can use this across all of my posts now. Click on any of the links to see the same list being used across all. We get to share content within our own WordPress install. Pretty cool. But with things like the REST API available, we can potentially even provide content that can be widely distributed as a “reusable block”. I think there is a lot of room for innovation around this. Essentially since the reusable block is also essentially just a custom post type.

Although there is a lot of potential for creativity and sharing, I am somewhat concerned about the potential negatives.

The downsides

There are a two main downsides that are apparent to me: security, and code sprawl.

Security

As mentioned above, security, and education around security is going to be critical. If we make it too easy to grab whatever block from wherever, we are most likely in big trouble. This isn’t necessarily anything new, as you could make the argument that the WordPress.org plugin repository can be a major attack vector as well. This is definitely a reasonably fair assessment. The only difference with blocks, is that they will most likely be more prolific than plugins.

Blocks in their nature are most likely going to be smaller than an entire plugin. Purely due to the reduced amount of code needing to be written for a block, I can see a lot more blocks being created. Blocks are also mainly written in JavaScript, which we have established as the most widely used language. A lot of people are going to be creating a lot of block. In this massive mess of blocks, it will definitely be easy for bad actors to sneak in. If it becomes very easy to just grab a block from some platform, how will users be alerted around the potential dangers ahead? We need to start coming up with good solutions now.

Code Sprawl

We are probably in an era of immense code sprawl already. It might get worse. We will most likely see a lot of blocks that are pretty much the same block. Does this benefit the users? Will we be able to encourage new coders if there are clear winners already established for certain blocks? I think the ability to share blocks will potentially cut down on the creation of the same blocks, but I can definitely see the flip side where it increases. Maybe this isn’t a bad thing at all either. I tend to think that it is, but maybe it really does not matter all that much.

With the rise of distributed computing platforms, I think it will matter, as we will want a way to condense the amount of information we are sharing amongst each other to only what is necessary. The efficiency gains in distributed computing won’t mean very much if everyone has a slightly different file that does 99.9% the same thing. We will need some sort of block unifier, that can take the contributions of many and turn it into one singular block.

Wrapping Up

Gutenberg really opens up a lot of unique opportunities that were not previously possible. I am excited for the future and to see what comes. We will definitely need to be aware of the potential pitfalls ahead and start implementing some safeguards or strategies against them.

Posted on by Edwin Cromley

Advent of Gutenberg – 5

We are going to look at the editor UI in greater detail now. From a technical perspective the user interface is written in JavaScript leveraging the React library. There has been great effort to make the editor experience extensible like the rest of WordPress, which we will look at more in the future. The tech choices for Gutenberg are also almost as important as the project itself.

Significance of JavaScript

JavaScript is the leading client side language of the web. JavaScript is also most likely the most widely used language as well. Popularity doesn’t necessarily have a positive connotation, but it does mean that there is a wide group of people fluent in JavaScript.

This familiarity enables a lot of things. It enables new developers to more easily and quickly get involved with WordPress, as the client side shifts more and more to JavaScript functionality. In the goal of democratizing publishing, it might make sense to make one of the widely used programming languages a flagship aspect of the platform. JavaScript usage is not anything new to WordPress, but Gutenberg definitely takes it to a new level.

The widespread use of JavaScript also is largely due to JavaScript being a key language of the web. JavaScript’s unique position over time has made it a language available across many platforms. It has become a very large compilation target as well, allowing cross platform codebases to slowly become a concrete thing. Tools like Electron allow for targeting Windows, MacOS, and Linux. Tools like React Native allow JavaScript to become this interop layer for targeting iOS and Android. The shared thread between these is you guess it; JavaScript! Since the web is a cross platform thing, we will probably see more and more web technologies creeping into the native space, or at least that is the current trend.

The direction WordPress is taking technically, will hopefully enable it to reach an even wider audience. This does not mean PHP is going anywhere. PHP is by some estimations still the most widely used server side language. Even if or when PHP is no longer a bedrock of web applications, it is unlikely the entirety of WordPress core will be replaced with another language. Most likely something else would have replaced WordPress. The block concept in a lot of ways though does detach WordPress from it’s underlying server implementation, so only the future will tell what happens.

Editor Areas

Enough jarbling around! The editor has three main areas currently. The header, sidebar, and content area. Each of these plays an important part to shaping our editing experience. Out of the box it is pretty straightforward to just start typing content into the editor like you normally would.

Header

The editor header toolbar is featured at the top of the screen.
The header is the area at the top of the editor.

The editor in the picture above is set into the Top Toolbar mode, meaning that we see the block controls in the top toolbar as opposed to hovering over each block, in a more Google Docs, Microsoft Word fashion. Remember Word in many ways was the killer app of computers for many decades.

Left side of header

The first tool we see in the header is the block inserter. The block inserter is very important, as that is the main way we add new blocks. There are keyboard shortcuts available, but if you are a more visual, the plus button will be your most widely used button.

Next to that we have redo and undo controls. The undo and redo feature keyboard shortcuts as well, but they can be visually accessed here in the header. From my experience, the undo and redo functionality is pretty darn good in Gutenberg. This is partially due to the tech choices made for the project, as well as the great team behind it.

The next two parts of the header are really interesting.

Content Structure

One of the coolest features is the content structure menu, where we get a quick overview of our document.

Content structure menu provides a quick overview of the current document.
This current document at time of inserting this image.

I love this feature. I can see how many words I have typed, headings used, paragraphs used and how many blocks. We also get a nifty document outline. Remember we now have a data model of our content, things like this are more at hand and easy to implement. I see very quickly that there is an error in my heading structure, which I have just now fixed. Would I have noticed that in the classic editor? I highly doubt I would have. It’s all about the blocks.

Next on the list is the block navigation.

Block Navigation

When we open the block navigation we get a pretty neat menu of all of the current blocks. We can see our currently selected block, and select the focus for another block in the menu, or just get an overview of the blocks.

block navigation menu is accessed via the header.
Block navigation can also feature child blocks.

We get child block views available as well scoped to this particular block.

On first glance the menu seems very humble, straightforward, and helpful. The reality is that as the future of WordPress evolves, this block navigation will most likely evolve into a central way of interacting within WordPress.

There is an entire scheduled post on this.

That wraps up the left part of the header. The left part of the header is more content focused. The section to the right is more control and document focused.

Right side of Header

We won’t dive into this too much now, but you can save your post, preview it or save a draft from this area. You can close the sidebar as well by clicking on the gear icon. The sidebar is referred to in this case as Settings. Next to that is another hidden gem the “Show more tools & options menu”. We will look in more depth on this in a follow up post.

The right side of the header toolbar focuses on settings.
This area focuses around publishing and settings.

Sidebar

The sidebar, or Settings area of the editor is another cool part. At the top of the sidebar we have tabs: Document and Block. This allows us to separate different controls into different areas within the sidebar. The document controls, are mainly the features we have grown accustomed to in WordPress like: Visibility, Permalink, Categories, Tags, Taxonomies, Featured Image, and excerpt.

The sidebar document tab houses familiar controls.

Some of the areas that were meta boxes below the post content are now present in this document tab. If you don’t see something you are used to seeing, it has most likely been snuck into the document tab.

As we saw in earlier posts, depending on what block is selected, we will also get contextual controls for each block presented in the sidebar. This is one of the primary areas ripe for exploring extensibility of the editor interface.

Content area

The content area is maybe the most important part, but honestly all three parts synergize together. One is not as complete without the others. We will not be talking about the content area for now. This is mainly to outline it is one of the three key parts to the new editor interface.

Wrapping Up

This should give you a more clear picture of Gutenberg, and outline some of the more hidden gems of the experience. The editor will evolve, but I have a sense that the general UI will be the foundation for years to come. As always, stay tuned for the next post and drop any comments in the comment box.

Posted on by Edwin Cromley

Advent of Gutenberg – 4

So far we have looked at some of the fundamental content types, text and media. In this post we are going to do a very quick overview of all of the blocks available by default in WordPress. We can see all of the blocks available via the block inserter. By default you can access this via the plus icon in the top left of the screen.

Gutenberg block inserter

Now for every block!

Heading Block!

Above is the heading block, this is a paragraph block.

List Block

  • The list block by default is a unordered list.
  • It supports sub items
    • Like this
    • And this
  • We can also use a list block to do ordered lists.
  1. Within the lists we still have our rich text controls
  2. So we can do bold text
  3. As well as italic and links!

Image Block

image of a pier with birds flying
This is an image block with a caption.

Code Block

/**
 * Sometimes, when dealing with the web, you might want to share a code 
 * snippet. Luckily we have a code block!
 */

function gutenbergIsGreat( opinion ) {
  return opinion;
}

share( gutenbergIsGreat( true ) );

The code block is not much different than the preformatted text block.

Preformatted Block

With preformatted text,
  We can do Poetry or other artsy versions of text.
  Text that depends on custom whitespace is a great fit for a

Preformatted text block.

Next up is our friendly twitter embed!

Verse Block

Verse block
Is pretty much the same as preformatted text.
It happens to use the main font family instead of a monospace font.

Embed Block

Choyce Design; check it out!

Quote Block

Check out the great post above. This is a quote block. Next is a gallery

-Edwin Cromley

Gallery Block

  • man on cliff
    We can caption individual pictures
  • waterfall
  • blue waters
  • mountains
    Oooooh
  • green field
    Ahhhhh
  • flowers and a dock

Cover Block

Cover image block here

Audio Block

File Block

Category Theory for ProgrammersDownload

Video Block

My Daughter’s first music video! Please subscribe she needs to get to 100 subscribers!

Pullquote Block

Pull quotes are extra special fancy!

-Anonymous 2018

Table Block

Number of Gutenberg Blocks Used so far35
Number of Gutenberg Advent posts written so far4

There is some really cool stuff I have in store for tables! Stay tuned for future posts!

HTML Block

Even though we see a form on the front end, when creating this block we simply add in HTML. Oila!

Button Block

Try out the Gutenberg editor right now!

Columns Block

We can get two columns as well. Columns allow us to nest blocks within other blocks. Pretty neat!

Content, layout is going to be a future focus for the Gutenberg editor, and columns block will most likely play an integral role in that.

Media & Content Block

flowers and a dock

Flowers

Separator Block

Spacer Block

On a project recently, whitespace was critical to the marketing team for whatever reason. Down the exact pixel. There was no real way to accommodate the client, with Gutenberg however, they could have added a spacer block and set the height. I am not excited about this, but it is still very cool to have, and illustrates the creativity that Gutenberg enables.

Above is a 60px spacer block.

Archives Block

Categories Block

Comments Block

Posts Block

Shortcode Block

Embed Blocks

There is an insane amount of embeds out of the box available to WordPress, and these all use the Embed Block as their base. This was already possible in the classic WordPress editor, but now it is just clear that we can post content from:

  • Youtube
  • Twitter
  • Instagram
  • Flickr
  • Soundcloud
  • Spotify
  • Flickr
  • Animoto
  • Funny Or Die
  • Hulu
  • TED
  • PollDaddy
  • Many more…
  • And most importantly WordPress
We Called it Gutenberg for a Reason

Phew! That’s a lot of blocks. It will be very important in the coming future to figure out how to create more baseline blocks, and compose new blocks out of existing blocks. We do not want to create some ridiculous proliferation of blocks overwhelming us with options. The embed block is maybe my favorite block so far. One block that allows us to embed any content from the web directly into our posts. Great stuff.

Wrapping up

Now that we see the various content that Gutenberg makes readily available out of the box, next up we will do a more thorough overview of the editor interface, from both a technology perspective and usability perspective. As always, stay tuned! Drop a comment to share your thoughts on Gutenberg so far.

Posted on by Edwin Cromley

Advent of Gutenberg – 3

Gutenberg logo

Text is a primary content type, but more and more the interactions taking place are going beyond text. Images, audio, video, and visualizations are all becoming more prevalent. Text is a great medium. In most cases, it is more accessible, and easy to produce. Text does have some barriers, like video, you have to actively engage it by observing it, where audio allows you to passively consume the content, while working on something else. Video in some ways can also be a much quicker way of learning how to do something and is a great instructional medium, as it combines both the audio and visual aspects together. WordPress already has great support for different web media types, and Gutenberg will help make these easier to access and interact with.

Media in WordPress

WordPress in its current form has a media library allowing you to manage the media on your site. We’ll come back to this. One of the best parts of WordPress is that it plays nice with other content platforms, allowing us to share information more easily.

Embedding content

The current editor also allows for embedding content from other sites. For example you might add a video to your page by pasting a YouTube link into your content, and clicking enter. This process is one step easier in Gutenberg as you just paste the link, and the editor understands you are trying to embed a video, and creates a new block for you.

The current way of adding a YouTube video.

WordPress was ahead of the game as far as embedding other content, but now it is even further ahead. It is just so easy to add embeds. You can also add embed blocks. They look something like this:

Image of embed block, features a URL input field, and submit button.
Embed block

We simply just enter the link, and if the link is embeddable, we magically get our embedded content. Super cool. So far in this series I have been embedding twitter links. Twitter can be crazy, but there is a lot of great stuff on it. Instead of expanding on tweets in the limited character set, where lots of bickering can happen, we can add commentary via a more thorough blog post. This was possible before in the classic editor, but something about this process is just so nice in Gutenberg.

Link to the gutenstats.blog site, outlining how widespread the usage of Gutenberg is.

Try out adding a tweet to one of your posts:

  1. Go to twitter
  2. Find the tweet you want to embed.
  3. In the top right you will see a downward arrow. Click there to expand the menu and “Copy link to Tweet”.
  4. In the editor on a new block line, paste the link. It will automatically start embedding the tweet. You can get to a new block line by hitting Enter, or the down arrow at the end of the current block you are typing in. ( More on this in the future. )
  5. See the tweet immediately appear in a stylish format.

Not much of a difference between the classic editor, but it is still a great experience. So far we have looked at embedding media and content from outside sources. Let’s look at a staple in WordPress; images.

Image handling in Gutenberg

Image block, featuring an upload button, media library button, or the option to insert via URL.
Image block in Gutenberg.

The above shows the default view of an image block, before we have selected an image. This view is known as a placeholder. Placeholders are great for a number of reasons. One of the most important is content layout. If we wanted to layout our content ahead of time, we could set a bunch of image blocks in various places, with the placeholders ready to go. We could then hand that off to our coworker in charge of selecting what media gets used. This is typically done in the current editor by using placeholder images, but with blocks, it will become more straightforward. It’s all about the blocks.

We have three options for adding an image: upload, media library, and “insert from URL”. Upload allows us to directly upload an image. I personally have had mixed results with this, and do not use it ever. Media Library will open up our media library and let us select the image to use.

The WordPress media library.

I have basically opened two tabs, one with my editor open, and one with the media library open. I simply just upload new images to the library, then switch to Gutenberg and pull in the new image. It’s all JavaScript powered, so no page refresh is necessary. It is actually a very quick workflow. Insert from URL seems to work well too, enjoy wapuu:

Wapuu

You can also drag and drop images into the editor. Currently, like the upload, my own experience has not been the best. Images start to upload but fail. The functionality has been tested rigorously, but for whatever reason my setup makes that extra hard. Don’t let little things like this take away from the Gutenberg experience. This is just the beginning. WordPress has a track record of fixing and accommodating all sorts of issues. WordPress has a strong people-centric focus.

All of the above is currently available in the classic editor. Gutenberg adds some new cool image features.

What’s new about images?

The cover image block!

cover image controls including color overlay settings

One of the coolest blocks is the cover image block, shown above. We get some text over a full cover image background. We can even set a fixed background effect for a nice visual touch. Like any block a lot of the extra options are found in the sidebar, when that block is selected. Always check out the sidebar to see what is available!

Right off the bat we see the fixed background control set to on. We also see the overlay controls. In the post we see a nice dark blue overlay, by default it is a black overlay. You can also just set the opacity to 100%, and get a full screen background with text.

Remember that each of these sidebar areas are available for developers to extend the functionality of each block type. Who knows what people will come up with.

Working with images in the new editor.

Let’s look a bit more in depth at what options there are to work with in Gutenberg. We will start with the block toolbar.

image block toolbar

Here you can see an image block selected with the toolbar above it. We currently have the center alignment set. You can left or right align an image which will float the content to the left or right, allowing the text to wrap around the image. The left and right alignment experience could use some tweaking, but it does work. We can quickly also change the image by accessing the Edit button, represented by a pencil. We also get sidebar controls.

Image block sidebar controls contain alt text attributes, image dimensions, link settings, and additional css.

We can edit the alt text, image dimensions, link setting, and additional CSS class from the sidebar by default. If you can imagine a setting that is missing from this menu, plugins will become available to fill these gaps, or you can make your own!

Remember this is the foundation. Unlike the classic editor, room for extending the functionality is possible, and available.

With the new block model, galleries become much more engaging. We will look at galleries more in the future.

What lies ahead for images?

There is a lot of future room for improvement around images. With the block concept available to us, we will potentially be able to make different crops for different screen sizes or have an image set that serves a different image to different audience segments. This area is a big struggle for web content in general, and I feel that Gutenberg puts WordPress in a unique position to solve this problem.

Responsive images will become easier to manage, currently it is very challenging. This will greatly improve the mobile experience, a major win for the web.

I can also see new image editing tools being built into WordPress. You could upload a raw image, do a custom crop, maybe apply some filters, do some various light editing. The possibilities are very open, and I think we will see a lot of these new experiences being provided via plugins. Maybe the best will get rolled into core itself. Google docs has great image editing tools for this purpose. With the foundation presented by Gutenberg, this might allow WordPress to even surpass that experience.

Wrapping up

The media library plays a critical role in the new editing experience, allowing us to quickly add in content. Below we see a list of some of the common media blocks available:

List of common content blocks.

Image, galleries, cover image, audio, file, and video are all media blocks ready to go out of the box. These were all possible previously in the classic editor, but now everything is a bit more discoverable. In the past I might have to go to an external source and read about WordPress to understand how to use it. This problem is not fully solved, or ever will be, but the new editor interface is more inviting to explore, and you can figure things quickly by just poking around.

Leave any comments or feedback on what you would like to hear about next in the series!