How To Guides

How To Guides

URI Management Documentation

1. Updating to 9.0004

2. URI Management Settings

3. Search Friendly Storefront & Setting your SFNT Canonical URI

4. URI types

5. Adding A Redirect

6. Imports & Exports

7. Removing All URIs For a Resource

8. New Slugified encoding (5.23 engine)

9. Template Code Lookup The Canonical URI

10. Managing 404 Errors

11. Canonical Meta Tag

12. New URL Component Module

13. Setting URI permissions within User Groups

14. Update Your .htaccess Files

*Note: The store must be on CSSUI.

Overview

URI (Uniform Resource Identifier) Management in Miva allows you to control your URL structure across your Miva store. It controls what appears in the browser bar when someone is looking around your site at your products, categories and pages.

A URL is a subset of a URI, however in this context we’re going to use the acronyms interchangeably to refer the the web address displayed in the browser.

Here is an example of a URL in the browser

With the new URI Management features in Miva, you no longer need to produce code or category code in the URL as a unique identifier. Instead the new default is the product name separated by dashes with special characters removed. This is referred to as the “slugified” product name. However, the URI Management tools give you the flexibility to use any URL you wish, not just the product name. You have complete control to setup your URL structure in any format.

1. Updating to 9.0004

If you have an existing Miva store and are upgrading to 9.0004 via the streaming update system it is important to know that on update nothing related to your .htaccess file or URL structure will change. If you wish to use the new URI Management features you will need to explicitly enable them and generate URIs for all your products, categories and pages.

For brand new installations of Miva on 9.0004 or greater the URI Management is the default link source and a slugified product name (or title) is used for the product & category URLs.

2. URI Management Settings

You can find the URI Management tools from the left menu. URIs are managed at the domain level so if you have a Miva store with multiple stores (a Mall) all URIs will be managed under this single location. This means that two stores within a single domain cannot share a URI. You will also need to pick a store to be the default one, by identifying which SFNT page gets the root URI or “/”. Setting a page to just have a slash as its canonical URI will identify to Miva that this page should be the one displayed when someone just types in your domain name.

There is now a drop down to select what system you want Miva to use to generate your URLS.

Long URLs

This is Miva’s default URL with no rewrites used. It relies on parameters passed in the query string of the URL. It looks like this:

http://version9.mivamerchant.net/mm5/merchant.mvc?Store_Code=v9&Screen=CTGY&Category_Code=cat1

Here the Store Code, Screen and Category Code are passed in the query string to tell Miva which store, page and category to load.

Legacy SEO Settings

The “old” SEO settings that have existed in Miva prior to 9.0004 has been renamed to Legacy SEO Settings. These rely on .htaccess rewrites rules to rewrite the long Miva links above into shorter more search engine friendly links.

These required product and category identifiers typically /product/ and /category/ as well as a the product code or category code. Here is an example:

http://version9.mivamerchant.net/category/cat1.html

Here “cat1” is the category code Miva needs to load.

URI Management

This system stores each URI in a database and does a lookup to determine which product, category or page to display at runtime. This flexibility allows you to specify any URL you desire for each of your products without requiring you to include the product code or category code in the URL structure.

This also gives Miva the flexibility to manage 301 redirects for you, without having to write individual redirects into the server configuration file (.htaccess)

URL Prefix

In previous versions of Miva (9.0003 and below) the domain name was used to determine the domain for the URL structure.

Now, in 9.0004 that field still exist, but it is not used to determine the domain name for the URL structure. Instead there is a new URL Prefix field which is used for this purpose:

The optional secure URL Prefix field is only needed if you have a separate secure domain that is different from your normal URL Prefix. This would be used in cases where you have a shared SSL.

Configuring the URI Templates

There are 3 templates you can configure, one for pages, products and categories. These templates are used when generating new URIs for new products, categories or pages. Miva needs to know what format to use each time you add a new product.

The default for all of these templates is to use the “slugified” title and if that is blank then to use the slugified product name. “Slugified” referes to a string where the spaces are replaced with dashes and special characters are removed to make it suitable for a URL

This template is completely customizable so if you can create any custom template you like to match your existing URL structure or modify it however you like. This field fully supports the Store Morph Template language so custom variables or logic can be added.

Options for Updating pages/categories/products

There are 3 options to choose from when updating a product, category or page. This will tell Miva what to do with the URI when a resource is updated.

The default option is Never which mean that if the product title or product name is updated, the URI will not change. You will need to explicitly change the URI if you need it changed.

Add a Non-Canonical URI - If this is selected Miva will leave the existing canonical URI but add a new non canonical URI to the product. This would mean you now have multiple URIs pointing back to the same resource.

Replace Existing Canonical URI - This option allows you to automatically change your canonical URI and also insert a 301 redirect from the old canonical to the new one:

Keep in mind that choosing this setting will cause the URLs to change anytime a product title/name is changed which can cause some negative SEO ramifications.

3. Search Friendly Storefront & Setting your SFNT Canonical URI

In previous version of Miva the way you get your storefront to load when someone visits your root domain is to turn on “Search Friendly Storefront”. Behind the scenes this writes a line into the servers .htaccess file which tells the server to display the SFNT page when someone visits www.domain.com. Here is what that line looks like:

DirectoryIndex /mm5/merchant.mvc?Screen=SFNT&

In the new URI Management system the page that loads when you visit www.domain.com is going to be the page that has a Canonical URI of “/”. You will typically want your SNFT page to load. Because a domain may contain multiple stores, the SFNT page does not get this “/” by default. You need to manually add it. To do this navigate to the store you want to load at the root domain (in the case where you have multiple stores) and go to User Interface, Pages, Edit SFNT, the click the URI tab.

