 Thank you that Transience before small story about why I called you at Transience. So like Jean said, I'm talking about the building area. We made WP rockets, you might know. It's your premium and a worthless cash play-in. And recently we modified, which is a play-in and service to optimize your media and images. So both of these projects are about optimization and also are Transience. Because Transience, I look for you on your website. Why? Who already know what is a Transience? Who already use Transience? Maybe the other government. Ah, yes. So I will give you some questions like what it is, why, and how. Just a question, what is a Transience? Transience is a temporary thing. What is Transience in Codex for us? Transience API offers a simple and standardized way to store your footage data in the database. So probably, like you need it, it's just a main engine and a frame. After which, if you expire, it's very important and easy to do. You can do this on this page of your codex, on worker.org. But it's not totally true. Because why? First, it's not the same as an option. You may know if you are already doing it, that Transience is stored in the database. In the options and table. But it's not acts like an option. Like I just said, it's not only in the database. Codex said it's stored in the database. Okay. So it's not only in the database. Because if you're using memcache or opcache, the Transience won't be stored in the database, but directly in the server's memory. So the codex doesn't talk about that. In the time-out, the time frame is not mandatory. The codex is not ten years. It's not mandatory. You could add a time-out to make your presence scarce. But it's not mandatory at all. Also, it can be deleted before the time-out. So the time-out is not a minimum lifetime. It's a maximum age, in fact, for your Transience. And the worst, it's because it's still in the database after expiration. It means if today I set the Transience for one day, I can back on my website seven days later, I go in my database. The Transience is still there. So the codex is not very accurate for this. But we'll see why and how to deal with them, etc. So why do we have to use the Transience? Is it a storage system? Because you get data. You store them in the Transience API in the database. But it's not a storage system. It's a cache system. Because you will gain performance by using the Transience API form with us. We will see quickly when we can use the Transience. For example, in your front-end, if you get the same contents on the many pages, like your last comments, your last posts in the sidebar, you don't have to always go to the database to do request again and again for the last comments between two pages, two editors. It will be the same comments, maybe for one hour, maybe for one day, we'll see also later when we can deal with them. So you can use it on the front-end for the same contents on the many pages. Also, when you do external requests, like your followers, your last tweets, your friends from Facebook or an API, an external API, you don't want that each visitor will gain a website. Each page will load your followers, your last tweets, etc. Each time will do an external request, and you may note an external request at the same time. So it will exactly be slower, of course, but using the Transience, you will cache the data. And some examples for the front-end if you do custom requests in your database using custom tables with big joints, you may need to cache the data as a result of the request because you don't want to again go in the database each time for each page for each visitor. An example for the back-end, you can display a message for a particular user written from a validation or a custom error. The two screenshots here are from the WordPress core. The first one is when you try to activate a plugin, that trigger of a fatal error. So WordPress will try to include the plugin, to activate the plugin in a kind of sandbox mode. We'll grab the error using output buffers, then it will need to refresh the page. But between the refresh, it will lose the information about an error or a strikeout. So it will store the error in a Transience with a user ID and then display later the reason of why this plugin can be activated. And it's the same when you delete plugins. WordPress will store the results of the deleted plugins if it's worked or not. A little example, it's the code from a WordPress core. I just deleted the comments. We will delete some plugins, the one we just checked in our back-end. This will be stored in a variable called deleteResult. Then we will use setTransient, we will see later how to use it, with the name plugins deleteResult, with the user ID, and then the result of this deletion. Then later, after the first refresh, WordPress will get the Transient, of course with the same name, for this particular user ID. It means if another user is refreshing another page, he won't have the notice for him. It's just for this user, because this user deleted some plugins before. Then we delete the Transient, because we don't need it anymore, and then we can display the message, the selected plugins have been deleted. So this case is not for performance, but you can use it to display some information later, and then you delete yourself your Transient. So you don't need a timeframe, an expiration. It's not mandatory, like I said. Where can we use the Transient? A few examples. If you're running a website with widgets like Meteo, Radeo, Lastwitz, et cetera, you may need to use a Transient. In fact, for all of these cases, you need Transient, of course. But do I have to manually delete my Transient? Do I have to add a timeframe for my Transient? Okay, a timeframe, but a long one, a short one. What is this? For example, for the Meteo, I think half an hour or an hour is enough to cache the data. I don't think the clouds will be there in one hour, or new clouds with rain will come. So one hour is kind of perfect. On Radeo, maybe three or five minutes, okay, it's very short, but each three or five minutes, you get a new song. For your Lastwitz, it depends on your tweets, if you are a Twitter fan, maybe you will tweet at ten times per hour, so you need to refresh more. If you tweet not so much, maybe one time per day is enough. You will reduce the external request calls. For your friends or followers, I think one day is enough. Same for your last member, if you're running like a forum, something like that. Same for your popular posts, you will get some new stats, which one is now the first, the third, et cetera. So these six examples are done with Transients, with Timeout. This one, this one's your menu, your bug role, your tag cloud. I can't say I need to refresh in one hour or one day. My menu will be the same, even in one month, two months. I won't set my Transients for two months because in three months it will be the same. So I have to do it manually. What's the difference? The Transients will stay in the database as we saw earlier. So I will have to myself go to delete my Transients. So when do I have to do this? For my menu, I will wait to have a new entry in my menu. Oh, this is correct, okay. When I delete something in my menu, same for my tag cloud. If I don't add or delete or update a new tag, I don't need to refresh my Transients about my tags. So you can use the WordPress hooks on the menu, on tag, on your post. Each time you will update a post, create a new post or delete a post, you will force the Transients to be deleted. Your Transients to be deleted so the next time you want to show your last post, the new Transients will store the new data. For your custom request, I can't tell. It depends on your request, on your needs. It could be automatic, it could be manual. You have to understand when and why to use it. Then you could answer yourself to this question if you need a large or short expiration time frame. Don't use Transients on live data because this example is from the WordPress.org download counter, of course. If I use the Transient to store my number of downloads, I will store them for like one second, two seconds. Is it really useful? Not sure. You may find, HK is of course, you may need but avoid to use Transients on live data because it's cache so it's not very live. And the big question, how? How to use Transients? First, is it from the database or object cache? Here comes a little drawing I did talking about Transient Caching without object cache. So, like 90% of you and me, you get your Transients stored in the database. Each time a page is requested, the database will be called and then your WordPress page will be displayed. New page, new call and the page will be displayed again. But if you are using object cache like memcache, your Transients are stored in the server memory and directly it can be set on your pages. The access is absolutely fast, faster and you won't have to manually delete your Transients. We'll see this why you don't have to do this because the server will manage itself the expiration and depending on his memory needs. We get three basic functions to play with Transients. So, we can set get and delete them and we also get the same with site, set site Transients. But be careful because the site Transients functions are not the functions that manage the multi-site compatibility. In fact, when you use the site Transient functions and you're using a not multi-site WordPress, it will fall back on this one, set Transient. So, we could say I will always use this one. If I'm not in a multi-site, the fallback will be okay if I'm using a multi-site, this one will be okay. Yes and no because if I get two websites or three websites or ten websites in my multi-site that will do an external request to get my followers on each website, I will get the same results because it's the same user, it's the same number of followers but I will have ten requests. So, it depends on the request. If the request is only for this website and another website shouldn't read the Transient, you should continue to use this one. If it's for only one website in your multi-site, you will use set site Transient. Let's see how set Transient works with three parameters. The first is the name of your Transient. Be careful because in your database, WordPress will add two prefixes because you will have two entries in your database if you're using a timeout. So, underscore transient underscore then underscore transient underscore timeout underscore. It means if you are naming your Transient like superplugin and MD5 unique ID, this is the name of your Transient timeout. 64 characters, it's the maximum. It means if I add superplugins, it will be 65. In the database, it will be truncated. So, this one won't be stored. And for the next call, when I will get the Transient, I will get with the last letter, so you won't never find it. So, the getTransient will always return false. So, be careful about your name. I suggest you to cut the MD5, not using the 32 characters for the MD5, you can just like 8, 10, it's enough. And this is a bad ID, I did that. If you use the date of today, okay. This is not a real date. 16 August 14, then tomorrow it will stay in your database for error because we will see why just after. The deletion of the plugin is not automatic. You have to request a known Transient to be deleted by WordPress. But tomorrow, it won't be the same date. So, you can't get a Transient with the date of yesterday. The value. So, you can use strings, integers, arrays, objects, serialized data, and you get 4 gigabytes of data. Pretty enough. But don't try to add a simple XML object directly. If you do this, it will explode. Not you, your development. And the famous exploration. So, the length is in seconds. It's not a date. You can't tell expiration 31 December. You have to add a number of seconds. And this number of seconds is a maximum age. It's not an expiration guarantee. It means if I set a Transient for like one year, I can assure you it won't never stay one year in your database. First reason, each time you update your WordPress core, WordPress will delete all your Transients. Yeah. If you're using subscripts or plugins that will purge your Transients, it will be deleted before. So, it's not a lifetime. It's just a maximum age. You can't relay on that like a cron. It's not a cron. It's not a web cron. If you want to be sure that your data will stay in your database, don't use Transient. Use an option. Like I said in the first slide, a Transient, it's a temporary thing. It's pretty important. If you're using object cache, it also be possible to be deleted earlier because when the server doesn't have enough memory, it will start to delete the Transients by age. It doesn't look for the timeout just in the added orders. And if you don't use exploration, so zero second, and you don't use object cache, it will always be in your database. This is why you have to delete them. And take care of the autoload. You may know or not. In the options table, when you add an option, you can set autoload yes or no. It means when WordPress is loading, all the autoload yes options will be loaded in a PHP object. It means if I don't add an exploration, and I get a big Transient, it will be autoloaded. 4 gigabytes in the PHP memory. Maximum. If you use an exploration, the autoload will be set to false. So each time WordPress will need to get this Transient, it will do two requests in the database. Ten Transients equal 20 requests. It's not a big deal because it's two very small requests. You can't... how to tell? You can't say it will be slower. I'm not sure. Because it's very... two requests, very, very small in fact. So now you set Transient, you will now get Transient with only one parameter, the name. But you have to check with equal, equal, equal to check the type of the result. Because if you set a Transient from your followers, and you get zero followers, sorry for you, and you don't check with three equal symbols, the Get Transient will return false because zero is equal to false. So it will do again the external request to get your follower, then zero again, then get equal false, and it's a loop. Your Transient is not working using the three equal symbols. You will check if it's really false, really false. I don't know these Transients. Again, I talked about the deletion. The Transient is now only deleted now because you try to get the Transient. If the timeout expired, okay, now WordPress will delete it. If you don't try to get this Transient, it will stay in the database for a while. This is why you can't use a date in the name of a Transient. Talking about hooks, it won't trigger this hook. When you get the Transient and it's expired, delet Transient with the name of your Transient won't be triggered, but this one will be. It's absolutely not in the codex, only on my slide. Quick example. I've got a function and my external API request, and I return the data. I can do something with my data, of course. So each time I will call my function, each time I will do my API request. So this is bad. Use Transient. The code is not so difficult. You will try to get your Transient with your custom name. If the data is absolutely equal to false, so I don't know how my Transients may be expired, so I will do my external request. I will set my Transient with the same name of the GetTransient, of course, my data and my expiration. Then, like earlier, I do something with and I return. Next call. The GetTransient won't return false, so the if is false. Directly, I do something and I return. My external request API has been done. It's quite the same when you use persistent cache with WordPress. The code is slightly the same, but the cache is not... This kind of cache is not in the database, only in the WordPress memory. So the cache Transients will stay between pages, not this one. And this is a bad idea, because if you try to read the timeout yourself using GetOption, because maybe you will have the bad idea like me, because I did that, to tell I will try to get the Transients. If the Transient has expired, I will try to get my new data, but what if the external request will fail because website is down or what? I just lost my data. So you could think about doing your own GetOption to read the timeout, then check yourself the timeout and get the option yourself. But first, you will miss the Transient hooks, so it's not very cool. And remember that if Transients are used with memcache, you won't be able to read them using Option, because Option will only read the database, not the server memory. So it's a bad idea. Sometimes you have to delete your Transient yourself with only one parameter, and this is the same false good idea because the delete option won't work if you're using object cache or memcache, because options are not Transients. You may know Rust, I think is here today. He did this little script to delete your expert Transient in your database. So the magic line is here, if WordPress is using external object cache return, there's nothing, it won't work. But if you're not using object cache, so he will himself request all your Transients with an expert time. So you can use this script to delete your Transient and then clean your database from pure Transient, old Transient, etc. It's a good one. And this will trigger the previous hooks I talked about. A little help for you. I propose you four plugins to clean your Transients from your backend. You can delete them with the second one. The artists and this one are kind of the same. The Transient Manager is not the same. You will find all your Transients set in your database. You will see the next exploration, etc. And if you're using debug bar, you will find for each page how many Transients have been loaded, etc. Thank you. Have you got some questions about Transients? Thank you, Julia. Let's give it up for Julia first. Big round of applause. If you have any questions, just raise your hand. We'll have a mic runner come around and bring you the microphone. Hello. If your server has object caching, do you have to specify if you want your Transient to be stored in object cache? No, you don't have to. WordPress will do it itself. I've never used it before, so the one place I would have it would be with menus. Would it be something that you'd trigger on the saving of a menu, like a hook? Yeah, you can do it on the save menu. Each time you add an item on your switch items, the save menu hook is a good one, yes. Because sometimes you get big menus and the request can be huge. It's a kind of a get post. And each time you load your website, you get one, maybe two, sometimes three menus, so it can be loud, heavy. I thought about it a bit more, but you mentioned that there was, I think it was a plug-in or a bit of code to delete all the expired Transients. I was thinking during web development, you might want to delete all your Transients, whether they're expired or not, because you're testing and you just want to see the new data. Even if you've got Transients set for an hour, do you know if there's something in the API for that? No, you can do your own request. Personally, I go in my PHP, my admin. I select all like Transients, delete all. In fact, when you delete all your plug-in, all your Transients, don't delete all your plug-ins. It's a very bad idea. When you delete all your Transients, they might have to remain the same. Maybe the next call will be slower, but it doesn't have to break anything, any display, any widget, et cetera. Transients are really temporary. So let's imagine you update your WordPress core. It will delete all your Transients. Imagine your website has been configured. It's not logical. Your Transients are really temporary. You could delete them at any moments, but not your options. Don't delete your options. Thanks. Hi. If doing a core upgrade with WordPress deletes all your Transients, what's the best way to handle that if you're reliant on those Transients for some sort of functionality in the website? Don't use Transients. For example, if we use it in one particular case where we're storing a cookie with an ID in it, and the ID is a way of relating those two things, it is a temporary thing. It's temporary, but not really temporary. You can create your own Transients using the options. You set your own timeout, your own option. You grab your own timeout, check, et cetera. And then you are sure that your Transient will be related with the RAR scripts or the WordPress updates or manually. You have to do it just... What would be your strategy for warming up the cache after a core update? Let's say you have Transient because you have some very heavy API calls, and then after every core update there would be many slow page loads. How would you handle that? Do you want that this Transient will be deleted? Yeah, they will be deleted at the core update, but how would you warm up the cache again after the core update, so trigger to recreating the Transients? Just reload. Just reload your WordPress. You can do that using your own bot, maybe. Like for the WP Rocket, when you pair the cache, our bot is asked to come on the website and store the new page in the cache of the user. So, kind of that. Each time your WordPress site has been updated or this particular Transient has been deleted, you can ask being a cron or something to get on your website to load the heavy... and avoid that it will be done by your visitors. So, you would say which pages would create the Transient and then just load them after the core update? Because otherwise the first user browsing the page would trigger the Transient update. Yes, so if you don't want that the user is the one through the Transient, ask a bot to visit your website, any page, logically any page, it depends on your development. Maybe it's only for the backend, maybe only for a particular page. Kind of leading off the back of that, I was going to ask if you knew of any other solutions to not deleting Transients when they need recreating. Because last year Mark Jaquith was talking about a plugin he wrote that basically does when a deletion is appropriate, it doesn't delete the Transient, it loves it and then requests the new data in the background. I don't know if you knew of any other solution to that or if that's still the only thing around. I tested this one and it's working, but I'm not sure that it would be implemented in WordPress. But it's a way to do it, to avoid losing data before grabbing some new ones. That also affects the previous comment about the performance of new people coming, it stops that performance here. Good question. You won a shirt, not for me. Can you cite any real world examples that you've come across of a dramatic performance improvement after implementing Transients? The best performance gain is always from external requests. But for example, I'd be interested to know if we're saving half a second on a page load or if you've seen more dramatic improvements. Yes, this is... I mean, I think I gained like three seconds on a page using Transient because I was using a short code and each short code was using an external request and in my page I could use any short codes... How to tell? Any number of short codes I want. So if I put 10 short codes or 20 short codes, each time I've got 20 external requests. So of course you can't do that. 20 on different URLs. Each time you will have to recover the DNS, call the API, authentication, retrieve the data, display. So you can gain like one second, two seconds, maybe ten seconds. External request is the best gain performance visible.