Amanda Rush

Introduction

Welcome to the WordPress Block Editor Tutorial Part Four of a Series!

This tutorial will cover many different concepts and topics when it comes to using the WordPress Block Editor. However, the tutorial will primarily focus on using the block editor in conjunction with a keyboard and screen reader.

This document is the first part of three (3) parts on the FSE (Full Site Editor). Details that were covered during the lecture/presentation such as the tour of the FSE will be presented in the documentation in the next part of the tutorial series. The decision was made so that certain features  can be properly tied together explaining the workflow. The audio lecture/presentation discusses basic concepts and principles that will become clearer as we progress through learning about the FSE.

Acknowledgements

Special thanks go to the following contributors:

  • Amanda Carson for co-authoring and proof reading parts of this tutorial.
  • David Edick for setting Up and hosting the Zoom conference for us to demonstrate the concepts detailed in this series as well as recording and editing the user zoom sessions.
  • Jason Castonguay for assisting in researching and testing of the Mac Keystrokes so this information can be Updated.

Topics and Concepts that will be covered:

  • What are blocks in WordPress
  • Tools used for tutorial
  • Anatomy of a Theme
    • What’s in a Name
    • style.css
    • functions.php
    • PHP template Parts
    • “Always-used” Templates
    • Files in the WordPress Hierarchy
    • Template Parts

What Are Blocks In WordPress?

Blocks are the components for adding content in the new WordPress editor. They are used to transform a single document into a collection of discrete elements, each of which has an explicit, easy-to-change structure. Block structure and settings are separate from the settings for the entire document, and block settings and Post/Page settings have their own distinct parts within the editor’s user interface.

Tools used for tutorial

  • WordPress 6.8using the twenty twenty-five (2025) theme
  • Browsers: Mozilla Firefox, Google Chrome, Safari and Microsoft Edge; all browsers kept up to date.
  • Screen readers: JAWS 2025, NVDA 2024 and Microsoft Narrator (Windows 11) as well as VoiceOver (MacOS Sequoia 15)

The Anatomy Of A Theme

What’s in a Name?