Here you should see this:

You will want to edit the Canonical URL to be just the slash:

This will also ensure the correct Canonical link tag will be output in the page head tag:

4. URI types

When creating a new URI there are a few different types to choose from.

Canonical

Canonical is a term that refers to the authoritative version of something. When we say it is the canonical URL, it means it is the correct URL for that page even if other URLs point to the same page. There can only be a single canonical URL for each page, product and category. This is what will be displayed on the site and used in the canonical link tag in the head.

Normal

A normal URI is just an alternate URI for a product, page or category. It is not displayed anywhere on your website, but if you manually typed it into the browser, it would display the correct resource.

Redirects (301, 302, 303 & 307)

There are 4 types of redirects you can choose from. Each has a slightly different purpose. The majority of the time you will be using a 301 redirect.

301 - Permanent redirect

302 - Temporary Redirect

303 - Redirect for GET request

307 - Redirect for POST request

5. Adding A Redirect

There are two places to add a redirect. It can be done at the product level under the URIs tab or from the URI Management screen. To create a redirect, first select the URI you would like to redirect. You will then see a redirect button appear:

Clicking the redirect button will bring up the following dialog:

Here you can choose where to redirect the product to as well as what type of redirect to implement:

There is no limit to the number of redirects you can set up for a specific product, category or page. The Miva URI button will simply move the URI you have selected to the resource you have designated in the “Redirect To” field.

This powerful feature of Miva allows you to manage all your 301 redirects in Miva and not have to add them to your .htaccess file.

6. Imports & Exports

URIs can be imported and exported via a CSV file which allows you to bulk import URIs quickly and easily. There are two methods to do this:

Via Product / Category Imports - There is a new field in the product import named: CANONICAL_URI. This allows a single canonical URI to be imported for each product and category respectively.

URI Import - There is also a separate URI import module, that allows you to import different types of URIs as well as URIs for pages. Here is what the column headers look like:

Here the STATUS column are the HTTP status codes that should be used in the response.

7. Removing All URIs For a Resource

You should always have a Canonical URL to every product, category and page. However, In the event you delete (accidentally or otherwise) all URIs for a specific resource, Miva will default back to the long link.

8. New Slugified encoding (5.23 engine)

The 5.23 engine allows you to use the slugified encoding on any Miva variable. It is output like this:

&mvts:product:name;

9. Template Code Lookup The Canonical URI

You may need to lookup a products canonical URI if you need to use it in a 3rd party module like toolkit, or power search.

There is a function which can be called via a mvt:do tag to return the canonical URI:

10. Managing 404 Errors

In the event you have a URI does not exist in Miva’s database, Miva will take the user to the NTFD (not found page) and a 404 error will be returned.

You would need to use a tool like Google Webmaster tools in order to determine which resources are going to the not found page and then implement a redirect.

11. Canonical Meta Tag

There is now a canonical link tag that gets output in the head tag of each page. This canonical link tag is used to tell Google and the other search engine the correct or authoritative URL in the event there are multiple URLs to the same product, category or page. Here is what it looks like:

PROD:

CTGY:

All Other Pages:

The first two will output the product or category canonical URI for the specific product or category you are viewing.

The last one uses a new URL component that contains the canonical URL for the page. This variable is a structure and contains different members to output variations of the URL. _self refers to the page that is currently being loaded. :auto will automatically output the http or https version of the URI depending on if the page is setup to be secure.

12. New URL Component Module

9.0004 introduces a new URLs component module to handle all the page URLs across the site.

This item makes available the canonical URL for every page of the store. It does not give you access to individual products and categories. Those URLs are accessible though the product and category components.

On each page load all Pages Canonical URL are loaded into this variable:

It has the format of urls:page_code:modifier

page code - This is the code of the page you wish to access its URL. There is also a special _self page code which always references the page that was loaded.

modifier - There are 4 modifiers which identify how the URL will be output

* 1. :auto - This will toggle between the secure and non-secure url depending on if the page should be secure or not. This can be determined on a per page basis by a new setting at the page level:

Virtual pages such as OINF will always be secure

* 2. :secure - This will always output the secure version of the url

* 3. :rr - This stands for root relative and outputs the link without the http: (ex. //domain.com) A root relative link is allows the browser choose between secure and non-secure based on if the customer is at a secure on non secure URL.

* 4. _sep - All the modifiers above have a version where _sep is appended. This will output the URL with the question mark at the end.

13. Setting URI permissions within User Groups

The URI Management features are very powerful and should only be modified by a developer who knows how they work. URIs have the following Access Control restrictions:

* 1. Global Settings - To be able to view the URI Management settings you must be logged in as an admin user

* 2. Product, Category & Page URIs - restriction to product, category or page level URIs can be limited via User Groups

There are individual access control for Categories, Products and Pages.

Update Your .htaccess Files

There are four sections under the .httaccess tab.

1. Status:

Under the status section it will tell you whether your httaccess rules are current, present, absent or in need of updating. As you make changes under the Legacy SEO Settings, the status will update to inform you where you're at with your rules.

2. Update:

Update .htaccess file with the current settings. This will add Miva Merchant htaccess rules if none are present, or update the existing rules if out of date.

3. Delete:

Delete Miva Merchant htaccess rules from the .htaccess file. This will remove all rules generated by Miva Merchant. If you have modified the Miva Merchant rules, all modifications in the Miva Merchant generated code will be removed.

4. Recall:

Recall .htaccess file. Select a previous version of your .htaccess file from the list below and click Recall to move that version to the current version used by Apache. So here, if you made changes that broke your store or made changes you don't want, you can revert back to previous versions to get your store back where it was.