Yoast, the company behind the popular Yoast SEO plugin, launched its free block editor training course today. The course is available to anyone by signing up for Yoast Academy, which also includes multiple other free and paid courses. Users can learn everything from SEO and copy writing to basic WordPress skills. The Academy team’s latest course promises to get first-time users up to speed on using the block editor.
“At Yoast, we are huge fans of the block editor,” wrote Marieke van de Rakt, CEO of Yoast in the training course announcement. “Admittedly -not right from the start-, but we’re now block-editor fanboys and fangirls. That’s why we created an awesome free block editor course! We hope it will help everybody to use the block editor to the fullest!”
Currently, the course on block editor training has at least two or three hours of content to work through, depending on how quickly users digest the content. The course offers three major sections:
What is the block editor?
Using the block editor
Extras
Each of these is further broken down between one and three sub-sections. At the moment, there are seven lessons in total, which range between 7 and 49 minutes based on Yoast’s estimated time.
The courses are similar to taking a school class. The Academy team provides short videos that cover individual topics around the block editor. The team also provides a PDF version of the lesson for those who prefer text over video format. At the end of the lesson, users take a quiz and move on to the next lesson. A score of 80% or more is considered a passing grade.
The team keeps each lesson digestible enough to complete in a short bout. Even if watching the videos, the PDF version of the lessons, which are high quality and have loads of useful information with links to third-party resources, are recommended reading.
The team has provided a preview of the block editor course via YouTube:
Moving to the Block Editor and Building Training Courses
Joost de Valk, founder and CPO of Yoast, said the team would continue building on the training course over time as new features are added to the block editor. There are no plans to update it on a strict schedule, but the team wants to keep it current.
Yoast, as a company, focuses on SEO. Therefore, some of the advice offered through the course puts focus on creating content that is useful for people and friendly for search engines. One of the primary topics the course touches on is publishing “resources” and how this is made better by the block editor. “Resources are larger articles, evergreen content or in our SEO terminology ‘cornerstone content’: the stuff you want to rank within the search results,” said de Valk. “You can’t just throw some words on a page and expect to rank anymore. You’ll have to try a bit harder. Gutenberg makes that extremely easy.”
The Yoast team has been moving its massive site to the block editor over time. “The post types I deal with regularly are all written with the block editor, but we might have some areas of the site that aren’t there yet,” said de Valk. “It’s a rather large site, with e-commerce, training, jobs, etc. all built into one giant WordPress multi-site install, so that was a bit of an undertaking. We always try to dog-food stuff though, so we moved everything over quite quickly.”
Getting the 11 million users who are using Yoast’s products to make the switch is not quite as easy. Not everyone has embraced the block editor. “The usage of the block editor is definitely improving, but it’s not going as fast as we’d like to see,” said de Valk. “We honestly think a lot of people don’t understand the chances the block editor brings yet, one of the reasons for releasing this course and trying to help more people to start using it.”
The team’s latest SEO course had over 10,000 signups within a week. While that number is a drop in the bucket in comparison to their full user count, it is promising. With a similar turnout for the block editor training course, it may convert more users from the older classic editor.
Putting together full training courses is a large undertaking, but these are the types of resources the WordPress community needs moving forward. “It’s a lot of work,” said de Valk. “We have four people in our Academy team, a crew that records our videos, and our design team designs all the PDFs and slides within the videos. It’s a non-trivial investment, but we’re happy to make that if it helps make more people enthusiastic for the block editor.”
The new version of the Startup app is here and it comes with a few new features that we’ll explain in this post. The important features Startup include new integrations. Data form information can be sent to messengers like Telegram …
This is the March 2020 edition of "This Month in WordPress with CodeinWP." // Hey WordPress fans, welcome back to our monthly roundup of news from our community. You'll hear about lots of happenings; some you will enjoy and some you will probably not agree with. But that's life, isn't it?
Yesterday, the Gutenberg team released version 7.6 of the plugin. Most of the work in this update went toward the upcoming full-site editing feature. The team continues to pump out new dynamic, placeholder blocks for post data. The biggest user-facing feature was the addition of a rotating list of tips in the block inserter.
Version 7.5, released two weeks ago, was the last major release of the plugin that will have features to land in WordPress 5.4, which is currently scheduled for release on March 31. However, bug fixes from 7.6 were ported to the most recent WordPress 5.4 beta updates.
Version 7.6 does not include as many major feature additions as earlier releases. Aside from experimental work on full-site editing, it primarily includes bug fixes.
The announcement post boasts a considerable speed improvement in loading time and keypress events. In comparison to version 7.5, loading time was reduced to 7.7 seconds from 8.5 seconds and keypress event speed was reduced to 48.59 milliseconds from 55.45 milliseconds. These tests are run against a post of approximately 36,000 words and 1,000 blocks.
Rotating Tips In Block Inserter
In the past, the block inserter had a single tip at the bottom right that read, “While writing, you can press / to quickly insert new blocks.” It was a useful tip, but it was easy to ignore because it never changed. After seeing the same message a couple dozen times, it had become little better than wasted space.
Version 7.6 creates a rotating list of tips. Each time a user opens the inserter, a new tip appears. At the moment, the list only contains five messages but more are sure to come in the future.
There are open tickets to add contextual tips based on block search queries and block-specific tips. Both of those tickets could continue to help users learn the block system and provide a path for block creators to teach users how to use custom blocks.
Currently, the list of tips is static. However, it may be possible for plugin authors to extend it in the future. I’m already contemplating writing a plugin to replace the tips with quotes from Joss Whedon’s Firefly.
Full Steam Ahead with Full-Site Editing
Gutenberg 7.6 added four new dynamic, placeholder blocks related to post data: featured image, tags, comments count, and comments form. This brings the total to around 12 blocks for full-site editing, which is still a few dozen short of where the platform will need to be before the feature is ready. Most work thus far has gone toward building out blocks that handle post data. Eventually, the team will need to expand to other areas that will need block representation on the front end.
Theme authors looking to test out full-site editing should make sure to check out the block-based theme experiments repository, which continues to see regular updates.
Users can now set the heading level of the site title block. It can also be set to a paragraph. However, it does not include all of the design settings, such as text size or colors, that would come with a regular paragraph block. This is a good first step in recognizing the various ways the site title block will be used, but it will need to evolve into a much more robust block to allow users to do all the things they will eventually want to do with the site title.
At this point, it is hard to gauge what full-site editing will look like. Everything is experimental. It only covers the most basic use cases. I am still cautious about its potential. On the other hand, I am ready to skip ahead a year and see how it all turns out. Every plugin update brings us a step closer, but it is tough waiting to see what the bigger picture looks like as it comes together.
I was recently working on a modern take of the blogroll. The idea was to offer readers a selection of latest posts from those blogs in a magazine-style layout, instead of just popping a list of our favorite blogs in the sidebar.
The easy part was grabbing a list of posts with excerpts from our favorite RSS feeds. For that, we used a WordPress plugin, Feedzy lite, which can aggregate multiple feeds into a single time-ordered list — perfect for showcasing their latest offerings. The hard part was making it all look awesome.
The plugin’s default list UI is rather bland, so I wanted to style it to look like a newspaper or magazine website with a mixture of smaller and larger “featured content” panels.
This seems like an ideal case for CSS Grid! Create a grid layout for different layouts, say, one five-column layout and one three-column layout, then use media queries to switch between them at different break points. Right? But do we actually need those media queries — and all the hassle of identifying break points — when we can use grid’s auto-fit options to automatically create a fluid responsive grid for us?
The approach sounded tempting, but when I started introducing column-spanning elements, I ran into trouble with the grid overflowing on narrow screens. Media queries appeared to be the only solution. That is, until I found a workaround!
After looking at several tutorials on CSS Grid, I found that they largely fall into two camps:
Tutorials that show you how to create an interesting layout with spanned elements, but for a fixed number of columns.
Tutorials that explain how to make a responsive grid that resizes automatically, but with all of the grid items the same width (i.e. without any spanned columns).
I want to make the grid do both: create a fully responsive fluid layout that includes responsively resizing multi-column elements as well.
The beauty is that once you understand the limitations of responsive grids, and why and when column spans break grid responsiveness, it is possible to define a responsive magazine/news style layout in just a dozen lines of code plus one simple media query (or even with no media queries if you are willing to limit your span options).
Here’s a visual showing the RSS plugin right out of the box and what it’ll look like after we style it up.
This magazine-style grid layout is fully responsive with the colored featured panels adjusting dynamically as the number of columns change. The page displays around 50 posts, but the layout code is agnostic as to the number of items displayed. Ramp up the plugin to show 100 items and the layout stays interesting all the way down.
All of this is achieved using only CSS and with only a single media query to deal with a single column display on the narrowest of screens (i.e. smaller than 460px).
Incredibly, this layout only took 21 lines of CSS (excluding global content styling). However, to achieve such flexibility in such a few lines of code, I had to dig deep into the more obscure parts of some of CSS Grid and learn how to work around some of its inherent limitations.
The essential elements of the code that produce this layout is incredibly short and a testament to the awesomeness of CSS Grid:
The techniques in this article could be used equally well to style any dynamically generated content such as the output from a latest posts widget, archive pages or search results.
Creating a responsive grid
I have set up seventeen items displaying a variety of mock content — headlines, images and excerpts — which are all contained in a wrapper
The code that turns these items into a responsive grid is remarkably compact:
.archive {
/* Define the element as a grid container */
display: grid;
/* Auto-fit as many items on a row as possible without going under 180px */
grid-template-columns: repeat(auto-fit, minmax(180px, 1fr));
/* A little spacing between articles */
grid-gap: 1em;
}
Notice how the heights of the rows automatically adjust to accommodate the tallest content in the row. If you change the width of the Pen, you will see the items grow and shrink fluidly and the number of columns change from one to five, respectively.
The CSS Grid magic at play here is the auto-fit keyword that works hand-in-hand with the minmax() function that’s applied to grid-template-columns.
How it works
We could have achieved the five-column layout alone using this:
However, this would create five columns that grow and shrink with different screen widths, but always stay at five columns, resulting in them becoming ridiculously narrow on small screens. The first thought might be to create a bunch of media queries and redefine the grid with different numbers of columns. That would work fine, but with the auto-fit keyword, it is all done automatically.
For auto-fit to work the way we want, we need to use the minmax() function. This tells the browser how small the columns can be squeezed down to followed by the maximum width they can expand to. Any smaller, and it will automatically reduce the number of columns. Any larger, and the number of columns increases.
In this example, the browser will fit in as many columns as it can 180px wide. If there is space left over the columns will all grow equally by sharing the remaining space between them — that’s what the 1fr value is saying: make the columns equal fractions of the available width.
Drag the window out and as the available space increases the columns all grow equally to use up any additional space. The columns will keep growing until the available space allows for an additional 180px column, at which point a whole new column appears. Decrease the screen width, and the process reverses, perfectly adjusting the grid all the way down to a single column layout. Magic!
And you get all this responsiveness out of just one line of code. How cool is that?
Creating spans with “autoflow: dense”
So far, we have a responsive grid but all items the same width. For a news or magazine layout we need some content to be featured by spanning two or more columns or even, perhaps, to span all the columns.
To create multi-column spans we can add the column-span feature to the grid items we want to take up more space. For example, if we want the third item in our list to be two columns wide we can add:
.article:nth-child(3) {
grid-column: span 2;
}
However, once we start adding spans a number of problems can arise. First, gaps may appear in the grid because a wide item may may not fit on the row, so grid auto-fit pushes it onto the next line, leaving a gap where it would have been:
The easy fix is adding grid-auto-flow: dense to the grid element which tells the browser to fill in any gaps with other items, effectively making the narrower content flow around the wider items like this:
Note that the items are now out of order, with the fourth item coming before the third item, which is double the width. There is no way round this as far as I can tell, and it is one of the limitations you have to accept with CSS Grid.
There are several ways to indicate how many columns an item should span. The easiest is to apply grid-columns: span [n] to one of the items, where n is the number of columns the element will span. The third item in our layout has grid-column: span 2, which explains why it is double the width of other items that only span a single column.
Grid lines can be specified from left-to-right using positive values (e.g. 1, 2, 3) or negative values (e.g. -1, -2, -3) to go from right-to-left. These can be used to place items on the grid using the grid-column property like this:
So, this gives us additional ways to specify a spanned item. This is especially flexible as either the start or end value can be replaced with the span keyword. For example, the three-column blue box in the example above could be created by adding any of the following to the eighth grid item:
grid-column: 3 / 6
grid-column: -4 / -1
grid-column: 3 / span 3
grid-column: -4 / span 3
grid-column: span 3 / -1
Etc.
On a non-responsive (i.e. fixed columns) grid, these all produce the same effect (like the blue box above), however, if the grid is responsive and the number of columns changes, their differences start to become apparent. Certain column spans break the layout with an auto-flowing grid, making the two techniques appear incompatible. Fortunately, there are some solutions which allow us to combine the two successfully.
First, however, we need to understand the problem.
Overflow side-scrolling problems
Here are some featured areas created using the notation above:
It all looks good at full-width (five columns) but when resized to what should be two columns, the layout breaks like this:
As you can see, our grid has lost its responsiveness and, although the container has shrunk, the grid is trying to maintain all five columns. To do so, it has given up trying to keep equal-width columns, and the grid is breaking out of the right-hand side of its container, causing horizontal scrolling.
Why is this? The problem comes about because the browser is trying to honor the explicit grid lines we named. At this width, the auto-fit grid should implicitly be displaying two columns, but our grid line numbering system contradicts this by explicitly referring to the fifth grid line. This contradiction leads to the mess. To display our implicit two-column grid correctly, the only line numbers allowed are 1, 2 and 3 and -3, -2, -1, like this:
But if any of our grid items contains grid-column references that lie outside this, such as grid line number 4, 5 or 6 (or -4, -5 or -6), the browser is getting mixed messages. On the one hand, we have asked it to automatic create flexible columns (which should implicitly give us two columns at this screen width) but we have also explicitly referred to grid lines that don’t appear in a two-column grid. When there is a conflict between implicit (automatic) columns and an explicit number of columns, grid always defers to the explicit grid; hence the unwanted columns and horizontal overflow (which has also been aptly named CSS data loss). Just like using grid line numbers, spans can also create explicit columns. So, grid-column: span 3 (the eighth grid item in the demo) forces the grid to explicitly adopt at least three columns, whereas we want it, implicitly display two.
At this point it might seem like the only way forward is to use media queries to change the grid-column values at the width where our layout breaks — but not so fast! That’s what I assumed at first. But after thinking it though a bit more and playing around with various options, I found there are a limited set of workarounds that work all the way down to two columns, leaving just one media query to cover a single column layout for the narrowest screens.
The solutions
The trick, I realized, is to only specify spans using grid lines that appear in the narrowest grid you intend to display. That is a two-column grid in this case. (We will use a media query to cover the single column scenario for very narrow screens.) That means we can safely use grid lines 1, 2 and 3 (or -3, -2 and -1) without breaking the grid.
I initially thought that meant limiting myself to a maximum span of two columns, using combinations of the following:
grid column: span 2
grid-column: 1 /3
grid-column: -3 / -1
Which remains perfectly responsive right down to two columns:
Although this works, it is rather limiting from a design perspective, and not particularly exciting. I wanted to be able to create spans that would be three, four or even five columns wide on large screens. But how? My first thought was that I would have to resort to media queries (OMG old habits die hard!) but I was trying to get away from that approach and think differently about responsive design.
Taking another look at what we can do with just 1 to 3 and -3 to -1, I gradually realized that I could mix positive and negative line numbers for the grid column’s start and end values ,such as 1/-3 and 2/-2. At first glance, this does not seem very interesting. That changes when you realize where these lines are located as you resize the grid: these spanned elements change width with the screen size. This opened up a whole new set of possibilities for responsive column spans: items that will span different numbers of columns as the screen gets wider, without needing media queries.
The first example I discovered is grid-column: 1/-1.This makes the item act like a full-width banner, spanning from the first to the last column at all column numbers. it even works down to one column wide!
By using grid-column: 1/-2, a left-aligned nearly-full-width span could be created that would always leave a one column item to the right of it. When shrunk to two columns it would shrink responsively to a single column. Surprisingly, it even works when shrunk to a single column layout. (The reason seems to be that grid will not collapse an item to zero width, so it remains one column wide, as does grid-column: 1/1.) I assumed grid-column: 2/-1 would work similarly, but aligned with the right-hand edge, and for the most part it does, except at one column display when it causes overflow.
Next I tried 1/-3 which worked fine on wider screen, showing at least three columns, and smaller screens, showing one column. I thought it would do something weird on a two-column grid as the first grid line is the same as the grid line with -3. To my surprise, it still displays fine as a single-column item.
After a lot of playing around, I came up with eleven possible grid column values using grid line numbers from the two-column grid. Surprisingly, three of these work right down to single-column layouts. Seven more work down to two columns and would only need a single media query to deal with single column display.
Here is the full list:
As you can see, although this is a limited subset of every possible responsive span, there are actually a lot of possibilities.
2/-2 is interesting as it creates a centered span which works all the way down to one column!
3/-1 is least useful as it causes overflow even with two-columns.
3/-3 was a surprise.
By using a variety of grid-column values from this list, it is possible to create an interesting and fully responsive layout. Using a single media query for the narrowest single-column display, we have ten different grid-column span patterns to play with.
The single-column media query is generally straightforward as well. The one on this final demo reverts to using flexbox at smaller screens:
Here is the final grid which, as you can see, is fully responsive from one to five columns:
Using :nth-child() to repeat variable length displays
The last trick I used to get my code down to two dozen lines was the :nth-child(n) selector which I used to style multiple items in my grid. I wanted my span styling to apply to multiple items in my feed, so that the featured post boxes appeared regularly throughout the page. To start with I used a comma-separated selector list, like this:
But I soon found this cumbersome, especially as I had to repeat this list for each child element I wanted to style within each article — such as the title, links and so on. During prototyping, if I wanted to play around with the position of my spanned elements, I had to manually change the numbers in each of these lists, which was tedious and error-prone.
That’s when I realized that I could use a powerful feature :nth-child pseudo-selector instead of a simple integer as I had used in the list above. :nth-child(n) can also take an equation, such as :nth-child(2n+ 2), which will target every second child element.
Here is how I used the :nth-child([formula]) to create the blue full-width panels in my grid which appear at the very top of the page, and is repeated just over half way down:
The bit in the brackets (31n + 1 ) ensures that the 1st, 32nd, 63rd, etc. child is selected. The browser runs a loop starting with n=0 (in which case 31 * 0 + 1 = 1), then n=1 (31 * 1 + 1 = 32), then n=2 (31 * 2 + 1 = 63). In the last case, the browser realizes that there is no 63rd child item so it ignores that, stops looping, and applies the CSS to the 1st and 32nd children.
I do something similar for the purple boxes which alternate down the page from right-to-left:
The first selector is for the right-hand purple boxes. The 16n + 2 makes sure that the styling applies to every 16th grid item, starting with the second item.
The second selector targets the right-hand boxes. It uses the same spacing (16n) but with a different offset (10). As a result, these boxes appear regularly on the right-hand side for grid items 10, 26, 42, etc.
When it comes to the visual styling for these grid items and their contents, I used another trick to reduce repetition. For styles that both boxes share (such as the background-color, for example) a single selector can be used to target both:
This will target items 2, 10, 18, 26, 34, 42, 50, and so forth. In other words, it selects both the left- and right-hand featured boxes.
It works because 8n is exactly half of 16n, and because the offsets used in the two separate selectors have a difference of 8 (i.e. the difference between +10 and +2 is 8)
Final thoughts
Right now, CSS Grid can be used to create flexible responsive grids with minimal code, but this does come with some significant limitations on positioning elements without the retrograde step of using media queries.
It would be great to be able to specify spans that would not force overflow on smaller screens. At the moment, we effectively tell the browser, “Make a responsive grid, please,” which it does beautifully. But when we continue by saying, “Oh, and make this grid item span four columns,” it throws a hissy-fit on narrow screens, prioritizing the four-column span request rather than the responsive grid. It would be great to be able to tell grid to prioritize responsiveness over our span request. Something like this:
.article {
grid-column: span 3, autofit;
}
Another issue with responsive grids is the last row. As the screen width changes the last row will frequently not be filled. I spent a long time looking for a way to make the last grid item span (and hence fill) the remaining columns, but it seems you can’t do it in Grid right now. It would be nice if we could specify the item’s start position with a keyword like auto meaning, “Please leave the left-hand edge wherever it falls.” Like this:
.article {
grid-column: auto, -1;
}
…which would make the left-hand edge span to the end of the row.
In the video embedded below, Jen Simmons explains how to improve image loading by using width and height attributes. The issue is that there’s a lot of jank when an image is first loaded because an img will naturally have a height of 0 before the image asset has been successfully downloaded by the browser. Then it needs to repaint the page after that which pushes all the content around. I’ve definitely seen this problem a lot on big news websites.
Anyway, Jen is recommending that we should add height and width attributes to images like so:
This is because Firefox & Chrome will now take those values into consideration and remove all the jank before the image has loaded, even when you override those values in CSS with a fluid width and thus unknown height. That means content will always stay in the same position, even if the image hasn’t loaded yet. In the past, I’ve worked on a bunch of projects where I’ve placed images lower down the page simply because I want to prevent this sort of jank. I reckon this fixes that problem quite nicely.