As a Developer, one thing that you’ll need to do quite a bit is stage your changes before they go live. Anytime you make an update before you go live, say to add new code or modify its content, when you hit “Update” that change is immediately reflected on the web site. Every change happens in real time. So, in the case where you want to make a bunch of changes and you don’t want them to be reflected on the web site immediately, you need a staging area where you’ll be able to preview that code and make sure everything works correctly before pushing it live. There are two common ways to do this. One of them is tied to creating a customer account on the front end. The other one is tied to your ip address. The idea behind it is you log in as a customer on the front end, you can then test for things like the customer id, the customer login, or other elements of the customer and if you log in as that customer display this code else display the regular code.
Let’s take a look at TokenList to see what variables are available that we can test for. So I’m back in my Miva Admin, I’m going to search for the Storefront page, and then I’m going to pull up tokenlist under the “More” menu button here. Now TokenList shows me all the available variables on the page. I’m going to search for “Customer.” Now we see here, there aren’t very many variables related to customer. There’s a few global variables, a local variable, but nothing with a customer id or customer login. Well, that’s because I’m not logged in. TokenList is able to view a front end of the web site as you see it. So if you’re logged in, TokenList will see you as logged in and have access to those variables. Let’s log in and see what happens. So now I’m signed in, it says “Welcome back Brennan.” Let me go back here to the Admin and let’s refresh TokenList. So I’m just going to close it, and to refresh it I just need to navigate to and other page and then back to it. So here I’m going to pull up TokenList again and search for customer.
So here, you’ll see I have a lot more variables at my disposal. So, the main one we’re going to look at is g.customer:id and g.customer:login. However, there are a bunch of other variables here that are all related to my customer account. This is all stored within this customer structure. So let’s look at this customer id first. Because I’m the first customer in the store, my id is 1. So we can test for that and say, “if g.customer:id = 1 show this code.” Let’s see how that looks. So here back in my text editor I have that exact if statement.
That data can be your new code, it can be whatever you want. This can be an if l statement as well. So you can have two blocks of code. One for if you’re logged in as that customer and one for if you’re not for regular users to see. So let’s take this, let’s put this on the page and see what happens. Let’s go down to my content section here and paste this code in. I’ll hit update, then go back to my storefront page and click refresh. It now says “My customer id is 1.” Well, how can we prove this isn’t showing up for all customers? Let me log out and see if that is still displayed. Once I logout and refresh, you’ll see that it’s gone. Exactly what we expect.
Let’s try one more “if statement.” We can say:
This is the same code as above, but instead of testing for my customer id, I’m testing for my customer login which may be a little easier to remember. I’m going to paste this code right below our old code, go back to our storefront page and log back in. When I navigate back to my storefront page now, I see both messages. My customer id is 1 and I’m logged in as bheyde. These are two really nice ways to be able to stage code behind a login so only you can see it and you can even give it to your clients. You can give them a login, they can login as that user and they’ll see everything you see. So a regular customer who is not logged in as this specific user will just see the normal site.
One last thing we can test for has to do with ip address. Say you don’t want to be logging in constantly as a customer account to stage your changes. Or say you’re making a change that requires you to be logged out to see. Well, in that case you can use your ip address. This is a nice tool Because it will only show your changes to your ip address, so everyone else doesn’t see it. So here’s my ip address here and as we saw in one of the earlier videos, we’re testing for a system variable. This “s.remote_addr” which is the ip address of the remote user, which in this case, is me. Now you may be asking, how do I find my ip address? Well, this is something that TokenList can give you as well. Let’s jump back to the Miva Admin. I’ll pull up TokenList here on the Storefront page. I’m going to search for “remote” and here’s a system variable, g.session:remoteaddr and it gives you my ip address here. I’m going to copy this, I’ll bring it back to the text editor and replace the ip address with mine. Now, we should be able to run this in Miva and it should show us this message, “This can only be seen by my IP address.” I’ll paste it in the code, hit update, go back over to my storefront page, hit refresh and I see the message just as I expect. Well, how can I validate that not everyone is seeing this message? Let me change the ip address by 1 just to verify that this is in fact, working. I’ve changed the ip address, hit update, go back over to the front end, hit refresh, and the message went away just as I would expect. If you’re using the ip address is doesn’t require that you be logged in. I can be logged in or logged out. It doesn’t matter. As long as the ip address is correct, it will show me those changes. So those are three great ways to stage changes behind a customer login or your ip address where you can make as many changes as you’d need without impacting the live site.