Need a complete reference of action hooks and filters found in the Genesis Framework? Here ya go. Note this is intended as a reference, not a tutorial.
There has been an increase in developer resources around Gutenberg. We collected quite a few here. We’ll update along the way.
Development note: for the purposes of being able to remember gotchas when developing, I’ve added this development note with this bookmark.
While I’m not sure if this is a function of Gutenberg or not, I needed to manually input the information for the post name but not post excerpt, and I needed to manually input the site name. All of this applies when attempting to parse the information from the URL, which uses the “Parse This” portion of the Post Kinds plugin. This may mean something to look at specifically when migrating that plugin.
This is an up-to-date list of recommended books for learning React.
Author Mark Wilkinson Date 9th September 2018 Topics DevelopmentIntroduction
I have been using WordPress for many years – all the way back to version 2.0 in 2005 and I am now co-owner of a WordPress agency, here at Highrise Digital. A key breakthrough for me, in terms of being a WordPress develope…
Adding additional meta boxes, fields, and other information to WordPress is easy if you know the right hooks and the proper APIs to follow. But what if you want to add information to a WordPress taxonomy page?
For example, say you want to create a custom WordPress category edit page or, at the very …
A WordPress plugin that will enable you to register custom menu theme locations and easily swap menus on individual WordPress Pages or Posts.
Late in November, I published a personal opinion on the state of Gutenberg accessibility. Today, I’d like to give an introduction to Gutenberg from a screen reader user perspective.
I still have issues with this whole Gutenberg process, and my recent criticisms regarding leadership and project-level accessibility prioritization still hold.
But this quick guide to using Gutenberg with a screen reader gives me a place to start, and at least allows me to work with the thing, and even to think about experimenting with some things on a development version of this site.
So, thank you tons Marco, I probably owe you a keg at this point. 🙂
Google wants to speed up the web, and it has a plan:
For many, reading on the mobile web is a slow, clunky and frustrating experience – but it doesn’t have to be that way. The Accelerated Mobile Pages (AMP) Project is an open source initiative that embodies the vision that publishers can create mobile optimized content once and have it load instantly everywhere. Right off the bat, if you use the AMP project page to get a sense of how capable Google is of doing this right, you may become a little deflated. For starters, it fails on the accessibility front, lacking alt text on images, a lang attribute on the element, controls on its opening video, and sufficient text contrast. It also seems to demonstrate just why we want faster pages by itself weighing in at 44MB over 124 requests, taking nearly 6 seconds to load.
If a client insists on it, I’ll do my best to convince them otherwise, but if they continue to insist I’ll of course implement it because pick your battles (TM).
This has turned out to be a great resource for keeping up with the flaws of AMP though.
Since the landmark Domino’s case, I’ve been having some conversations about web accessibility with people who wouldn’t ordinarily take an interest. Some of these conversations have been productive; others have not. The following is a dramatization based on true events.
I’m still laughing. This is the funniest thing I’ve read when it comes to web accessibility in a very long time.