Yesterday I posted that I was contemplating migrating this site over to the Gutenberg world. There are a couple of reasons for this, and the most pressing one is that John, (whose greatest hits include experimenting with Gutenberg and Twentytwenty back in November and consequently providing the catalyst for some fixes that went into WordPress 5.3), and I are have decided to professionally pool resources. He’s been working on some smaller projects for me, and he likes kicking the tires on Gutenberg and doesn’t want to give it up for the classic editor.
OK, so we’re doing this. But for this site, it’s going to take some planning. First, there are several custom post types this site relies on, and it also heavily relies on the suite of plugins which enable WordPress sites to participate in the Indieweb movement. I’m definitely not giving that up, so this means that there are going to have to be some contributions to those plugins to make them suitable for Gutenberg use.
I’ve volunteered to be the lab rat for this, since I depend on it and I don’t want to give it up and go back to not-indieweb. I’ve decided to journal the entire process, starting from Day 0 until we get everything finished.
after doing some initial planning, (determining what custom post types are in play, plus post kinds), a separate development environment has been set up, which has Gutenberg installed. John’s using Twentytwenty on a smaller site he’s working on, so I think the development environment will have a Genesis theme for its base install. I’m also chatting back and forth in Indieweb Slack.
I figure if I’m doing this, may as well jump off the deep end. We have a target date of just after Labor Day for launch, and I’m going to do my best to stick to that. And I’m documenting the entire process, challenges and all. It should be interesting.
Noting Google’s continued support for Microformats as a metadata format.
I’ll take this opportunity to note that, while WordPress doesn’t yet natively support Microformats 2, it does support Microformats 1, and has to one extent or another since 2003.Amanda wearing a blue knit cap
#WCUS Every day is a good day for web standards.
I’m spending Contributor day working on some accessibility fixes to the Indieweb Publisher theme, which I will submit as a pull request when done because I need some easy wins if the WordPress accessibility fight is going to continue.
I’m also celebrating Blue Beanie Day early because every day is a good day for web standards.
It has been a while since I wrote out some thoughts on where the Indieweb is on WordPress. Sitting here, after hearing Matt Mullenweg gave the State of the Word at WordCamp US, and after I assisting Tantek Çelik in his talk on Taking Back the Web, which was one of the contributing factors to my being at WordCamp US.
Replied to
That's got me pondering about what it would take to get @t suggesting that @wordpressdotcom as the best turnkey solution for the #IndieWeb#WCUS
In short, WordPress.com would need to support at least two of the Indieweb building blocks:Webmention and full Microformats 2. See all the building blocks at the first link.
In order for WordPress.com to be a turnkey solution, it’ll need to support these things out of the box, and make it as simple as checking some boxes, or better yet, turn them all on for everybody by stealth.
part of this involves themes, and for the time being users either have to install a plugin like MF2 from the WordPress repository which will try to programmatically add Microformats 2 to a theme, or choose a theme that has full Microformats 2 support already baked in, or manually add them to a theme themselves.
I’m not saying WordPress.com couldn’t do this, (I’d love it if they did, and if they became a turnkey solution for people who want to join the Indieweb), but I don’t see that happening any time soon.
The Ninth Circuit Court of Appeals has handed down a groundbreaking decision today on the federal computer hacking law, the Computer Fraud and Abuse Act (CFAA). In HiQ Labs v. LinkedIn, the court held that scraping a public website is likely not a CFAA violation.
Under the new decision, violating the CFAA requires “circumvent[ing] a computer’s generally applicable rules regarding access permissions, such as username and password requirements,” that thus “demarcate[]” the information “as private using such an authorization system.” If the data is available to the general public, the court says, it’s not an unauthorized access to view it—even when the computer owner has sent a cease-and-desist letter to the visitor telling them not to visit the website.
This is a major case that will be of interest to a lot of people and a lot of companies. But it’s also pretty complicated and easy to misunderstand. This post will go through it carefully, trying to explain what it says and what it doesn’t say.
This decision is critical to maintaining an open web, at least in the United States.
Jamie Tanna
David Shanske