So, we now know that all parameters passed in the url automatically become global variables. This is very nice and very useful. If you take a look at Miva’s default url structure; it’s category structure, it’s product structure, you’ll notice that there’s a series of parameters that are usually always there. I want to dive into a few of them because you’ll see them over and over again.
The first one is Screen. You’ll see something like Screen=PROD, or screen=SFNT. The screen tells Miva which page code to render. So screen=SFNT means the storefront page is being displayed. The word screen and page really mean the same thing. The screen parameter is just telling Miva which page to display. Now, this is 99% accurate. Any time you see in the url where there’s screen=PROD you’re most likely on the Product page. However, there is a use case is where this is not true. Miva has a concept of a UI exception. Where behind the scenes if there’s a user interface error for whatever reason, Miva will essentially hijack that page and instead of displaying the product page it will display some error page. Now because all parameters either passed in the url or passed as a form submit become global variables, Miva will still display screen=PROD, but it wasn’t the product screen that got rendered. It’s some error screen that needed to display. You won’t see this a lot, but I wanted to bring this up in case you ever come across it. However, for the most part you can be fairly confident that screen=PROD means the product page is being rendered and displayed.
The next one is Product_Code. This is written with a capital P for Product and capital C for Code. It does work with lowercase, but as convention it’s always written with capital letters for the first letter of each word. So Product_Code references the product code of the product being displayed. This is mostly used on the product page. So if you took a url that was say referencing Product_Code Test and you deleted the word test and instead put test2, it would pull up the test2 product.
The same thing goes for category code. It’s Category_Code and this is the code of the category being displayed. This is mostly used on the category page, but it’s also used on the product page if you wanted to pass a category code in the url.
The fourth one is Store_Code. Sometimes you’ll see this and sometimes you won’t. The store code is optional. It doesn’t need to be there but it is recommended. In the case where you have a mall, a Miva installation with multiple stores, the store code is going to be required. This code tells Miva which store to pull the data from. Now, if you don’t have a mall and only have a single store, this parameter becomes less important, but it’s still good to have it there so in the future if you ever wanted to create a mall, you have that option without having to go and redo your entire url structure.
The last one I want to talk about is Action. Action is the action being performed. Now if you’re just visiting a category page or product page there is no action. It’s just pulling that data in and displaying it. However, when you submit the add to cart button, there’s an action being performed. So there’s an action for Add to cart and that action is ADPR. There’s an action for removing a product, there’s an action for logging in, there’s an action for logging out. Miva has a whole list of actions which we’ll talk about in a later video. Anytime you see an action passed in the url, or as a hidden input in a form, you’ll know that this is the action that Miva’s going to perform when that form is submitted. Actions are a key part of Miva Merchant and they tell Miva what to do.
Let’s take a look at some url examples. So here, I just pulled this from our demo store: so you’ll see the domain name mm5/merchant.mvc which is the default url for Miva Merchant and then the question mark. Everything after the question mark is a parameter. So we have three parameters here which are highlighted in different colors. You have the store code which is V9. You have the screen which is CTGY. This is telling Miva to pull the contents of the Category page. Then we have the Category Code of Phones. So this is telling Miva what category code to pull information from.
http://version9.mivamerchant/mm5/merchant.mvc? Store_Code=v9&Screen=CTGY&Category_Code=Phones
The same thing goes for the url below for the product page. So the screen is changed to PROD. Instead of Category Code we have Product Code. This is the default url structure for Miva Merchant.
http://version9.mivamerchant.net/mm5/merchant.mvc?Store_Code=v9&Screen=PROD&Product_Code=iphone5c
Now, you may not always see this when visiting a site. Most of the time you can turn on the search links or short links so you hide this long url structure and you replace it with a shorter, easier to read url structure. This is typically done, but behind the scenes these parameters are still being passed as you see here. Let’s take a look at some live examples.
Here I am back at the Miva Merchant Storefront. Now you’ll notice in the url we have two parameters: Store_Code=v9 and Screen=SFNT. So this tells us that we’re on the Storefront page. Let’s play around with this. I’m going to get rid of store code and see what happens. Nothing changed. Because I only have one store Miva’s able to still return all the correct data without the store code. The other one here, Screen=SFNT, well, let’s see what happens when I delete this. Nothing happened. Storefront is an actual special use case where you can actually remove the screen and it will still pull the storefront. This is because if there’s no screen code is passed within the url, Miva is programmed to always display the storefront page. Now, it doesn’t have to pass in the url. It can be passed in a form submit. So you’ll see during the checkout process this url here, usually with some session parameters and it still pulls the right page. This is because behind the scenes the screen is being passed and each form submit as you go from page to page. So as long as Miva knows that screen variable, it will pull the correct page. Let’s go over here and click on phones. So this is a category page and again we have the store code, we have the screen CTGY and then the category code being displayed. If I click on this one product here and go to the product page, so here the screen changed to PROD because now we’re on the Product page. The category code got removed and we now pass in a product code of the product we want to display.
In the last video that we saw, you can pass any url parameter you want and have it become a global variable. So i can do name=brennan and that will work where I can output &name and it will give me the value of brennan. While there’s nothing different or special about any of these built in parameters, this is doing the exact same thing. With store code, screen and product code. The only difference is Miva is looking for parameters with that particular name with Product_Code, Screen or Store_Code. It’s looking for those and if it finds them it will do something based off that. It will pull the right product, pull the right category, or render a certain page. If you take a look here at the add to cart form and inspect the element, all the different elements that are inputting being submitted. So here, when we talk about actions, the action of ADPR, ADPR is the add product to cart action. We also have the store code, product code, category code and a few offsets here that are used for pagination.
All of these hidden inputs work exactly the same as the parameters up here. It’s just telling Miva what to do and where to go. Now there’s more default parameters than just the standard ones we’ve talked about here. But these are a lot of the common ones you’ll see. Once you understand what they are and how they are used, when you come across new ones that you haven’t seen before usually you can figure out by deduction what functionality it provides.