WordPress decides how to treat theme files based on their name. The first thing to notice is that every file in any theme directory has a special name. functions.php, style.css, index.php — none of these files are named by accident, and none of their names are arbitrary. WordPress decides how to treat theme files based on their name. It has a special treatment written out for functions.php, (lower-case and with (functions” spelled correctly), but none at all for functionz.php, (lower-case, but with “functionz” spelled with a Z instead of with an S). It goes without saying that should you spell “functions” with an upper-case F, which is allowed under Linux in order to distinguish the file with a capitalized name from the file without a capitalized name, WordPress would treat this file like any other that doesn’t conform to what it expects when it comes to naming conventions. So if you upload a set of instructions as functions.php, (spelled correctly), WordPress will interpret them; but if you upload those same instructions as functionz.php, (spelled incorrectly), WordPress will just ignore that file and its instructions completely.

style.css

style.css is the main source of your theme’s visual appearance. As such, it dictates everything from the choice of fonts and colors to whether or not your theme is responsive. It’s also where you’ll be doing the bulk of your work to make your site look the way you want. style.css is Also how you Register Your Theme, because it contains a comment section in its header, which is where theme data such as the theme name, author, parent theme if any, and so on, are registered.

WordPress reads these comments to get its information about your theme. So the little comment block at the top of your theme’s main style sheet, and nothing fancier or more technical, is what causes your theme to appear in your site’s list of themes in Appearance > Themes in the WordPress admin area.

functions.php

functions.php is where you add custom functionality to your theme. This could be an awful lot, including:

  • Adding CSS stylesheets (including style.css itself) and JavaScript files
  • Registering nav menu areas and widget areas
  • Defining which custom image sizes you want to be available on your site
  • Filtering your page content

functions.php “talks to” the rest of WordPress primarily through WordPress hooks (also called action and filter hooks), which let it add functionality at just the right places.

PHP Template Files

A WordPress site’s template files determine the site’s markup. Without them, there’s literally nothing on the page. The main bulk of a theme’s files are its PHP template files. If functions.php is a theme’s brain, and style.css is its clothes, template files are its body.

Together, these files determine the site’s markup: the actual HTML that the browser displays when it renders your site. They do this in two ways: 1. HTMLFirst. Template files do print HTML directly to the browser, just like a regular .html file would. Anything not inside isn’t PHP: it’s just plain HTML that goes straight onto the page. So if a theme’s header.php includes a bit of HTML such as the following: <body class="site-body"> That’s exactly what a browser will see on every WordPress webpage that includes header.php, which should be all of them. 2. PHPTemplate files really work their magic using PHP, which is interpreted as HTML along with programmatic instructions by your server’s running copy of php.

As a simple example, our same header.php file could instead contain the following code: <body class="<?php echo ‘site-body’; ?>"> The added PHP simply echoes (prints) the string “site-body” right onto the page.

So the server did extra PHP processing on its end, but the browser still sees the same old HTML. As you can imagine, a theme’s template files are utterly crucial: without them, there’s quite literally nothing on the page.

“Always-Used” Templates

Some template files are used on every webpage on a site. The major examples are header.php and footer.php. These files are used so often that WordPress has special functions for including them in other template files: get_header() and get_footer(). Called this way, without parameters, those functions simply grab header.php and footer.php, and drop them in where the function was called. Why are these files used everywhere? It’s because most sites want a consistent header and footer across different pages. If one page has your company’s logo and primary nav menu, it’s a good bet that you’ll want other pages to do the same. The same is true for your footer at the bottom of the page.

As a note, sidebar.php is also sort of this kind of file, although it’s a hold-over from when WordPress was blogging software and when sites had sidebars. Like header and footer, sidebar has its own function as well, get_sidebar().

Files in the WordPress Template Hierarchy

The real excitement happens in files like index.php, single.php, and page.php. These files dictate what markup will appear for different kinds of post data. For example:

  • If the webpage being requested involves a Page-type post (for example, your About page), WordPress will likely use page.php to build that webpage.
  • If the requested webpage is an individual Post-type post (for example, you’re viewing a particular blog post), WordPress will likely use single.php to build it.
  • If you’re looking through all the Post-type posts you wrote in 2014, WordPress will likely use archive.php to build that webpage.

These “in-the-template-hierarchy” template files all share something very important: They’re build around The Loop, one of the absolute core principles of WordPress development which we’ll discuss in a later lecture.

Template Parts

Let’s say there’s a section of both index.php and page.php that’s exactly the same. Should we repeat that code in both those files?Actually, DRY (“Don’t Repeat Yourself!”), is a battle cry for good programmers. Repetition causes all kinds of problems. What if you want to change something about the repeated section? Now you’ve got to change it in two places. What if you forget to change it in one place, or make a mistake in one file but not another? Now your code is out-of-sync and your site is buggy. (Now: what if you repeat the same code twenty times? You’ve got to repeat every change you make times twenty, and hope that you “caught them all.”) Template parts take a likely-to-be-repeated part of a template file, and move them out into a new file. This way, both index.php and page.php can both simply refer to the same template part, rather than individually writing it twice; and if you want to change that section you only change it once.

These are the things to really understand about a WordPress theme. Even a way-too-big ThemeForest theme will be built around this core skeleton, so understand how these pieces interlock and you’ll have a lot of power to understand WordPress themes, and by extension, your WordPress-powered site.

Replied to

This is an incredibly glib response to the issue of why people or products haven’t jumped on the Gutenberg bandwagon.

I’m sure I’ve already raised several objections to this strawman explanation but I’ll continue to do so every time it gets raised by Matt.

Speaking for myself, I’ve been using computers since before there were true screen readers. I’ve adapted with every single change to that piece of software alone, to say nothing of operating system changes and application changes and even WordPress changes since 2005. I promise you, this is not about being afraid of change. And I seriously doubt “afraid of change” is the case for even half of the rest who haaven’t aadopted Gutenberg.

As of June 9, 2021, Gutenberg is still an efficiency and useability nightmare, despite the technical accessibility improvements that have happened over the last two years or so. I see this every day with my own usage, John’s own usage, (and he’s got just as much or even slightly more experience with computer usage than I do), with clients who use assistive technology of any kind, and even with clients without any disability who don’t spend all their time living in their WordPress dashboards.

I have a single client who truly does enjoy Gutenberg, and that’s because their only familiarity with using WordPress was through visual composer.

I’m not saying, and I’ve never said, that WordPress should never change. I get that WordPress needs to adapt, I get that it needs to modernize, and I have no problem with any of this.

What I have a problem with is that adaptation being poorly thought through and poorly managed, the complete disregard for tons of completely avoidable problems having been created during almost the entire development cycle of Gutenberg, the prioritization of dreams at the expense of technical realities, (see that whole discussion on GitHub about how Gutenberg is never going to be Microsoft Word on the web no matter how much that’s wanted by product designers), and then the pretense that none of this has happened and that everything is just peachy and it’s all about people just being afraid to change.

If this were really about being afraid of change or unwillingness to evolve, I would have quit using computers cerca 1995 around the time of quite literally a seismic shift in the way screen readers work under the hood and the way they present information to users. Or that other seismic shift in 1998/9 or so when MSAA became a thing. Or that other one in 2006 when Web 2.0 became a thing.

But I didn’t. And that should tell you something.

Read #AccessiBe to Release New Search Engine Designed for Internet Accessibility by Joshua Hawkins

“For too many people, using popular search engines is a frustrating and fruitless experience,” Shir Ekerling, CEO of accessiBe, said in the press release.
“With the understanding of the web accessibility gap, the decision to put our resources into accessFind was an easy one. With accessFind, internet users
with disabilities finally have a search engine that provides them with results of readily accessible websites, working to bridge the existing digital divide.”

$100 says this attempt at a new ghetto for people with disabilities is merely an aggregator for sites loading their script.

Another $100 says that, if they actually approached any people with disabilities to inquire about any problems we might have with using search engines, the Chief Vision Officer is the only person with a disability they asked.

I suppose it’s easy to say you’ll make the web accessible by 2025 when you can just build yourself a safe space and then pretend it’s the web. But AccessiBe’s self-constructed safe space isn’t the web any more than Facebook is.

I’ll stick with the open web, thanks.

Replied to Blind people, advocates slam company claiming to make websites ADA compliant (www-nbcnews-com.cdn.ampproject.org)

In an email, Ekerling said people who criticize the company online are largely stirred by “thought leaders” who are rallying blind people in a “huge campaign”
against the company with few specific critiques.
“Almost no one gives any specifics to actual websites that really don’t work for them,” Ekerling wrote in an email. “This is because they don’t really
test us, nor have really used us. At most, they went on a website out of anger and didn’t even try to understand.”

No really, I promise, we’re not just “stirred by thought leaders”. I can state with complete confidence that neither Karl Groves nor Adrian Roselli have gotten in touch with me in any manner to offer beers in exchange for negative comments about AccessiBe. 😛 And really, that’s all it would take, that is, if we must mix in some stirring by thought leaders.

I could be this easily bribed to slam AccessiBe because the product doesn’t solve even half the problems it claims to solve, hell will freeze over before they manage to make the entire web accessible, and Ekerling, at least, is a lying liar who lies.

There. I said it. Publicly. The AccessiBe hashtag on Twitter is overflowing with examples of websites that don’t work, complete with videos of users experiencing them not working. Ekerling knows this. So we’re well past ignorance and well into lying territory.

Reposted