1 of 47

Destination Full-Site Editing��All the Steps Monmouth University Took �to Prepare for the Future of WordPress

Steve Graboski (he/him)

Full-Stack Developer

Marketing and Communications

www.monmouth.edu

2 of 47

Rebuilding our WP Theme (2021-2022)

Cleaner use of fonts, easier to read.
Hero section: huge image, stand-out header, styled buttons
We’re focused on improvement, with an eye toward staying modern.

www.monmouth.edu

6/29/23

3 of 47

Interconnected Nav, prints via Full-Site Editor

Isolated Menus (2015)

Connected Menus (2022)

www.monmouth.edu

6/29/23

4 of 47

Site Editor (aka, Full-Site Editor)

Officially released with WordPress 5.9 on Jan. 25, 2022.
No-code template creation and editing.
We’re banking on reaping the rewards of Full-Site Editor. Other higher-education sites could find the same benefits.

www.monmouth.edu

6/29/23

5 of 47

Simple Edits, No Codebase Changes Required

www.monmouth.edu

6/29/23

6 of 47

Easily Change Static Parts of Template

www.monmouth.edu

6/29/23

7 of 47

You Can Create and Edit �Full Templates

Without changing any code you can

Create New Templates (Posts, Pages, Archives)
Edit Pre-Existing FSE Templates

Upshot: Save time, focus energy on bigger projects.

Quicker Edits
Approved workers won’t need to code to alter themes.

www.monmouth.edu

6/29/23

And this isn’t just page templates. It’s post templates. It’s archive templates. It’s even custom-post type templates. You can create all of these in the Full-Site Editor, and after you create them, and you can *edit* them in the Full-Site Editor. And it’s all saved via WordPress—no need to push to your repo for simple edits. What all this translates to, is a future where approved authors don’t need to consult developers for simple edits, be they on a page or in a template. I’m talking those authors you trust enough for that level of access—you can limit who gets to make those changes of course. If it’s just your web developers that will handle such changes, well, now they can finish their templating tasks more quickly, freeing up time for the tougher programming work only they can accomplish. �

8 of 47

What’s with These New Template Files?

How can static HTML be powerful enough for a theme?
Where’s “The Loop”?
Where does information about the post go (get_the_ID, get_the_title)?

www.monmouth.edu

6/29/23

So I’m sure this all sounds fantastic, right? I’m sure many developers thought so, checked out one of the example themes that supports the Full Site Editor, and came across the template files. Yes, there's still template files if you want them, no need to rely entirely on the Full-Site Editor. But rather than the old PHP standard, these new files are all HTML. But how? How can static HTML be powerful enough for a template? Where’s “The Loop”? Where’s all the usual functions for post information, like “get_the_ID” or “get_the_title”? Anyone accustomed to PHP themes no doubt had these questions and plenty of others on their mind when taking their first glance at this sort of code. But, if you took the steps our team did over the past few years, the answers came pretty quickly. One big answer, in fact:�

9 of 47

It’s all Blocks!

www.monmouth.edu

6/29/23

�

This line of code will be the content of a given page!

Equivalent of “the_content()” from classic PHP-based themes.

New blocks made specifically for theming! For example:

10 of 47

How We Accidentally Prepared for FSE

Step One: We dabbled in the Block Editor (2017)
Step Two: Began the transition to the Block Editor (Early 2019)
Step Three: Built blocks, moved whole site to new editor (2019-Now)
Step Four: Everything learned geared us up for FSE (2022-Now)

www.monmouth.edu

6/29/23

So you see, we accidentally prepared for Full-Site Editing. Sure, there was a bit more to learn, but we were only paces away from our goal. My hope is that anyone with the same goal can use our path as model, going through each of the four stages our team encountered. Step one is dabbling with the Block Editor, you know, getting used to how it works, making some content with it, seeing what this new editor can do. Then, step two: beginning the transition to block editor, but starting with a small section of your campus site–just to get used to the workflow of making posts and pages. Step three: as you transition the rest of the site to the Block Editor, you’re going to build custom blocks to handle any necessary tasks for which the Block Editor is not already equipped. And then, the final step—taking everything you’ve learned through all that work, and pushing yourself onward to the Full-Site Editing experience.

11 of 47

Show of hands! (Even if you’re at home!)

Raise your hand if:

Dabbled in the Block Editor?
Began to transition to the Block Editor?
Built their own blocks?

www.monmouth.edu

6/29/23

Successful Transition Requires All Three.
Don’t rush! Move forward in steps.

12 of 47

Why Prepare Now?

The Block Editor is WordPress’s future.

