Abilities API for Humans  🔗 **Source:** [Abilities API for Humans](https://www.youtube.com/watch?v=vSbdtpAhROs#transcript) > [!note]+ Document Notes > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > tags: [wordpress-abilities-api, plugin-architecture, developer-tools, woocommerce, wordcamp-us] > author: Nick McLoughlin (SkyVerge) > source: WordCamp US (YouTube) > reference: https://www.youtube.com/watch?v=vSbdtpAhROs > date created: 2026-08-19 > # 🏷️ Title: Abilities API for Humans > ## 🧭 Table of Contents > - [📝 Summary](#-summary) > - [📖 Main Content](#-main-content) > - [🗒️ Notes](#️-notes) > - [📚 References](#-references) > - [🗣️ Paraphrase](#️-paraphrase) > - [📰 Newsletter](#-newsletter) > - [✅ Action Items](#-action-items) > - [🧪 Hypotheses](#-hypotheses) > - [📊 Methodology](#-methodology) > - [❓ Questions](#-questions) > - [🔮 Future Research](#-future-research) > - [💡 Implications](#-implications) > - [🧠 Learning Styles Assessment](#-learning-styles-assessment) > - [📊 Accessibility Assessment](#-accessibility-assessment) > - [🌍 DEIB Assessment](#-deib-assessment) > - [✅ Logical Validity](#-logical-validity) > - [🛡️ DARVO Analysis](#-darvo-analysis) > - [🎯 Conclusion](#-conclusion) > ### 🔗 References > - [WordPress 6.9 Abilities API](https://make.wordpress.org/core/) — the platform feature this talk is built on > - Baton (Nick McLoughlin's workflow-orchestrator plugin) — referenced as "just on GitHub," no direct URL given in-talk > - WooCommerce Order Query and Add Order Note abilities — referenced by name, no URL given > - SkyVerge Print Invoices & Packing Lists extension — referenced by name, no URL given > ## 📝 Summary > - **What happened.** Nick McLoughlin (SkyVerge; self-appointed Abilities API evangelist for the WordPress Core AI team) gave a WordCamp US talk arguing the Abilities API shipped in WordPress 6.9 is not primarily an "AI gateway" but a general-purpose, discoverable capability registry for the whole platform. He walked through the spec (name, input schema, output schema, callback), the problems it solves in current plugin architecture (monolithic plugins, "class drilling," duplicated per-interface logic), proposed a "new plugin architecture" pattern (write core logic once as an ability, expose thin adapters to REST/CLI/admin/MCP/LLM), showed a slide of companies/plugins already adopting it, and closed with a live demo of Baton, a prototype workflow-orchestrator plugin that chains WooCommerce and SkyVerge abilities (query orders → filter → add order note; query orders → filter → send pick-list email) without writing any custom integration code between the plugins. > - **Why it matters.** WordPress plugins today routinely duplicate business logic across REST endpoints, CLI commands, and admin UI, and third-party integrations require reverse-engineering undocumented public methods or brittle class chains. A standardized, self-describing, namespaced ability registry — enforced by JSON Schema input/output validation and a required permissions callback — turns "read the code to guess the contract" into "call `WP get abilities()` and inspect the schema." That is a structural, ecosystem-level change to how WordPress plugins interoperate, not just a convenience for AI agents. > - **Key stakeholders.** WordPress Core AI team (drove initial development); plugin/theme developers (SkyVerge, Leaky Paywall, Ultimate Multi-Site were named or asked questions from the audience); WooCommerce (supplies read and write abilities Baton consumes); Abilities API core maintainers (David, audience member, confirmed a discoverability-filtering feature request is already landed); WordPress.org Plugin Directory / Meta team (a Trac ticket exists, per McLoughlin, for surfacing a plugin's registered abilities on its .org listing page, though it doesn't exist yet); end users/merchants (ultimate beneficiaries of cross-plugin workflows like Baton's WooCommerce automation). > - **Risks and tradeoffs.** (1) Adoption dependency — the ecosystem-level payoff (McLoughlin's "seamless interoperability") only materializes if plugins and themes actually register abilities; today the barrier is explicitly named as adoption, not the API's readiness. (2) Security is layered, not centralized — McLoughlin was direct in Q&A that the abilities layer only guarantees a per-ability permissions callback; REST-specific auth, nonces, and other surface-specific security controls still have to be implemented separately at each access layer, which is a common point of confusion he flagged. (3) Namespace collision risk — abilities are namespaced per plugin, so accidental duplicate registration is unlikely, but McLoughlin acknowledged a plugin could deliberately target another's namespace ("namespace jacking"), which he characterized as hostile-actor territory rather than a solved problem. (4) Discoverability gaps at the ecosystem level — no way today to see what abilities a plugin registers before installing it (a Trac ticket exists but is unshipped), so evaluating "does this plugin have the abilities I need" still requires installing it first. (5) The demo itself failed once live (invalid JSON from a stray comma) and once more the second demo transaction was blocked by WooCommerce's own "store not live" safeguard — presented candidly as evidence the tooling enforces its own schema validation rather than as an embarrassment. > - **Bottom line.** The Abilities API is positioned as WordPress's new default "plugin atom" — the standardized, inspectable core that every access surface (REST, CLI, admin UI, MCP, LLM) should be built as a thin wrapper around, rather than one more parallel integration layer bolted onto AI use cases specifically. McLoughlin's practical advice to builders: start by turning your plugin's custom-post-type CRUD and any bespoke cross-service workflows (e.g., calling an external API with order data) into abilities, because the same core functions can then power your REST API, CLI, and any future MCP/agent surface without rewriting logic per surface. > ## 📖 Main Content > - **Core definition.** The Abilities API provides "a central registry on every WordPress site where the site's capabilities are registered" — discoverable and interoperable, sourced from plugins, themes, snippets, or core itself, all in one standard place. WordPress 6.9 shipped it. Each ability has exactly four parts: a name, an input schema, an output schema, and a callback function. > - **Not fundamentally new — a standardization layer.** McLoughlin is explicit that abilities don't introduce new capability; WordPress developers already call each other's functions and APIs constantly. What's new is a shared, ecosystem-wide agreement on what "well-formed" exposure looks like — the same category of standardization hooks already provide for data manipulation and side effects, abilities now provide for calling functions. > - **Problems in the pre-abilities status quo.** He frames current plugins as effectively "monolithic": each one embeds unique architectural decisions a newcomer has to reverse-engineer. Symptoms named specifically: repeated core logic rewritten per interface (REST, CLI, admin); "class drilling" through long singleton chains just to reach one public method; and ambiguous public function signatures (is this parameter an object or an ID? does this return an array or a string?) that force developers to read source rather than a contract. > - **The fix, mechanically.** Consumption is three pieces: `WP get abilities()` (discover all), `WP get ability()` (retrieve one), and an execution method on each ability whose inputs/outputs are validated against its JSON Schema automatically, plus a required permissions callback that runs on every execution. McLoughlin calls this "a cable management standard for our spaghetti code." > - **The "new plugin architecture" pattern.** His central prescriptive claim: abilities should become the nucleus of a plugin's business logic, with REST, CLI, admin, MCP, and LLM access all built as thin adapters on top of that same core — "write once, expose to REST/CLI/admin/MCP." He explicitly warns against treating abilities as "just another REST API" or "just another CLI" bolted on f [applause] Thank you. Thank you. Yeah, thanks for making it out after the lunch break. I'm sure we're all a little stiff. I'm going to do some stretches actually to get warmed up if you want to join me. Uh this is going to be abilities API for humans and we're all humans with bodies who benefit whose brains benefit from some blood flow. So I do encourage uh you know taking some taking a second here to move around. Um yeah, so I am Nick Mclofflin. Thank you for the intro. I'll keep this part short since you already heard most of it. Uh support engineer, product manager, general manager at Sky Verge. Uh I've been doing Devril and self-appointed abilities API evangelist for the core AI team. Uh also running a little uh thing called plug-in jam. Uh which is like a hackathon for WordPress builders. Um so that's me. Uh that's my kid Oliver. He's back at home uh building a tent in the living room with his mom right now, which is so much fun. Just got to talk to them. Uh so real quick show of hands. Uh how many folks in the room have heard of the abilities API before coming to this talk? I'm impressed that there are some hands down. I love that. That's actually fun that you like are showing up to learn. That's great. But most most folks so I I think if you've heard of the abilities API at all, it's probably in the context of AI in WordPress. Uh and that makes sense. Uh that's first of all a valid use case and then also historically what drove the development of the abilities API by the core AI team. But the abilities API has a whole bunch more to offer to it than just AI integration. Uh and I want to talk about those pieces so that we can understand this as a new fundamental in the WordPress platform and not just a gateway to an LLM. Um so we'll start out just with definitions, get straight into it. Uh what even is the abilities API? So for folks that didn't have your hands up before, this is your time to get on boarded. Uh the abilities API, and I'll try not to just read too many slides here, but this one's worth just getting the words in. Uh the abilities API provides a central registry on every WordPress site where the site's capabilities are registered, right? Um so it's a central registry that's discoverable and interoperable, uh where you can register capabilities. So these capabilities are the abilities that the API is named after. Uh and they can come from any source in the WordPress context. So that's plugins, themes, random code snippets that you forgot you had on your site. Uh or even like the core platform itself. Um so anywhere in WordPress all in one standard central discoverable registry. Uh, so that came out in WordPress 6.9, brought us the abilities API. Uh, and I just wanted to get a quick overview. I'll throw some code at you a couple times in this talk. Uh, and it's, you know, maybe legible, maybe not. I will have all of the slides available after this if you want to actually dig into some of the code outlines here. Um, but real high level, the abilities API or and ability itself is just has four things. There's the name, the input and output schemas, what comes into it, what goes out of it. Uh, and then a a callback function like what actually gets done uh and and where that reference is internally inside of WordPress. Uh, so once you have that defined, any other code running in WordPress can find, inspect, and use your ability. Um, so you might be thinking if you've heard a little bit about this or been building on WordPress for a little while. Like none of this is fundamentally new. We're already interacting with each other's code. We're already writing functions that have inputs and outputs. Like there's some new jargon about this apparently, but like this is the same thing I'm already doing, right? Um, and that's fundamentally correct. Like I I I want this to sound as normal as possible. Uh, that we're already interacting with each other's code. we're already interacting with APIs from core or functionality from core um through a whole bunch of different methods. Uh and the abilities API doesn't define anything I think inherently new that hasn't existed fundamentally somewhere in WordPress before. Uh but there's some problems to solve still in like how we do this currently. Um so I want to I come from like a plugins background so I'm going to use plugins as in most of my examples. Uh, but like I said before, this kind of applies to any code that's running in WordPress. So, if you're writing random snippets in your functions PHP or if you're developing a theme or what have you, um, the same things apply, any sort of package that's running code in WordPress, but we'll use plugins as an example. Uh, today I I use the term monolith here. Uh, that a plug-in is monolithic. It's maybe more of an adjective than a technical term because you can structure it how you want. But the point that I'm getting at here is that inside of that plug-in itself, you have a custom set of architectural and software design decisions that were made by the author that as an a newcomer to the codebase, you have to kind of wrap your head around to understand what's going on inside of it. Um, and so that's today, right? You have this kind of you get delivered a plugin and who knows if it if they're doing it the same way that you would have done it, if they're doing it the same way as the other plugins on your site. um it's it's really unknown. It's kind of stands on its own in its own unique implementation of a lot of things. Um within an individual plugin, you might have repeated functionality where you're writing the same core logic of what needs to be done in your plug-in across different interfaces. You might need a REST API interface and then uh add a CLI because you want more developers to be using your tool or retool the admin interface. And then these pieces of functionality can sometimes get caught up in those inter like integration layers and it gets really messy. Um so even if you do try to centralize that functionality um which is you know the direction that I'm going to try to recommend you go today uh if you do try to centralize that functionality prior to abilities API um you might be exposing like some core public methods. you have some class where you define a public method that just then can be consumed by all these integration layers. Um, even if you were doing that previously, other developers still have to dig through your code to find where are those functions declared, how are they declared, what what syntax do they take, what um, you know, what inputs and outputs are they returning, that sort of thing, right? They have you have to dig through that yourself to understand what the code is doing. Um so a few examples of that and I think I talked through most of these already. Uh first one being uh public function you know that order parameter is that an order object or is it just an ID? Uh do I get data that comes back of out of it as an object or is it an array or just a string? Uh the the second example of class drilling is maybe more niche for folks who are big on like singleton patterns. But uh the joke I have there is how many singleton instances does it take to get to the center of a public method. Uh you you can end up with these really long chain calls just to get to one thing that you're trying to do that's supposed to be a public method but takes you know eight classes to get there. Um, and then the per interface patterns, like I said, uh, without a standardized way to define the core functionality, those access layers can often get bloated with the logic that you're repeating across your plug-in when really they should just all be doing the same thing. Uh, so what does abilities API do about this? Uh the abilities API gives us the opportunity to standardize these patterns of exposure and interoperability uh between our packages, plugins, themes, core, wherever. Um and also within the individual package itself, within your plug-in, you can standardize how that's structured and and and meet the standard that's set at the ecosystem level. And then you can carry out that same functionality across multiple contexts, your REST API, your CLI, what have you. Um, you know, command pallet as that's growing in adoption, right? And now you don't have to rethink the logic of how that works. You can build that thin layer of integration just for that surface. Um, so I think of this as like a a cable management standard for our spaghetti code um of how we can kind of bring these things into one place uh and and make a little bit less of a mess while we're at it. Um so we get a standardized way to declare abilities uh which are then recorded in a centralized discoverable registry uh and then can be written once and consumed anywhere within the WordPress context with just like a minimal access layer based on where you need to consume that functionality. Uh so a quick example or I guess this is a revisit from before now that we have some of that info preloaded. Uh just go over this quickly. Registering an ability is really straightforward. It's what's it called? What goes into it? What comes out of it? Uh and then you know the the reference to the function that actually carries out the the ability the the activity. Um the usage layer uh as far as like consuming an ability. And I think the main thing I want you to see on this slide even if you can't read the code from where you're seated is how few of those lines are syntax highlighted as actual code. It's a very lightweight, easy to use, quick tolearn API. There's not a lot of heavy lifting that you have to do up front to understand how to consume an ability. There's really like three pieces to it. You got WP get abilities to discover the abilities themselves. WP get ability singular to retrieve just the one that you want. And then each of those abilities has an execution method on it whose inputs and outputs are defined uh in their by their JSON schema and discoverable programmatically. Also includes its own validation. Uh and you can have permissions checks as well. I won't talk too much about those today, but it's part of the spec built in is that you have permissions checks that run every time the ability is executed. So again, I mentioned this before. Uh, we're not doing fundamentally new things here. Um, there's there's maybe some new concepts or names depending on like your development background, but I don't want this to sound too foreign. Uh, as WordPress developers, we're already doing a lot of this. An ability is essentially a well-formed public function call. Uh, and the difference now is that we have a standard model in the ecosystem of for what well-formed means. um that we can all build toward together. It also it fits into the the pantheon of other ways that we have to interact with each other's code already. Um so just like hooks give us a standard way to manipulate data or run side effects and kind of the event-based system, abilities give us a standard agreed upon interface to call each other's functions. Um, so I want to zoom out a little bit and look at like the really high level like okay that's like within a package but then where does this go? What's the what's the big picture here? Um, fundamentally having a standard for discoverable functionality sets us up for a future of I'll say seamless interoperability across the ecosystem. So big words but your plug-in works with my plugin, your theme works with every plugin. your your your in your SAS integration can discover all of the plug-in activity on a site. Um because it's all standardized and interoperable, there's no more digging through each other's code bases. Uh we have explicit contracts for how we integrate with one another's code, knowing what comes in, what comes out. Uh and changes to those contracts are obviously breaking changes. This is an explicit integration layer that you're exposing. Uh unlike a public method that you might have buried away in a class that you forgot about. Uh you are inherently when you expose an ability, you are inherently making that consumable externally. Uh and so if you make changes to that or to flip it around on the maybe more painful side that we've all experienced, if the other plugins that I'm building an integration for make changes to that, they have to tell me about it. They can't just change the API under under me. I have a discoverable programmatic way to figure out what are they accepting as input, what are they returning as output. Um, and then of course like at the at the ecosystem level, this delivers a new frontier I think of interoperability in what WordPress users can expect from the functionality on their site. I think a lot of the functionality on our sites right now, I think WordPress sites tend to be uh, you know, very spoiled for functionality. uh you know, you think of the 40 plug-in site, you think of, uh, you know, a WordPress build that just has a lot available in it, but how well does that work together? How easy is it to string those pieces together and to get them to actually do what we need to do for the user, for the visitor on my site? Um, I think that that interoperability layer of I have installed all these pieces and now they come together to do what I want uh is actually a a new standard expectation for WordPress because of abilities. Um, so that's that's kind of like the the highlevel ecosystem view. Uh, the the the standard at that level is set and the barrier to us achieving that is adoption, right? um is we need plugins, we need themes to be shipping abilities so that we can all consume them. Um so anybody building a plugin in the room, a theme in the room, developers in the room, get building. This is it. It's there. Um yeah, so that's that's maybe more future tense, right? Still, we do need to aspire to that. I wanted to set that in front of us. Um but a big part of what I want to cover today is actually what this means for the features that you're building now, the plugin that you're working on on the side. How does that impact what we're how does the abilities API impact what we're building today? And I think that this change in how we build things in WordPress uh that or that's why I want to get this message out now is because it changes how we build things in WordPress today. And yes, that levels up to these ecosystem benefits, but I want to talk about the core kind of solitary benefit as well. If you're maybe indie dev mindset of I'm just going to be building this thing myself. I think there's benefit in this for you as well. So the main unlock I'll say here for developers is uh what I'm here now labeling the new plug-in architecture. Um and I I think the 'the' is important there because it's the the idea here is that this is the standard. It's not a random new way that somebody else should be doing it. It's established as the standard way of doing this. that abilities live as the core of your sort of uh plug-in atom model uh the core nucleus of your business logic that then gets exposed to all of these other surfaces. Um I think this is mostly like a a mental unlock. There is like I said a lightweight API of registering and consuming abilities but largely it's a a mental shift in how we construct our code. Um, a lot of the folks that I see talking about abilities API or trying to process and wrestle with how to use it kind of put it on this outer ring of, well, it's another REST API. It's another CLI. Uh, it just happens to be made for AI for some reason, but also needs an extra MCP layer on top of that. Um, and that should be your clue that like we're not adding layers to add layers to add layers. This is the new standard that then you can point the rest of those to. So from that core bundle of abilities, you can expose the functionality that you write once to the REST API, the CLI, the admin, yes, MCP, yes, LLMs through that as well. Uh I'm going to also this I I think this uh this image is maybe a little too clean, so I did want to get into like scare you with some uh some lines going everywhere of what a real site looks like, right? This is this brings the humans back into it. So I I presented this this talk before and had just that really clean image and I think it didn't quite get across like the full workflow of what's going on here. So I I won't go into every piece on this, but just to get an idea of what's going on here, right? On a standard WordPress site, we have visitors coming to the site that are looking at the pages of the site. The pages on that site might consume abilities to provide some dynamic data on the front end or something. Um, alternatively, maybe you have an app that has a headless REST API integration. That same REST API integration or that REST API integration can be based on the same core of ability functionality that you've defined in your plug-in. Um, that's and that is shared that standard is shared throughout the entire site. [snorts] Um, yeah. So I I mostly wanted to call this out or point this out to bring back in the humans that are involved here, the developers, the users, um, and even like the users who might be using an agent or developers who might be use like running through CI. Uh, these this are the access layers, but they're all kind of drawing from this same core. So, one question you might have uh is like, hey, this all sounds great, but is anybody actually building on this today, or is this some like pie in the sky theoretical like, you know, every time somebody introduces a standard, it's now the next now we have 13 standards, right? Like that's [laughter] that's the problem here. Um, but that's not what we're seeing. Uh, we're seeing adoption. We're seeing folks building on Abilities API already. Uh, this is a list of people that I've talked to. I'll say that like I I don't I'm not sponsored by any of these people. I didn't they didn't pay me to put them on this slide. This is people I've talked to, people I've interacted with or that somebody has told me about that they're building on abilities already. Um and if you do want to see your name on this slide next time or find out more about these, I'm going to be at the core AI prompt bar the rest of today, most of tomorrow. Come talk to me. Let me know. I'm This is one of my main things here is wanting to know what people are doing with this. Um so do reach out. Um but the main reason I wanted to to get this slide up right now is to showcase that this is already happening and you know a lot of the biggest players in the space as far as plugins are concerned are already building their their plugins and their their products. Some of these are are just like SAS products. Um they're already building in this way. They're already using this new platform primitive of the abilities API. So, with that, I'm going to try the fun conference thing of diving into a demo. Um, I've built a plugin that will uh to showcase like direct consumption of abilities. Um, I think maybe a few slides back, if I can just dip back here, right? Uh, there's a lot of layers around abilities kind of in the intended model of how they're used. Um, but what I want to showcase today is how to uh what what we can what power we can harness from that. Uh, so I built a little admin UI to achieve that for us. And I'm going to try my best to figure out how to pull that up right now. So tech folks, stick with me on this one. Let's see. And then I should be able to Oh, you got me. Thank you. Incredible. Do my very secure login flow here that Chrome is going to warn me about. No, never. Um, okay. So, this is Baton. This is my little like prototype plugin. Uh I'll just show you real quickly like what I have on the site. Uh I've got Baton itself and then a few Woo Commerce extensions. Uh and then of course Woo. Um I operate in the Woo Commerce space so I'm familiar with what's going on there is the easiest for me to demo. A couple of these are our plugins from Sky Verge that we've already shipped abilities API integrations with. But what I want to show today is how to use those uh like a model of consumption that I think illustrates the power of what we're building on here. Um, so Baton is a a workflow orchestrator built on top of abilities. So I'll just jump straight into it here and try and add a new workflow. Uh, this is again very prototypy UI. Don't worry about me selling this anytime soon, but uh, just again to show off what we're dealing with. uh I'm able to programmatically pull every ability that's registered on the site uh and also present like sort them by source because uh every plugin has to register uh registers a name space uh for their abilities. Um so I'll just do I want to try let's try to just do like a pure Woo Commerce one. So let's just do like a orders query. Um, and I'm going to change I have here I can pull up the full JSON input schema for that. I again programmatically this is I could install another plugin on this site today that I've never seen anything about and I would have all the same information and same access. It's like I'm building a firstparty integration using anybody's tools. So, WooCommerce has this uh order query ability and I just want to get like all of the processing orders Whoops. Processing orders on my site, which I I think I'll have some. Let's see. I'm going to just type in processing here and then clear out the rest of this. Um, again, this this UI is the prototype, so let's not worry too much about it. I can inspect what the output here is. I know exactly what I'm going to get back from that. Um, I'm going to add another step, though. So, I'm going to take that orders query. When I get all of my processing orders, uh, and I'm going to just try to add a little order note to them. So, Woo also exposes a add order note ability. Uh this is one of the first like write abilities that they've exposed. A lot of them are like read only. Um and so this is going to accept the order ID from the previous step. So I don't need to write that in. I don't need to worry about it being a customer note. And I'll just say hello from WCU. All right. So we've got that. Now there's a problem here though. Uh if I look at the output schema of the orders query, it's not giving me just what I need inherently for this other step. So I've added data filters here where you can see uh every it breaks down the output from the first step and then you can pass that to your input for your following steps. Um again this is all possible with anybody's code. I I'm choosing WooCommerce because I'm familiar with it and I have to do this live in front of you. But if I have anybody else's plugin that has abilities on it, I can see all these same things without writing any a new integration into Baton. It's just reading the abilities API. I'm just exposing what all of WordPress knows through this silly little UI. So, what I want here is just the order ID on all of them. And I'm going to map that into this ID field. I think that's going to be correct. And then I was working on this piece yesterday. So, we'll, you know, demo it. Why not? Uh, and then I need to loop over this, right? So, it's it's going to get me and ideally it's going to get me an array of ids. I have more than one order in processing on my site. So, I'm going to get a whole bunch of IDs from that and then I'm going to pass each of those iteratively in a loop to this add order note action or ability um where I'm passing in this uh the note itself which apparently got lost somehow. So, let's get that in here. You know, this will be the fun thing if something just kind of completely falls over on me. Oh, cool. Uh add order note to processing. You can tell I tried this at least. Let's see if that works correctly. Um, there's a little bit more going on here, but I'm just going to try to run it because, you know, we got so much time. Uh, so it failed, which is great for a demo, right? Because now I get to show off what happens when it fails. Uh, it looks like I've got invalid input uh on the orders query itself. And again, Baton is able to detect that in anybody's plugin because the schemas are defined in a standardized way. Um, so I'll try to get this working to like because it's more interesting to see something that works, I think. Uh, but the the point here I hope that I'm getting across is that all of this is possible already. I think this was my problem is I had invalid JSON. I probably did the same down here, didn't I? Yep. Silly commas. Save that and run it again. We got it. So, we'll walk through this. This is our order query that just was querying over the processing status that returned this whole mess of full order data. I was able to uh filter out just the array of ids from that query, pass that into as input into this add order notes ability and then iterate over each of those IDs and add a note to the orders. So, let's go look at our orders. Good. We do have some that are processing and you can see hello from baton from yesterday. Oh, I I set the text to processing. So, my bad on that one, but that's our note from right now. Uh, it's the wrong time zone because of the site settings, but you've got it. Uh, that was one minute ago. We got a note added to an order. Um, so that's all internal to Woo Commerce, right? I didn't have to build an integration to that. I just get to consume things that they're exposing. I do have a slightly more complicated one that uses multiple plugins that I'll try to run real quick. Yeah, we're good on time. Um, these are my fake users. Uh, don't steal their credit cards. Where am I going? Oh, baton right? Uh, so then this is, uh, send processing to fulfillment. So, I set this up ahead of time. It's a little more complicated in the data filtering. Uh, but I'll walk through a little bit. It's the same sort of orders query that we were doing before to get our processing orders. But this is maybe a more real world example of a workflow that you might want to set up on an e-commerce site where you're sending uh I'm using our Sky Verge's print invoices and packing lists extension. Uh we're going to print off pick lists and email those to whatever set up as like the warehouse email. Um, and this is again using Woo Commerce's order query ability, Sky Verge's print uh or send a document email ability and stringing those together through this like silly little graphical user interface that can just show you what the abilities API is already doing. Um, so we've got the same order query here. We have to do some filtering on that to get just the to get the right shape that we need for our input. and we're able to pass that into uh the print invoices and packing lists uh ability that's exposed. We're going to pick our our document type of pick list. Uh and then we have our there's no output schema there. It's just a the actually the output is boolean true false did it send. Um one thing I didn't highlight here there's also like descriptions for each of the abilities that you can register. Um and so I have those showing here as well. It's going to iterate over every order ID to do that. So, let me wh well hope I didn't change anything on accident. I shouldn't hit save. We're going to try to run that. So, this is stringing together thirdparty code um from Woo Commerce and from Sky Verge all within the centralized API to carry out like an actual userfacing task, a merchant task that they might want to do uh all within uh you know the one common centralized API that we have through abilities. Um this you know what this is in coming soon mode. I think what we're going to see here actually is uh some logs from Woo saying that I tried to send an email, but it got blocked. That's my guess. Yes. So, there you go. [laughter] So, that's our that's our success mode for a coming soon store. Thank you, Woo Commerce, for catching those and not letting me send emails from a a site that's not live. Um, but that's it, right? It's it's that simple. Uh, I I made it actually even more complicated just to be able to show it off. Um but really programmatically you can discover you can inspect and you can consume these abilities across platform AC across the entire platform I guess uh all in one place in a standardized way. Um so we'll switch back now to slides here. I've got a minute to do that. Hopefully not start from the beginning. And if that doesn't work, I can just talk through the rest. It's not much. Looks like that's not going to kick over for me. So that's okay. Uh let's see. Maybe I can just full screen it on here and we'll we'll let that go. Is that just this? Cool. Um, so I'm going to move into Q&A, but I do want to get just the the main idea across again here is that we now have a standardized API for consuming thirdparty functionality across the WordPress platform that includes our own code that we can also build around with this new uh plug-in model, new plug-in architecture that I showed um where we're consuming these functional primitives that are called abilities uh throughout our codebase. Um, yeah. So, with that, I want to give some time for Q&A. I'm trying to make this a very like educational moment. So, please let me know what you don't get. Let me know what questions you have, what doubts you have, what concerns you have, uh, or what came across clearly, what fun new ideas you have. Uh, yeah, there's a microphone in the front. We are, uh, trying to get everything on the recording, so if you can come up to the mic for questions. >> Thanks. >> Hi, my name is Jeremy. Um, I'm a developer for Leaky Paywall. Um my question is um how do you determine I mean we have thousands of functions and things you can do with the plugin. How do you determine what to uh add to the ability to use API and what's not worth it? >> Yes. Yeah. Yeah. I think um for for Sky Verge what we started with was kind of a domain model um of anything basically shorthand it comes down to anytime you're defining a custom post type um and define and saying that okay now I want to expose controls for that post type that's unique to my plug-in because that's something that the plug-in is sort of adding that that domain of business logic to the site um and so you want to expose controls to that. So for our memberships extension, the first abilities we added were creating memberships plans, reading memberships plans, that sort of thing. Kind of CRUD operations across that. I think that's a good place to start. I mean, it's obviously functionality that you're going to be using across your own plug-in, right? So that's again the immediate benefit of now we can consume that. And in one of our plugins, we were able to roll out a REST API integration like on like the same week that we did the abilities API upgrade because all we had to do is write the the bridge class to translate all those abilities over. Um, so I think that's a good place to start. Beyond that, you can look for like custom workflows that your plug-in or your code, whatever it is, um, enables on the site. So I'm trying to think for payw wall. I'm not totally sure what those might be, but the example I like to use there is like a shipping rates extension that can like take in order data and hit an external API. You could expo that's like very custom flow data flow to that plug-in. Uh and you can expose that as an ability uh so that anybody else can can integrate on top of that as well. So those are kind of the two main ways that I see it going. There's obviously a lot more, but for starters, those are the things I look for is those domains that you're adding or the like custom functionality workflows. Yeah. >> Um, this is really interesting to me. I I do a lot of sharing um methods and variables across plugins that I've created using public static classes and stuff like that. >> Yeah. Yeah. >> So, I can see the benefit of this. Let me um ask you like if I make a REST endpoint, you get all kinds of WordPress security and methods and all kinds of stuff for free just by using the WordPress REST methods. Does the abilities API come with like authentication security that kind of those kind of methods that that you can then pull gives you added benefit as well. >> Yes. Yeah. I h Yes. but but also no [laughter] or no but also yes uh so the idea of the abilities is that they'll be uh I don't want to give you a full it depends right [laughter] uh is that the the abilities are defining the the core functionality you do have a permissions callback that you can define there as far as is the user allowed to run this ability um but if you're looking at like exposing to those external integrations the security and privacy or whatever pieces that you need on top top of that kind of come in at those layers of how do I expose this to the rest API and then I'll leverage you know we have to you still have to define the rest API endpoint you can't just like you know have the ability there so you still get to define that layer and can implement those at that at in that place um because you'll want those to be different for a REST API call versus just the admin interface versus a CLI maybe that has has more access or something right um so the abilities API is really focused on defining that core that central core and then the the addition there is some permissioning there but then those additional uh pieces kind of come at that layer. So I think that's maybe the biggest thing if you're starting to look into this is starting to wrap your head around where those pieces live um and at what layer do I need to enforce that um and what's particular to this you know REST API integration versus the core logic of the plugin. Um so there's there's room for differentiation there now. >> Thank you. Yeah. >> Oh boy. [laughter] >> Uh, hi, I'm David. I'm, uh, one of the maintainers for the abilities API. Um, >> hi Nick. This was awesome. Thanks. >> Um, as a plug-in developer, what are the things that aren't currently in the abilities API that uh, you're looking forward towards adding? >> Oh, yeah. Okay. Sure. Get my wish list. Um, yeah. I think I I need to update myself on this and as my like with my self-appointed abilities API evangelist title, I should know this answer. Um I know it's in the pro in it's been there's been an issue for it but I don't know if it's happened yet. Uh filtering on on abilities for discovery it's in. Excellent. We love it. Okay. Yeah, that would that would be my big one was that like the WP get abilities, right? Just literally returns every ability on the site. Um, so having uh like query parameters that you can pass into that to uh to narrow that down, I think is the biggest from a discoverability standpoint. I guess that's still me thinking of it more from the platform level and not the plug-in level. Um, at the plug-in level, I'll have to dig in more because I feel like we've just been so happy with it. [laughter] This is such a canned answer, right? just what a plant. But I genuinely like it's been such a [laughter] it's been such an easy thing to integrate with and so we've seen so much benefit from it in how we structure our own code and how we're able especially to rely on the code of others. Um that that feels like such a win. I have a hard time placing something immediately off the top of my head, but I'm sure my uh developers who are who watch this later will have something for me. >> Thanks. >> All right, I have two questions. I apologize. First first question um where is Baton available if you want to play with it? [laughter] >> Yeah. Um well thank you. Uh not the intent but uh it's just on GitHub. Uh it's uh I started to put together like a.org uh submission for it. We'll see if I go back to that after this. I figured I got it far enough for the talk that I could let that sit. Um it'll be actually I'll have a bunch of links on the screen after this and also a QR code that where you can kind of access a bunch of resources stuff that I've learned from and putting this talk together and that'll include a link to Baton as well. >> Okay. And then second question is um are we going to be able to see the plugins abilities on the WordPress repository the plug-in repository? >> Is anyone working on that? >> Oh, okay. So like on the.org listing see what abilities Thank you for asking that again. This feels like a plant because I really want this to exist. [laughter] Um >> I am a plant. >> Yes. Like this is this is on my wish list. Not again maybe not from the plug-in developer what I want consuming it. But yeah, I think just like we have uh like blocks exposed, right? Where you can see what blocks are added. Having what abilities are added and then being able to kind of discover plugins based on their ability is a huge potential unlock. But even just having them listed there, um, just that first step of seeing what's what a plug-in registers without having to install it first. Um, big proponent. Uh, it doesn't exist today, but yeah, I'm I'm ready to to chase people down for that. There is one. Okay. I thought so. Yeah. Yeah, we've got a track ticket for it. So, yeah, we'll chase that down after this. Yeah. Nice. Yeah. Thank you, though. Got another one. Is it is it possible for abilities to conflict like two SEO plugins creating the same ability or whatever it would be? >> Um yeah, I'm trying to think of how that would play out, right? So the the mental model here is still the same as like I said like a public function or something. Um so they could certainly be doing the same thing. Uh they could possibly try to register the same ability in the the registry. That's kind of the only net new thing for the API is that you have a central place to register those. Those are all namespaced. Um, so it would be pretty hostile to be uh targeting somebody else's namespace for your abilities and I think uh it'll just make your thing not work. So I don't I don't know how much uh risk there is in that. Uh you know there's a little bit of a you know centralized uh scarcity or something right maybe around that. But I yeah, I think aside from from namespace jacking, that would be about it, right? Um, and again, that would be like, you know, don't install that plugin. Like, don't stop using that one if they're trying to do that. >> Hi, um, I'm Dave. I make Ultimate Multi-Site and I added abilities recently. >> You could go back to the slide that had all the complicated lines. >> Yeah. Add multi-sight onto this. seems misleading when I look at it because if you create an ability, unless I'm understanding incorrectly, it doesn't automatically make it available to those other items. It won't make it in the CLI, it won't make it in the REST, >> but you can and if you want to like >> use the same code when you're registering your REST endpoints and your CLI ability. >> Yeah. Yeah. Exactly. Yeah. Yeah. Yeah. I didn't uh I didn't draw lines between like within the circle like these are all the lines come from outside. I felt like there was enough lines on the slide actually. Um [laughter] but uh but you're right that those are all kind of like optional right is like when you have the ability itself it's not automatically in any of those places. Um the I guess like the MCP adapter plugin would maybe be the exception there where using that it does expose those abilities but you can still choose in the ability definition to not expose it to that. Um, so you you still have that that optionality at any point to integrate with a new surface. It just makes it that much easier when you need to. >> My my next question is like >> I like I have this I had a rest before which had like a full CRUD setup you could use creating any of the objects uh my plug-in managed. Would you is there a reason not to expose the same kind of CRUD functionalities in an ability? Um I mean it's going to be use case specific obviously but uh in general like I would say the like in the and this is the model that we've followed like with memberships which already had a rest api uh integration um was that we we rewrote those to consume the abilities underneath. Um so that the the portion that's just that core functionality of you know get this thing from the database or you know write an update to this thing that's in the database that that's all handled by the ability and then the rest API integration becomes that like more of a thin wrapper that just exposes it um that way and you know can add layers to it. It can get, you know, pretty heavy too, but [laughter] um yeah. Yeah, it's uh I would say putting the abilities at the center of that though is is the idea here. >> Very good. Thank you. >> Yeah, thanks. Got like three minutes left, so we're we're in good shape. >> Hi, my name's Rob. I got a easy softball one for you. I'm new to abilities, so thank you for this talk. >> Nice. um just say conceptually I built a function and it renders a graph and I want that graph function to exist in a block. How would abilities help me do that? >> Oh yeah. Um the rendering piece is going to be tied to the block, right? Because that's the view, right? That's like, you know, that's that's where you're showing it. >> Um how what data handling you have underneath that might be where the ability comes in. um where if you have a centralized uh source of of data that you need to uh process in a few different ways depending on the interface that you're showing it in uh that might be that might be good candidate for an ability um that can handle that uh you know write write once in one place and now you can it depends on uh the application but again I default to like a WooCommerce context if you're like processing customer data to show a report or something like that. You might have that uh that fundamental like data processing piece is the ability and then you can expose that to a block. You could just put it on the page. You could uh allow other folks via CLI to get a print out in the terminal or something if they want to. Like it all depends on your users and where you the humans that are on the outside of this circle that you want to see that um kind of determine what layer you use to get to them. I say it's just in the data later is where we'll be working with that which >> Yeah. Yeah. >> Okay. >> Yeah. Exactly. >> All right. Thank you. >> Yeah. Thanks. >> Anybody else? Probably got time for one more, maybe two if we're fast. >> I think I'll be fast. Um, assuming you're using a plugin to ingest uh another plugin's ability, do you like make it a requirement the other plugin or how do you how do you catch like it not being installed or >> um yeah, so it's there's the discoverability layer in the abilities API. Um, so you you have to like proactively query for them essentially. Um, so you'd look for it. You could you could also, you know, introduce checks there. If the ability isn't registered, then either you don't worry about consuming it or you find some other fallback for that. Um, if they just for some reason have an old version of the third party plugin that didn't have the abilities on it, but it does have a public method that you knew about because you used to have an integration for this that was a lot more work to build. Um, you can you can fall back to kind of the old the older less uh, you know, less structured way of doing it. All right, I think that'll be it. Let me get my see you later slide on here real quick. So, that's uh abilities API for humans. Uh the QR code there, like I said, will get you all of those links so you don't have to type them into your phone right now. I built a little landing page that has all that stuff. Uh and you can find me everywhere you can find me online. So, thank you. [applause], Abilities API for Humans, Nick McLoughlin (SkyVerge), 01m0czzmd35wrxxyjgbrh8f876.