I’m doing some changes to this WordPress site and wanted to get out of the loop of FTPing a new version of my CSS to the live server and refreshing the browser. Rather than clone the site and setup a dev server, I wanted to host it on my local machine so the cycle of changing and testing would be faster and I could work online.
Nice people on Twitter recommended Local By Flywheel which was easy to install and get going (no dependancy rabbit hole) and which allows you to locally host multiple sites. It also has a really intuitive UI.
To clone my live site, I installed the BackUpWordPress plugin, told it to backup the MySQL database and the files (eg, the theme, plugins etc) and let it run. It exports a file that Local by Flywheel can easily injest – simply drag and drop it onto Local’s start screen. (There’s a handy video that shows how to do it.)
For some reason, although I use the excellent Make Paths Relative plugin, the link to my main stylesheet uses the absolute path, so I edited my local header.php (in Users ▸ brucelawson ▸ Local Sites ▸ brucelawsoncouk1558709320complete201905241-clone ▸ app ▸ public ▸ wp-content ▸ themes ▸ HTML5 ) to point to the local copy of the CSS:
link rel="stylesheet" href="http://brucelawson.local/wp-content/themes/HTML5/style.css" media="screen".
And that’s it – fire up Local, start the server, get coding!
If you’re having problems with the local wp-admin redirecting to your live site’s admin page, Flywheel engineers suggest:
- Go to the site in Local
- Go to Database » Adminer
- Go to the wp_XXXXX_options table (click the select button beside it in the sidebar)
- Make sure both the siteurl and home options are set to the appropriate local domain. If not, use the edit links to change them.
(Last Updated on 1 June 2019)
Domain-specific markup for fun and profit
It doesn’t come as a surprise to Dull Old Web Farts (DOWFs) like me to learn last month that Google gives a search boost to sites that use structured data (as well as rewarding sites for being performant and mobile-friendly). Google has brilliant heuristics for analysing the content of sites, but developers being explicit and marking up their content using subject-specific vocabularies means more robust results.
For the first time (to my knowledge), Google has published some numbers on how structured data affects business. The headlines:
- Jobrapido’s overall organic traffic grew by 115%, and they have seen a 270% increase in new user registrations from organic traffic
- After the launch of job posting structured data, Google organic traffic to ZipRecruiter job pages converted at a rate three times higher than organic traffic from other search engines. The Google organic conversion rate on job pages was also more than 4.5 times higher than it had been previously, and the bounce rate for Google visitors to job pages dropped by over 10%.
- In the month following implementation, Eventbrite saw roughly a 100-percent increase in the typical year-over-year growth of traffic from Google Search
- Traffic to all Rakuten Recipe pages from search engines soared 2.7 times, and the average session duration was now 1.5 times longer than before.
Impressive, indeed. So how do you do it? For this site, I chose a vocabulary from schema.org:
These vocabularies cover entities, relationships between entities and actions, and can easily be extended through a well-documented extension model. Over 10 million sites use Schema.org to markup their web pages and email messages. Many applications from Google, Microsoft, Pinterest, Yandex and others already use these vocabularies to power rich, extensible experiences.
Because this is a blog, I chose the BlogPosting schema, and I use the HTML5 microdata syntax. So each article is marked up like this:
<article itemscope itemtype="http://schema.org/BlogPosting">
<header>
<h2 itemprop="headline" id="post-11378">The HTML Treasure Hunt</h2>
<time itemprop="dateCreated pubdate datePublished"
datetime="2019-05-20">Monday 20 May 2019</time>
</header>
...
</article>
The values for the microdata attributes are specified in the schema vocabulary, except the pubdate value on itemprop which isn’t from schema.org, but is required by Apple for WatchOS because, well, Apple likes to be different.
And that’s basically it. All of this, of course, is taken care of by one WordPress template, so it’s automatic.
One thing puzzles me, however; Google documentation says that Google Search supports structured data in any of three formats: JSON-LD, RDFa and microdata formats, but notes “Google recommends using JSON-LD for structured data whenever possible”.
However, no reason is given for preferring JSON-LD except “Google can read JSON-LD data when it is dynamically injected into the page’s contents, such as by JavaScript code or embedded widgets in your content management system”. I guess this could be an advantage, but one of the other “features” of JSON-LD is, in my opinion, a bug:
The markup is not interleaved with the user-visible text
I strongly feel that metadata that is separated from the user-visible data associated with it highly susceptible to metadata partial copy-paste necrosis. User-visible text is also developer-visible text. When devs copy/ paste that, it’s very easy to forget to copy any associated metadata that’s not interleaved, leading to errors. (And Google will penalise errors: structured data will not show up in search results if “The structured data is not representative of the main content of the page, or is potentially misleading”.)
An example of metadata partial copy-paste necrosis can be seen in the commonly-recommended accessible form pattern:
<label for="my-input">Your name:</label>
<input id="my-input"/>
As Thomas Caspars wrote
I’ve contacted chums in Google to ask why JSON-LD is preferred, but had no reply. (I may go as far as trying to “reach out” next time.)
Andrew wrote
I’m pretty sure Google prefers JSON-LD over microdata because it’s easier for them to stealborrow the data for their own use in that format. When I was working on a screen-scraping project a few years ago, I found that to be the case. Since then, I’ve come to believe that schema.org is really about making it easier for the big guys to profit from data collection instead of helping site owners improve their SEO. But I’m probably just being a conspiracy theorist.
Speculation and conspiracy theories aside, until there’s a clear reason why I should use JSON-LD over interleaved microdata, I’m keeping it as it is.
Google replies
Updated 23 May: Dan Brickley, a Google employee who is Lord of Schema.org, wrote this thread on Twitter:
(Last Updated on 1 September 2019)
Here are my slides for The HTML Treasure Hunt, my keynote at the International JavaScript Conference last week. They probably don’t make much sense on their own, unfortunately, as I use slides as pointers for me to ramble about the subject, but a video is coming soon, and I’ll post it here.
Update! Here’s the video! Starts at 18:08.
Given that one of my themes was “write less JS and more HTML”, feedback was great! Attendees gave me 4.8 out of 5 for “Quality of the presentation” (against a conference average of 4.0) and 4.9 for “Speaker’s knowledge of the subject” (against an average of 4.5). Comments included:
great talk! reminding of the basics we often forget.
amazing way to start the second day of this conference. inspiring to say the least. great job Bruce
very entertaining and great message. excellent speaker
Thanks, that was a talk a lot of us needed.
Remarkable presentation. Thought provoking, backed with statistics. Well presented.
Very experienced and inspiring speaker. I would really like to incorporate this new ideas (for me) in my code
I think there’s a room full of people going to re-learn HTML after that inspiring talk!
If you’d like me to talk at your event, give training at your organisation, or help CTO your next development project, get in touch!
(Last Updated on 10 June 2019)
