 Hi everybody. My name is Matt. I work at Automatic on the VIP team. And I am obviously speaking in English, so it's better than me speaking in French because that's sort of like a null operation. It wouldn't happen. But I appreciate you listening to me in English here in Paris. The VIP team at Automatic, we were responsible for hosting and providing services to some very large WordPress sites that are part of media, government, and industry. And we host some very major and highly-scaled brands on our platform. And for me it means I'm an engineer, so I have the pleasure of working on these really cool themes and watching really great WordPress developers all over the world do what they do. So if you want to know more about that, let me know. But for today, we're going to be talking about term meta. And as most of you probably know, term meta is the sort of newest major feature in WordPress Core. I was full disclosure, I was not part of creating term meta, but because of the open way we work, you can see how it was made. So a little bit of what we're going to do today is talk about how and why this feature came into Core. And we'll also be talking about, you know, what the feature is, what's new in Core, what new powers you now have now that you have a term meta API, how it actually works. So I intend to go down into the guts a little bit and we'll talk about why the feature was difficult to create and something about how the tables work behind the scenes in WordPress to surface terms. And then I just think it's a cool story. When you hear a little bit about how this feature happened and what caused it to happen, it's sort of just a fun story to tell. So we'll focus on the human side of it a little bit too. But first let's talk about metadata. So metadata is basically just data about other data, right? So you have a table that provides some data and it refers to another piece of data. And historically before 4.4, and we're actually somewhere in there for a long time, WordPress allowed meta on posts, users and comments. And this feature is pretty simple. We're just adding to that. So we now allow meta to be attached to terms. And just so we're super clear term, you know what that is? That's a single tag, a category or another member of some custom taxonomy that you define. Okay. So now let's go back in time a little bit. Way back to June 13th, 2009. And I'm going to start talking about some actual people who are involved in this. So actually maybe they're here. So sorry, I'm going to talk about you if you're here. This is a guy named Daniel. He lives in Poland. He has the cool wordpress.org username of sirzuro. And he opened this core ticket on that day in 2009. And basically the core ticket said, why is there no term meta in WordPress? It would be great to have. So this is a feature request he opened. This became a very famous and long ticket. It actually lived for six years. And we'll talk all about its history in a moment. But you can see what he's asking for this for here. Like, let's have term meta. It's kind of crazy that we have to do all these tricks to attach term meta to terms. Why can't we just do it naturally in the API? And in fact, Daniel was right. You know about this screen. This is the edit screen for a term, either a category, tag, whatever. This was historically quite difficult to extend. There were some hooks available for that, but you had to do lots of crazy tricks to make this work. So adding a field here was a challenge. There were a bunch of plugins that came about to help you with that. But not only was it an engineering challenge to even make it happen, but if you did, the results were sometimes not so great. Some unnatural things would occur, like the description would hold the meta that you wanted, or they would be attached using an option. And then what's more, the resulting queries to retrieve that on your templates or whatever were quite expensive sometimes and performance could be an issue. So this is Daniel's issue and we'll come refer to it a few times here. Let's go further back in time. February 10th, 2008, on this day, a guy named Ryan, who I think maybe many of you know, this is Ryan McHugh. I think he was perhaps 15 at the time, I don't know, but he opened this ticket, number 5809. And this is a very famous ticket. I think you all will immediately recognize this. This is the bug in WordPress where if you make a category and then you make a tag with the same name, and then you edit the category, what happens? You edit the tag too! It's insane, right? So if I change the name of the tag, this is prior to again 4-2 in these recent changes, I magically have changed the name of the category as well. And this was a super annoying bug and really embarrassing, right? Hard to explain why this happens. Well, it turns out that these two bugs are related. We'll talk about how in a minute. And here's a little bit of a timeline just so you can get a sense of how hard this was to solve, okay? So Ryan's bug, Daniel's feature request, here's when they were actually solved, okay? This one lasted, I think, seven years. That was six and a half years. So these are major, seem very simple, right? But major stuff going on in the background. Let's talk about why this took so long. So a bunch of reasons. One is it's a deep problem. And we'll talk a little bit about the structure of tables in the background that made this hard. And it was so deep in fact that it affected stuff like the upgrade path of WordPress. There were many ideas over many years about how to make this change in a way that wouldn't cause an upgrade nightmare for everyone using WordPress. And the same with what if we change some fundamental facts about the table structure that cause backward compatibility issues and how much backward compatibility, how many backward compatibility issues are acceptable. So these are major and serious problems. So let's dive in here a little bit and talk about the tables. Okay, why is this hard? This is how WordPress organizes its meta, right? You have some table containing data, users, comments, posts, and then you have the corresponding meta tables. This is everything I'm going to say in the next slide that's true before 4.2, okay? With terms is a little different. One of these things is not like the other, right? These are the three tables that deal with terms and we'll look at them a little more closely here. Prior to 4.2, you had a terms table, right? And what was it for? It basically listed all the terms in a unique way. That means no term with the same slug was repeated. In fact, on the MySQL level, there was a unique, that column was unique, right? So you couldn't insert a term that had the same, twice with the same slug. So that was a unique list of all the terms. WP term taxonomy mapped each of those terms to various taxonomy. So the same term could be in categories and tax and perhaps a custom taxonomy that you made. And then term relationships, the third table, in a one to many way again, governed sort of what was tagged in categories with what? Related posts to these objects. So Ryan's issue here is pretty obvious immediately, right? This uniqueness of slugs is the problem, right? So you can see if I rename a table or change anything in the WP terms table, it will affect all of the objects in WP term taxonomy that are associated with that term. So let's look a little closer at how WordPress stores meta. WordPress has a uniform API for all meta. In fact, when you call, update, create, delete, get meta, you're just right underneath calling another function that handles all of the different types of meta. And this is a good practice. It's done this way on purpose. And there's an enforced uniformity of these meta tables as well that corresponds to that. So the question became, and if you read the ticket that is a feature request for this, the big problem was how do you relate a table like this and the core, the whole API that we have for meta to tables like these, right? So it was decided early, and if you read, it's actually really fun to read that whole ticket. It was decided quite early that it was not really possible to relate this, this kind of table to WP term taxonomy. And that's because there are two keys here. There's both a taxonomy and a term. And in this table, there's only one key, and we want to keep it that way, a single object, right? So that was ruled out over, I think it took a long time, maybe a year of arguing, but they finally decided no. And likewise, it doesn't really work over here either, because when I attach some meta to a term, I wanted to apply differently to my category than a tag, even if they have happened to have the same name. So they were really kind of in a quandary here. And because neither of these strategies worked, Daniel's request sort of slept. And it became known as the problem of shared terms. So I like to think of it as a fierce argument happened, and then if you look and read the history of the ticket, it kind of went to sleep. Yeah. And it slept. And it slept. And it slept for almost three, four years before it woke up. So July 2013, there was a renewed energy around getting this feature finally into core. And this is one, Nason, kind of following the history here he made this post, which outlined a roadmap for how a solution might work. And we'll look at that solution now. And soon after that, Boone, who many might also know, became sort of involved in this ticket and eventually went on to be the main implementer of everything we'll talk about here. So these are the two guys who sort of helped push this forward. Here's the plan. First of all, it was decided that we should stop making things worse. So WordPress should not make any more shared terms. And so as a 401, this was rolled out. So at that time, if you were to create a category or a tag, you stopped trying to reuse the same term in that table. Unfortunately, another behavior where you had that little dash two that would appear next to your slugs was introduced, but it was temporary. So that was 401, no more new shared terms. In 4.2, WordPress started to fix proactively the shared terms when you would edit a term. So I think there were other times in which this would happen, but particularly if you edited a term, it would do what's called a term split. It would create a new entry in WP terms so that there was now a one to one correspondence between WP term taxonomy and that table and terms would start to be fixed. This actually fixed Ryan's bug, right? Because when you change the name of the term, that whole problem we described before was fixed in 4.2. In 4.3, all remaining terms were split. And this happened on install or update. So when you updated WordPress, process ran, found all of the terms that had this problem, created new entries in WP terms for those shared terms. The issue here was that sometimes a term ID would change in that process. So if you had a category that needed to be split, its term ID might have changed due to it being in a new row. And this could cause a sort of minor commotion because then if you were caching term IDs, for example, you had to compensate for that. But this happened in 4.3. And finally in 4.4, we get the real thing. We get term meta. So that was sort of the process. And I should note this is not quite finished. There's another step here we'll talk about in a minute that is coming sometime we don't know it. Okay, so what's the state of affairs right now? Right now, WP terms and WP term taxonomy no longer have as of 4.4 that one to many relationship. They have a one to one relationship. There are no shared terms. For each row and WP terms, there's a row and WP term taxonomy. So they actually even though they're still joined when you query them, they function as a single table. And there is this brand new table, WP term meta that looks exactly like all the other meta tables. You get this new API, add to meta update to meta all of the usual meta functions are now available for terms. You can use them now. You can, and as I say, it's the same stuff under the hood as all of the other stuff. Meta query arguments for get terms are available so you can select your terms in all the same way you do posts with meta queries, right? And there's also some performance stuff around caching in the background going on that was introduced. So let's talk about how you would apply these new powers that you have with term meta. Well, there's many applications. I won't be able to list them all here, but here's a great example that people keep talking about, right? Few tag stuff in GitHub ever, right? You can apply a tag and has these cool colors that go with each of the tags. How do they do that? How does it know that a color is associated with the tag or a category? Well, it's using something like this if you do it in the logical way. So things like this are now very easy to implement at WordPress, just with core. These are examples of index pages, right? Like category listings or tag listings. And these pages are going to get a lot cooler, because you can now associate meta with all of these kind of objects that you would present to a user, right? And it's super easy to do it. On the back end, adding fields to edit screens for terms is very quick and quite easy. So you can start to extend these sorts of screens like you would a post screen. And then listings have all kinds of cool stuff you can do with them, right? You can add columns and display your new meta in these ways as well. So how do you do all this? I'm not going to actually go into all of the detail of how this stuff works, but these two guys, Thomas and Justin, have written really awesome tutorials that will take you through all of the steps for doing this. If you're familiar with extending posts, it should be quite something that you're used to. So I'd really suggest either of these. I've just tweeted out the link to this, so you can go and explore all of these links that I have up there after this. And then JJJ, the famous JJJ, he actually has a starter class for all of this UI. So you can go here and he's done all of the boring work about the hooks that you need to use to modify all of this stuff. So if I were you, if I were doing this now, I would probably go and download this class, extend it, and build all kinds of cool UI really quickly. So there is one thing left that will happen here. It's promised slash threatened that the WP terms table and WP taxonomy terms table will be combined into a single table. There's from what I can tell not 100% certainty that this will happen, but I would say high probability. It was in the original nascent plan. So we could expect this maybe in four, five, four, six. I think it will be done in as safe a way as possible. But if you do have a plugin or a theme that directly queries either of these tables, you might want to look into that. You shouldn't have one that does that. But it would be something like your writing sequel and the wrong way. But just be warned that these tables are under flux at this point. So it's something to watch out for. And just to be clear, this would mean this grouping of tables up here that are now joined each and every time you look for a term would be just become a single table with preserved, probably preserved column names and stuff like that. Okay, so I just want to like, rhapsodize for a moment about how cool this whole thing is. Right? It was frustrating that these two guys submitted their issues like six years ago, and finally only now is it getting done. But if you think about all of the, the care and concern that went into this, you know, like, there was a lot of people who contributed and I've just picked out all their pictures. These are the folks who had something to do with either of those two tickets. And over time, they either contributed code or they put comments in or they tested things or they, they wrote, wrote requests or sometimes they even just closed duplicate tickets. But this is a fantastic example of how the community can come together, make decisions and get really big things done in WordPress core. So I'd encourage you if you find this kind of a cool story and want to learn how to do it yourself, go to make.wordpress.org. For those of you who aren't involved and get involved in some of these discussions that are happening really close to the center of the product that we all use. So I think that's kind of all I have. You can get the slides there. And should we do questions and stuff? Cool. Indeed. That was a cool story. Yeah. We have a couple of cool question now. Yeah. In the last version of VP, you introduce in the last version of VP, you introduce the new VP class term or class term to define the object of term. You know, you know that? Yeah, there are why, why is this class is a final class? I don't know the answer to that. There are there are underlying classes for everything I just talked about. But so you're asking why can't you extend that class even more? Why is it declared final? Yeah. Why is this class a why is this class is final class? Okay. Why is there a class? I would imagine there's a class for for all of many of the objects here that correspond to other classes that you have for posts and things like that. So there it's not surprising that there is a class. Why is it final? I'm maybe someone knows the answer that to that immediately, but let's go check. We can read in core after this and we'll find out. Bonjour, je vais pas faire l'effort de parler en anglais parce que je suis vraiment trop de nul. Si on pouvait me traduire, je serais vraiment c'est super merci. En fait, ma question, en fait, je voudrais savoir s'il était prévu dans les costumes post-tip, s'il était possible de, il était prévu de faire quelque chose comme ça, en fait, c'est-à-dire que je me retrouve souvent en tant qu'intégratrice, je me retrouve souvent dans des cas où j'ai une liste d'archives et le référencement veut évidemment mettre du texte dedans et bref, vous voyez apparemment tout à fait ce que je veux dire. Et donc voilà, je voulais savoir s'il existait, enfin si c'était prévu, en fait. Right. The question is about custom post-types and do we have the same mechanism to have custom files or met at it for custom post types or the person don't know them actually. Okay, so can there be meta on a custom post type? Yeah. Yes. Yes, you can attach meta to any post that you want, even if you define a custom post type, it can also have post meta. I think is that the right question? Yes. Yes, we can. It already exists, in fact, that is to say that in fact on the I'm just going to Truth, please, yeah. On the post, the pages or the custom post type, you ask what we call the custom fields. And so in fact, that's what your meta is about, that you can attach to the archive. Okay. Okay, the question was different actually, and I'm just thinking about how to translate it. She wants to attach meta data to archive page. Yes. Directly. Yes, this is exact. If the archive page is based on a term. It is not. It is the archive page of a custom post type. I see. I'm sure there is a way to do that. Yes. So talk to me after and we can have maybe a translator and we'll figure it out. Yeah, but it's possible. Should we start a ticket or something? Yeah. Yeah, six years from now, no problem. Anything. Yeah. No, we can let's talk after and we can discuss it. Yeah. Out of curiosity, because I could read through the comments of the on the ticket, of course, has there been a discussion about adding the fields automatically in the UI, like is the case for custom fields for posts? Interesting. I have not seen that yet. There were many discussions in the in the ticket. The fact that it ended up implemented this way was a compromise and only arrived here after many iterations of can we do it this way? And then they would think through all of the implications of that. And so but as far as your question, I yeah, I think what's available to begin with is just the API more or less that I described here. You can register the meta in the same way as any other meta. Pretty much you can do you can call all of the core meta stuff around terms that you can for posts. The UI on term editing in particular, I don't think there's any automated way for those fields to appear unless I'm mistaken about that. Yeah. Is that answer your question? Okay. Hello. My question is about if there are other issues like this one that haven't been fixed yet and that we should expect and keep in mind when when developing new websites. Wow. And the other question is, are you aware of any new features that will be introduced in the next major versions of WordPress? I mean, major features that will change how WordPress works. Thank you. Oh, that's awesome. For me, actually, this was one of the most obvious features that was missing from WordPress. That's and I think the question of whether I mean, I would argue I guess there's not one quite as large as this. That's an obvious problem with the basic API. Obviously, this weekend you've heard a lot of discussion and even today this morning, there was some of an online explosion again about the REST API and its pathway into core. So I would say the major thing that we're all going to be getting used to in the next three, four releases is how will the REST API enter core? And how will we manipulate it? That's the new kind of world of WordPress, I think. I can say that our clients in VIP are all preparing to use the REST API in these very large and scaled sites. Many of them currently write their own endpoints for all sorts of reasons, as I'm sure many of you do, and they're looking forward to some uniformityacross.organ.com as far as how the REST API works. So I think that's a very important area for everyone to watch and learn about. I know for me personally, I'm a PHP person. It's going to be a change of mentality about how I think about things and many things with WordPress. Hi, so I have a question. Apart from design feature like adding icon and what would be useful is going to be term meta for other things like maybe like your thing? Sure. Yeah, how useful is going to be for me? So there are many other examples. I just listed a few. I helped to maintain a plugin called coauthors plus, which uses some very what I would describe as exotic workarounds because term meta was not available. So I think many large plugins may find that they can be rewritten and simplified because of this. And as a result, the intensity of the queries behind many of these plugins that we all use will go down. So I think performance will be a huge factor in this. Even those two tables that we talked about becoming one will eliminate a join from so many queries underneath WordPress. It's crazy. And then if you think that table is then again joined, if you've ever looked inspected like the queries WordPress generates the ones with like seven joins in them and stuff, the number of those joins is going to be become less because of this. So features is just a product of your imagination. What can you build the term meta, but fundamental performance stuff for me is actually more exciting almost. And we know we have to put a term to your talk. Thank you very much. Thanks, guys.