Ideally, the majority of WordPress users should be able to use Gutenberg on the day WordPress 5.0 is released. They'll hit "Update WordPress", navigate back to the editor, and continue publishing in Gutenberg with all of the functionality they expect in the Classic Editor.
But plugins! If any one of their active plugins are incompatible with Gutenberg, the WordPress user is likely to experience pain, misery, and bad fortune. Many WordPress installations have a dozen or more active plugins, so WordPress plugins are a significant risk vector for Gutenberg incompatibility.
Enter the Gutenberg Plugin Compatibility Database. The goal for this crowdsourcing tool is to identify whether or not WordPress.org plugins are compatible with Gutenberg. With this data set, we'll be able to:
Know the most likely causes of incompatibility.
Focus developer outreach on the highest impact problems.
Proactively educate WordPress users on whether or not their WordPress installation is ready for Gutenberg.
The only gotcha: we need lots and lots of person-hours for testing. If each plugin takes roughly 1 minute to test, we'll need ~75 person-hours to get through the remaining ~4500 plugins in the database.
Check out the project README.md for a more complete introduction to what's involved. This includes a definition for "Gutenberg-compatible", explanation for why only 5000 plugins are in the database, and other design decisions.
Do you or someone you know have access to lots of person-hours (e.g. WordCamp contributor day, hosting support team, etc.)? I'd love to chat! Feel free to leave a comment, ping me on WordPress.org Slack (I'm 'danielbachhuber'), or get in touch however most convenient.
Natural peanut butter stirring device. You know, to mix the peanut butter back into its oils. This device would need to be high torque with low speed, or it could even be mechanical with some design to increase mixing.
Fridge door alarm. Amazingly, our fridge doesn't beep when the door is left open. Many fridges do. This device would emit some noise (or send you a text, etc.) when the sensor detects an opening for >10 seconds.
USB hub with mounting hardware. All I want is to mount the hub to the back of my desk so I don't have to see it. Some hubs exist, but the price is quite high for what they are. There's an opportunity for something with screw holes in the ~$20 range.
All-in-one individual video conferencing unit. The existing options seem focused on adding a variety of peripherals to your conference room and TV. This setup would be for one person, and include video camera, screen, light source, and audio. A veritable magic box!
Brand. Brand is the key differentiating factor when it comes to influencing purchase decisions in a mature market. And Amazon's marketplace is a race to the bottom cesspool that's antithetical to customer loyalty.
Three of the four have relatively similar ratings.
All of them are within the same price point.
None of them are from a name brand I know I can trust.
Such indecision! I could spend 20 minutes scouring through the reviews, but who knows which are real and which are fake these days. Or, I could buy them all and return the ones I don't want. But packaging stuff back up and taking to UPS is a hassle.
For exactly this reason, I went to Best Buy yesterday (for the first time in decades), looked at video cameras, and bought a nice Canon for a cheaper price than it was listed on Amazon.
I like brands. Brands mean I can form trusting, long-term customer relationships with companies. The Amazon marketplace is overrun with knock-off products from generic drop shippers — bad and getting worse.
Chrome and Safari began forcing https for the .dev domain because someone apparently thought it was a good idea to register as a public TLD. Laravel Valet only produces self-signed SSL certificates though, so I want to keep my local installations served as http. Guess it's time to switch TLDs!
Oh, and don't try to use .local on a Mac because it conflicts with Bonjour local networking. I discovered this with 30 minutes of wasted effort. .test is the way to go.
valet domain test
Switch Valet to using the .test domain, which will also update dnsmasq accordingly. Don't try to edit dnsmasq configuration on your own — there are too many ways to go wrong.
wp package install wp-cli/find-command
Install wp-cli/find-command to find all WordPress installs in your Laravel project directory. It's convenient for running one WP-CLI command against all WordPress installs.
Run wp search-replace against all WordPress installs to replace instances of '.dev' with '.test'. ~/projects is my Valet project directory, and --all-tables ensures the procedure is run against all database tables.
Et voila! You've switched Laravel Valet from .dev to .test in three easy steps.