Now, if you do maintain your production site and your staging site on the same server, there are a couple little gotchas you might run into. Let's go to my cache configuration file, and if I scroll down, you'll see this section for the prefix. So I'll let you read that, but what it translates to is, if you're using a RAM-based store like memcached, Laravel, to ensure that there is no collision with your keys, it will apply a prefix to the beginning of every key. So you'll see you can either set it in your .env file, or it will read your application name and then add an underscore. So it'll do something like this, and then the name of your key.

name and then add an underscore. So it'll do something like this, and then the name of your key. Again, this is to ensure that, for example, a database query that's been cached on your production site isn't being referenced on your staging site because they're reading from the same cache. Let me give you an example of this. We'll switch over to Forge and scroll down to Laravel Screencasts, edit the .env file, and we will use a RAM-based cache store, so we'll do memcached. And then what I'm going to do is switch over to staging and do the exact same thing. Okay, so now, if I switch over to the terminal, let's boot up php artisan tinker, and we're

And then what I'm going to do is switch over to staging and do the exact same thing. Okay, so now, if I switch over to the terminal, let's boot up php artisan tinker, and we're going to put something into the cache. Maybe videos. We'll just say foobar there. So let's cache that for, you know, a day. Okay, so now, using memcached, we can fetch the value associated with videos. So this is great. You use it on your site, you limit the number of database queries, etc., etc. But now, if you switch over to your staging site, it needs its own cache.

You use it on your site, you limit the number of database queries, etc., etc. But now, if you switch over to your staging site, it needs its own cache. The records you have in your database will be different, so you don't want it to read the cached query from your production end. You know what I mean? So if we boot up php artisan tinker on the staging site and we try to read from the cache, we get the exact same thing. So again, you can see where this gets a little bit tricky. You don't want your staging site reading cache from your main production site. So why is this happening?

You don't want your staging site reading cache from your main production site. So why is this happening? Well, again, notice that Laravel uses this system, so we get Laravel Cache. However, what often happens is, for your staging site, you don't change the app name. So again, let me show you. In staging environment, edit the .env file, the app name is the same, which means the cache key prefix is the same as well, and that's why it's reading from the same data. So you can fix this in a couple ways. One, simply change the name to your site staging or whatever, and that'll do it.

So you can fix this in a couple ways. One, simply change the name to your site staging or whatever, and that'll do it. Because think, now the app name will be staging, so it will be staging cache. And if you want to see that, let's try it again. Now it returns null, which is exactly what we want. But if we go back to our original site, boot up php artisan tinker, now we do have a unique cache for each site. So that would be one option. The other option, if you don't want to tinker with that, the other option is to simply set the cache prefix.

The other option, if you don't want to tinker with that, the other option is to simply set the cache prefix. So we could do that right here, and we could say for staging, we could say staging cache. And now it will use that, rather than dynamically determining the key. So yet again, on our main site, we can get from the cache, but if we switch over to staging and we read from the cache, it should return null, and it does. This is what we want. So yeah, little things like that you'll want to be aware of.