To fully understand custom fields and how they work, it's important to understand how custom fields have evolved over the years. In 2013 an update was made to the custom fields functionality that drastically improved its usability, functionality and availability within the page template language. However, it wasn't always this way. I want to talk about what I'm calling the legacy custom fields, which are really just the custom fields prior to 2013 when we released a new version. It's important to understand how custom fields used to work, because the old way of referencing the custom fields still works along side the new way. As a developer, you'll probably see both. The first thing to know with the old custom fields is that they only supported custom product, category and customer fields. There was no concept of a customer basket fields and a custom order fields that we have today. The biggest issue with the older version of custom fields is that they were limited with where you could use them. You could only use them on product lists, so that's the category page, the search page, related products, all products page and the category tree. Because of this limited availability, third party plugins filled that gap and there are modules such as Toolkit and Toolbelt, which have functions that allow you to read and write custom fields on any page within Miva. Another big limitation of the legacy custom fields was that they first had to be assigned to the page in order to use them. Now in theory, this was actually a smart idea. This prevented you from having hundreds of custom fields and loading all that data on the page when in reality you may not need any of it or only one or two.
This is solved in a different way with the new custom fields, which we'll take a look at in the next video. However, this was a common developer gotcha. If you tried to use or reference a custom field on a page and it wouldn't show up, a lot of the times it was because you forgot to assign it to that page first. The other issue with the legacy custom fields was that the syntax you reference it or to call on that custom fields on the page was long and hard to remember. This made it difficult as a developer to use custom fields on any page. What ended up happening is developers developed a reliance on these third party modules, which had functions that could read and write custom fields on any page. That became the standard, versus the built in Miva functions. Let's take a look at the old way of referencing any custom fields within the Miva Admin. Here I am back at the Miva Admin. Let's create a custom field and then see how to call in that custom field on the product page. I'm going to go into utilities where custom fields are located and I'm going to create a new custom field. So let's create a custom product field for msrp. It's going to be a text field, and leave everything else default. So now, let's go give a product a value for that msrp field. I'm going in here to custom fields and I'm going to give this an msrp of $100. So let's say I want to call in this retail price on the product page and display it. Now typically it would be displayed with a line through it and maybe a "you save" and then the regular price. So in order to use this custom field on the product page, you first have to assign it to the page. So that's going to be done under PROD. So I'll go to pages and then the Product page. So now I'm going to go down here to the product display layout. Now you remember what I said earlier is that the legacy version of custom fields could only be used on the display layouts, so the Category Page, Product Page, Search, etc. So, in order to use it you first have to assign it. Here I have a list of all the custom fields. You'll see my retail price here. This first needs to be selected. It needs to be on the box to the right. This means that whenever this page loads, whenever the product page loads, it will load the retail price custom field as well. One real important thing here, since this template has never been edited, here you can see I am at the original version of this template, any time you add a custom field to the page, Miva will automatically insert the code for you if you call in that custom field. Now this is a nice feature of Miva. However, most of the time, this page is not going to be default. If you've made any changes to it where it's not default, Miva will not automatically add this code to the page. You will actually have to manually go through and add the code where you want the custom field to appear. So let's update this. It should automatically add this custom field to the page. So I'm going to scroll back down and I'm going to go into Advanced Mode. This shows us the template code behind this product display layout. Now, if I scroll down here, and look, you'll see that it added this code. This is the code that calls in the msrp custom field that we created. Let me take it into our text editors so we can dive in a little bit closer. So here's the code that Miva automatically generates for you. Now again, this code will only be generated if that template is in its original format. Otherwise when you assign a custom field to the page, you have to manually add this code. That's important to remember. So you see it's going to check to see if a custom field is not null and you'll notice immediately off the bat the syntax is not very pretty. It's long, complex and hard to remember. It's in the l.settings structure, within the product structure and there's a custom field_values, custom fields:msrp. Now, not much of a chance of remembering that entire syntax. which is one of the reasons why the built in custom fields were so hard to use. So it outputs a div and within that div is the name of the custom field msrp, and then a colon, and the value, which is contained with custom fields_values:customfields:msrp;. So that's what outputs both the name and the value for that custom field. It's quite a bit of syntax which is one of the reasons why it was so hard to use.
Jumping back over to the front end of Miva, if we go and look at the product page and I pull up this product, you'll see that this retail price or custom field was automatically added to the page template. That code is what's outputting this to the page. Now that code can be added anywhere on the page. It doesn't have to be right here. However you could not use that code on say the storefront page. This was one of the big limitations of Miva's legacy custom fields. Let's jump back to the Miva Admin here real quick. So, a quick recap, the legacy custom fields must first be assigned to the page in order for you to use it. That's done from taking a custom field from this box and moving over to the box to the right. That will tell Miva to load all the data for that custom field when the page loads. The second important thing to remember is that there's limited availability of where you can use this custom field code. Miva will automatically generate it for you if the template is in its original state. Otherwise you'll have to manually add it yourself. It can only be used on certain pages. To solve these problems and more we released a comprehensive update to the custom fields functionality. Not only from the admin perspective, but also from the point of using the custom fields within the page templates. In the next video we're going to talk about the new custom fields, or just how custom fields exist today. However, it's important to note, that the legacy version of custom fields exists alongside the new version of custom fields and all the new functions we're going to look at. You can use both. At the end of the day the custom functionality is exactly the same. The difference between the two versions is how you call them in to the page templates. The legacy version has verses the benefits the new custom fields functions and all the functionality they provide.