Classic Editor to lose support in 2024 (was 2021, 2022, now 2024… maybe).
At some point, it’s coming. Best time to start the transition is now!

No word on if/when Classic Themes will phase out, but it’s possible.
Best to stay current. Avoid deadline scares and reap the benefits of both the Block Editor and the Full-Site Editor!

www.monmouth.edu

6/29/23

But don’t take too long—in fact, you’re going to want to start this as soon as possible, especially if you’re one of the millions of developers still using Classic Editor, which, by the way, is set to lose support from WordPress in 2024! Maybe. They say “2024, or as long as is necessary,” and yeah, they shifted the year back a number of times. But it’s coming. It’s clear that at some point they intend to end support. Will the same happen for Classic Themes (that is, themes that don't support FSE)? No word on that yet, but it’s possible. The way I see it, we should always prepare for the possibility that old systems will whither in the face of their replacements. Why wait for deprecation when we can bite the bullet now and prepare? That way, we can avoid worrying about these potential deadlines, and start reaping the benefits of both the Block Editor and the Full-Site Editor.

13 of 47

2017: Gutenberg

June 2017: WordPress announces Gutenberg

WordPress began moving away from a text-focused writing experience toward a drag-and-drop editor.

Same time: Our team was switching to WordPress

We leaned toward WP in part to empower our editors to build pages with one of the best editing experiences.
This new drag-and-drop editor could be even more powerful, easy-to-use.

www.monmouth.edu

6/29/23

Let’s go back to where this all starts, Project Gutenberg. In June of 2017, WordPress announced its replacement for what we now know as the Classic Editor, moving away from a text-focused writing experience toward a drag-and-drop editor. Our team began to take notice. So, a confession: WordPress wasn’t our first content management system. But by this point, in 2017, we began making the switch. The editing experience stood out amongst our other reasons—simply put, the Classic Editor was ahead of the pack when it came to making posts without hassle. We wanted to empower all of our authors, in each of their departments, with the ease-of-use only WordPress could provide. This news of “drag-and-drop” sounded like an even simpler experience, possibly allowing authors throughout the campus to build more complex pages without having to contact us. We wanted to see if it could deliver.

14 of 47

Old Editor: Text Focused

Static toolbar for modifying text like in a word processor.

Bold and Italic, Alignment, Headings

Other buttons for typical features.

Media, Hyperlinks

Shortcodes for dynamic content

[tool attr=‘value’]Content[/tool]

www.monmouth.edu

6/29/23

15 of 47

Block Editor: Block-Focused

At first blush, it looks text-focused.

Only text entries appear:

Title
Paragraph

But hit the plus icon and…

www.monmouth.edu

6/29/23

16 of 47

Way More Options Than Before!

Text Blocks

Layout/Design Blocks

www.monmouth.edu

6/29/23

Media Blocks

17 of 47

Easy Customizations

Less windows to cycle through for simple changes like size, captions, and alt-text of media items.
Drag-and-drop interface makes rearranging elements quick and painless.

www.monmouth.edu

6/29/23

18 of 47

The First Step: Dabble

At this stage, it’s simply about becoming familiar with the Block Editor.
Consider all the blocks WordPress offers.

www.monmouth.edu

6/29/23

19 of 47

Oct 2017: Post-Dabble

Impressive, but needed more dev time.

As expected: still not truly part of official WordPress.

We eyed the official release of the editor.

WordPress 5.0, November 2018.

www.monmouth.edu

6/29/23

20 of 47

Step Two: Transition to Block Editor

Chart your Block-based future.

Take a section of your site, and restrict it to the block editor.
Consider the best places to start. What part of your website can you transition without having to delve too far into Block creation.

www.monmouth.edu

6/29/23

21 of 47

2019: Our University Magazine, Monmouth

Our magazine team puts stock in staying current.

Spring 2017, they redesigned their print look, asked us to develop a website to match.

What’s more current than the future? Feb 2019, we moved our first site to the block editor.

www.monmouth.edu

6/29/23

So what was our first site for Step 2? Monmouth, the magazine of Monmouth University. Now the Magazine team, they put a lot of stock in staying current. For their Spring 2017 issue, they re-designed the print version’s entire look, and asked us to make a WordPress website to match. So we thought, hey, what better place to start moving to the future of WordPress than a site run by folks looking to stay ahead of the curve. It helps too that it’s branding existed somewhat separate from the University at large—that meant that the University's Visual Guidelines wouldn't become an obstacle. That was practically a godsend with all the experimentation we performed at this part of our journey. All told, in February of 2019, the Magazine site became our first to fully support the Block Editor.

22 of 47

A Few Extra Blocks

Articles are mostly images and text. Didn’t need to code a ton of bespoke blocks.
The few we made were simple.

Hero (headlines, bylines, media)
Aside (text that floats right)
Question and Answer (for consistent style of each question and answer)

www.monmouth.edu

6/29/23

Now for some folks, their first site might not need any additional blocks, like I suggested. If your pages are simply a matter of displaying text and images, you’ll most likely be fine, though you may need to write some CSS to make sure the core WordPress blocks appear how you expect. It turns out our team had more on our plate—we did need to build a few blocks at this stage. Thankfully, the only blocks we had to build proved rather uncomplicated—mostly text based, with nothing that needed to interact with other parts of the website. Again, try to avoid transitioning a site where you’ll need to build blocks--this is just to get your websites Block Editor transition started. However, if there’s no site that you can gear toward blocks without creating your own, the best option is likely the site with the easiest blocks to make.

23 of 47

The Third Step: Building Blocks

WordPress offers plenty of blocks for you to craft your pages.
Inevitably, there will be something you want to include that just isn’t there.
Look over your entire site, and consider what blocks you’ll need to add to make the Classic Editor completely unnecessary.

www.monmouth.edu

6/29/23

24 of 47

Designing Blocks

Please note: This is a very brief overview.
Don’t stress the little details.
More than anything, consider the data—what information you’ll need to capture, rather than knowing exactly how you’ll grab it.

Design is king.

www.monmouth.edu

6/29/23

25 of 47

Consider a “Presentation” Block

What parts of the presentation will you present to the reader? Will there be different types of presentations that need unique looks? And what form will all this data take?

The presentation’s title (a string)
The presentation’s description (a string, multiple paragraphs)
Is it a featured presentation? (true or false, a boolean)
What else?

www.monmouth.edu

6/29/23

What goes into building a block? Well, unfortunately, we don’t have time to cover everything, but let’s focus on one big thing. So, exercise time. Let’s say your school will host conference, with presenters coming from different schools to showcase their work throughout the day. You’ll be making a site to summarize each of these presentations. Sure, you could just write it all out in a WordPress page, but you realize that you can get your work done more quickly if you make a block for rendering your presentation in a consistent format. So what data will you need? Well, a title, for one. That will clearly be a string, simple. Same for the description. Some of these presentations will be stand-outs, so we’ll need a a toggle for whether it’s featured. Alright, then, a Boolean. What else would we be trying to capture. Any takers? (take a few responses).

26 of 47

First Big Thing: Describe the Attributes

attributes: {

featured: {

type: ‘boolean’,

default: false

},

title: {

type: ‘string’,

default: ’’

}�}

When you configure your block, you’ll describe the format of your data.
Include in the block’s JavaScript and PHP files.

www.monmouth.edu

6/29/23

All of those attributes, you’ll want to write them down somewhere, because they’re going to be make up the first bits of code you'll create for your block. Every block starts with configuration, and in two required formats: one in JavaScript and one in PHP. In both files, you’ll supply the “attributes” property, and this is where you’re going to describe your data. In JS it’s an object, while in PHP it’s an associative array. In both, you’ll list each attribute by name, and describe it briefly. This includes the format of your data: could be a string, a Boolean, an array, an object; check the documentation for everything. The rest of your code will revolve around these attributes--how you'll allow the author to manipulate them, how WordPress should keep track of them. We don't have time to go over everything, but there's plenty of tutorials on how to do this--you can check the details of my presentation on the wpcampus site for all that.

27 of 47

Second Big Thing: Manipulating Attributes (JS)

The “edit” property (JSX)
Tells WordPress how we want the author to interact with the block.
We take “components” that WordPress supplies, and use them to manipulate the “attributes” we declared earlier.

<div>

<ToggleControl� label=“Is This Featured?”� checked={ attributes.featured }� onChange={ () => {� setAttributes( {� featured: !attributes.featured� } )� } }� />

</div>

www.monmouth.edu

6/29/23

After you describe the attributes, you’ll write out the JavaScript for manipulating the attributes. You’ll do this In the edit property of the block using a format known as JSX. Notice how it looks very similar to HTML. For good reason: just like HTML describes how a browser should render information, the JSX here is describing how the block will render in the editor. The difference is that we also include these uppercased tags, known as components. Some of these components allow us to give authors the ability to interact with the block and edit its attributes. This ToggleControl component here works great for Booleans—it will appear as a simple “on-and-off” switch, or “true-and-false” switch, really. WordPress supplies us ToggleControl, as well as other essential components for manipulating text, media, even color values. Again, and I can't stress this enough, check the documentation for everything!

28 of 47

Deciding How to Show your Block to Readers

Render with JavaScript

Laying out attribute data in JSX as though it were HTML.
But, you will need to update the post for every change.

Render with PHP.

Define a render function when registering the block with PHP.
Best way to include data from outside the Block Editor (REST API, or the global $post variable).
Should be your go-to for your Full-Site Editor custom blocks.

www.monmouth.edu

6/29/23

One other thing I want to go over quickly, is you’ll need to determine the best way to render your data on the front-end. You have two options. The first is the “save” property of the block’s JavaScript code. This will be the quickest method of coding out how to render your data, as you’re essentially just laying out your attribute data in JSX as though it were HTML. The downside is that you will need to update the post in the editor every time you need the block’s render to change. Say you have information that can change between post updates, like remote API data, the time of day, or information about the page as a whole. In those cases, you’ll want to render the block in PHP. In short: use JS to render when you can present your block attributes as they are. For anything more complicated, PHP is the way to go.

29 of 47

2019 to Now: The Block Editor Rules

With our feet wet, we were ready to move the entire University site to the Block Editor.
We made Block Editor the default across the various departments and divisions of Monmouth University.
Looked over entire site, and determined what blocks we would need.

Would it be a feature we use regularly that would otherwise involve extra CSS, JS?
Was there a shortcode for it?

Ex: [shortcode attr=val /]

www.monmouth.edu

6/29/23

Let's talk about what my team accomplished following this block-building thought process. In 2019, we began making the Block Editor the default editor. We pored over the entire website to figure out what blocks we needed to author pages exclusively with blocks. How did we determine which blocks to make? Well, a good candidate would be for displaying some complex feature we would use on the regular. We could code HTML directly into the block editor, but what a waste of time that would be, coding it all over and over again when we could just drag it onto the page as a block. Beyond that, we figured we should convert into blocks all of our active shortcodes–that’s these pieces of code in square bracket that WordPress will turn into a snazzy feature in the front-end. Great for adding dynamic content to a page, but unwieldy for folks without programming experience.

30 of 47

Accordion (Shortcode)

Was a shortcode, wonky to use.
Even with extra UI (Shortcake), hard to work with.

Extra pop-ups to go through.
Hard to re-arrange.

www.monmouth.edu

6/29/23

31 of 47

Accordion (Block)

Now, all you have to do is add the block and enter the content.
To re-arrange, just drag and drop like every other element.

www.monmouth.edu

6/29/23

32 of 47

Contact Block (More Advanced)

Grabs info from the University’s employee directory site.
Automatically displays the contact details: styled, linked, and with a headshot.
Similar shortcode, but had to know directory post’s ID.

www.monmouth.edu

6/29/23

33 of 47

Contact Block (More Advanced)

REST-API autocomplete.
Quicker for authoring pages.

No need to go to the directory site and find the post ID.

This one required a deeper understanding of Blocks.

All the better to prepare for FSE.

www.monmouth.edu

6/29/23

34 of 47

Step Four: Closing the FSE Gap

Preparing for Block Editor means preparing for the Full-Site Editor.
Include /templates/index.html in theme folder. It’s a block theme!
Full-Site Editor is a Block Editor

Blocks for query loop, post content, featured image, so on.

www.monmouth.edu

6/29/23

And once you've mastered block-building, you'll be prepared no doubt to start moving your theme to the Full-Site Editor. As a reminder, FSE revolves around blocks. Any theme that includes templates built with blocks is known as a "block theme". How do you make a block theme? Well, in the root of your theme folder, simply include a “templates” folder and add a blank file called “index.html”. That’s all there is to it! Of course, now comes all the work. With that file added, you’ll see the “Edit This Site” link in the admin bar of whatever page your looking at in the front end. You’ll also find a link in the Appearances menu of the admin dashboard. And when you follow that link, you’ll find a number of new blocks exclusive to the Full Site Editor which we call theme blocks: blocks exclusively for making block theme templates! This is where you’ll find the query loop block, the post content block, the featured image block, as well as any blocks you’ll build for your theme.

35 of 47

Theme Blocks in Action: Post Content Block

www.monmouth.edu

6/29/23

�

When you add a block to a template, it will look like this.
The new “post-content” block, with the layout’s type specified as “constrained”.
Great for “single” post/page/custom-post-type templates.

36 of 47

Archive Templates: Simpler than in PHP!

Query Loop

Post Template (for all queried)

Post Title
Post Excerpt

Query Pagination

Previous
Numbers
Next

</div>

www.monmouth.edu

6/29/23

Here’s another example: this is what part of your archive pages might look like as a block. Personally, I find it much simpler than making an archive template with PHP, where you have to set up the loop to display every post while also figuring out all the code necessary to make proper pagination. With Full-Site Editing, you really don’t have to think much here at all—it’s all a matter of placing the blocks in the right spot. All you’re seeing in that code example are a few blocks nested within each other. We have the overarching Query Loop block. Inside that we have two more blocks: one for handling how each post looks, and another for the pagination. And each of those just has a few additional blocks for telling WordPress where we want the post title and featured image, where we want to see the previous and next page buttons and the page numbers. And it’s even simpler if you do this in the Full-Site Editor—you just drag and drop everything.

37 of 47

Adding Template Parts in Block Templates

<!-- wp:template-part {

"slug":”preheader",

} /-->

Or, just drag and drop the “Template Part” block in the Full Site Editor.

www.monmouth.edu

7/2/23

<!-- wp:template-part {

"slug":”header",

} /-->

<!-- wp:template-part {

"slug":”footer",

} /-->

38 of 47

You Can Replace PHP Templates Bit-by-Bit

At Monmouth, we took a hybrid approach when developing our 2022 themes.
Deadlines, folks!
Point being: not all or nothing!

Just include an index.php file in your theme folder.

Notice: PHP and Block Templates

www.monmouth.edu

6/29/23

Now even with all this simplicity, replacing all of your PHP code with blocks might sound daunting. Thankfully, you don’t need to conquer every file right away. WordPress gives you the option to use PHP templates alongside block templates. This is what’s known as a Hybrid theme, and its the approach we used for a few of our sites. As the screenshot on this slide shows, the theme for our directory site still uses a PHP template for the archive page, which displays our staff and faculty listings. Why? Well, you know how deadlines are—we needed to get our 2022 theme done in 2022. Actually, before the fall semester started that year. Eventually, we will get to this file, but thankfully, we didn’t have to hold off the launch of our new design to get started with Full-Site Editing. It’s not all or nothing—you can convert your templates at whatever pace you find necessary.

39 of 47

Building Your Own Theme Blocks

If you can build Block Editor blocks, you can build FSE blocks.
Most of the time, you’ll want to render the block with PHP, not JavaScript.

PHP beats out JS for for displaying remote data and post content with theme blocks.

www.monmouth.edu

6/29/23

40 of 47

Alert Block (2022)

Checks remote system for any active alerts, displays them.
The draggable block just specifies where on the template the alerts bar should load.

www.monmouth.edu

6/29/23

41 of 47

SuperNav, Breadcrumb Blocks (2022)

Blocks tell WordPress where on the template they should load.

www.monmouth.edu

7/4/23

42 of 47

SuperNav in preheader.html (template part)

</div>

www.monmouth.edu

7/2/23

43 of 47

Requirements for Block Building

WordPress introduces several new concepts.

Consult the documentation
Fantastic Tutorials (fullsiteediting.com, kinsta.com, css-tricks.com)

Some knowledge of React is a must, but not a ton!

A surface-level understanding will get you pretty far!
The more knowledge you have, the further you can take your blocks!

www.monmouth.edu

6/29/23

44 of 47

Strong Recommendations (Don’t Fret)

Learn some ES6

Arrow functions, array methods (map, reduce, filter).

Use JSX

Makes coding out layouts much easier (more to come shortly)

Transpile with a Build System

Allows your ES6 code to run on as many browsers as possible.
We use Babel with Webpack. Gulp, Make, others can work, too.

www.monmouth.edu

6/29/23

45 of 47

JSX and ES6 Plain JS

wp.element.createElement(

InspectorControls,

{},

wp.element.createElement(

Panel,

{},

wp.element.createElement(

PanelBody,

{},

wp.element.createElement(

PanelRow,

{},

wp.element.createElement(

ToggleControl,

{)

)

) […]

www.monmouth.edu

6/29/23

46 of 47

A Free Plugin to Get Started: �Block Environment

Out of the box, includes support for ES6, JSX, Webpack and Babel.

Check the readme.md for setup and instructions.

Example blocks for both the Block Editor and the Full-Site Editor.

Plenty of comments describing how it all works.

www.monmouth.edu

6/29/23

47 of 47

Thank You!

Steve Graboski

Full-Stack Developer

Monmouth University

(https://www.monmouth.edu)

Linkedin | Github: @SJGraboski

Feedback: Link in Schedule

Block Environment (GitHub)

www.monmouth.edu

6/29/23

https://github.com/SJGraboski/block-environment-plugins