Converting to MMv4: Custom scripts and templates


	Converting to MMv4: Custom scripts and templates
	Last Edited - 02/3/2012 11:12am PST
	Category Path - Editorial > What's new in MMv4

This article reviews the most common pitfalls that are encountered when converting a store's templates. Hopefully, this article will help minimize potential issues that can be caused by items that cannot be translated during the process of converting from version 3 to MMv4.

Customizations made to templates

The most difficult things to update when converting an account from version 3 to 4 are the store's template packages. This is because the entire content of each template can be edited — just like editing any other webpage.

The result is an infinite number of possible template iterations, each containing their own customized HTML, CSS, JavaScript and PHP code. Yikes!

The conversion process attempts to recreate the store's templates as faithfully as possible. However, not every conceivable customization can be accounted for. In our experience, HTML, JavaScript and CSS usually convert seamlessly, but any custom PHP code present in templates will likely not convert seamlessly.

Converting custom PHP code is an issue because MMv4's database and variable structure is completely different than previous versions. Any PHP code that references the shopping cart's database, arrays or variables will need to be updated in order to correctly point to the MMv4 equivalent.

Deprecated QuickCode Tags

MMv4 includes over 700 new and updated QuickCode Tags. Many tags from previous versions have been combined into a single "smart" QuickCode Tag. Others tags have been discontinued or changed to a new tag with a different name. The conversion system will find and update the names of all of the currently supported QuickCode Tags that it finds in templates.

However, the templates in accounts that have been around since version 2 may still contain QuickCode tags that have long since been deprecated. Deprecated QuickCode Tags contain spaces and/or colons.

examples of deprecated quickcode tags

Deprecated QuickCode Tags will contain spaces and/or colons, and may look something like this:

{REALLY OLD QUICKCODE TAG}

{ANOTHER: REALLY OLD ONE}

Deprecated QuickCode Tags such as these are, unfortunately, so outdated that they won't be recognized by the account converter. They will be left as-is in the templates.

After the conversion has been completed, deprecated tags will be displayed {IN RED LIKE THIS} when viewing the storefront. Those templates will then need to be manually updated to change the tags to their current versions.

Guest checkout

The "Guest Checkout" system that was introduced in version 3 has been retired. As such, any Guest Checkout references and links can be removed from the store's templates after converting to MMv4.

reference

"Guest Checkout" has been replaced with the ability to make "passive" customer accounts. Refer to the introduction to customer accounts for info on the similarities and differences between guest checkout and passive customer accounts.

Additional Templates

The system has a specific list of the templates that it will look for and convert. Any template on this list will have its contents — and QuickCode Tags it contains — updated to the MMv4 counterparts.

Any additional templates that have been added (such as additional templates for products, categories or vendors) will be retained, but won't have their contents updated. Those templates will need to be manually updated by the store Admins after the conversion process.

Why aren't the contents of all templates updated?
In MMv4, the QuickCode Tags and other store content, will vary depending on the context in which they are used. For example, the {PRODUCT-NAME} QuickCode Tag needs to know if it is being used on a product page, category page, search results, etc. The converter knows the context of each of the standard templates, and will add/alter the code in each template accordingly.

However, the converter doesn't know which store page custom-made templates are associated with. Thus, it cannot determine their context, and cannot update their contents to match. As a result, a template with a custom name, such as arbor-day-special-45.tpl, will be retained, but its contents won't be updated.

Availability of new features

MMv4 introduces many new features that can be added to templates, such as Product Reviews, Reward Points and 1-Click Upsell options. The conversion process won't add these new features to existing template packages. (The system has no way of knowing where you'd like these features located in your templates, or how their style should be customized.)

Adding new featured to templates:
This knowledge base contains tutorials and code samples on adding each of these new features to templates.

Using pre-made templates with new features:
A suite of new template packages — which include all of these new features — are also available within the MMv4 Administration Area at: [Design > Get Template Packages]. A new template package containing all the new features can be installed from the Get Template Packages page. It can then be set as the store's live template package, or it can be harvested for parts to add to your converted templates.

Custom QuickCode Tags

Any custom QuickCode Tags that are used to store code that's used in templates should be reviewed after the conversion process, and updated if needed.

Saving template content into a Custom QuickCode Tag is a great way to share common code among multiple templates, but it also adds an additional layer of abstraction that the conversion system may not be able to trace its way through.

This means that the converter may not be able to locate and update the contents of custom QuickCode Tags, so they should be reviewed after the conversion process, and updated if necessary.

Also, as with the templates, any custom PHP code present in custom QuickCode Tags will likely need to be updated.

Custom Script Slots

Custom-made scripts that run in the custom script slots (such as the slot at: /txt/CSTM_ckout_per_order_func.php) are not updated during the conversion process. (Due to the completely customizable nature of the custom script slots, it would be impossible to accurately modify their code.)

If your store utilizes Custom Script Slots, then either the original developer of the scripts will need to update them to MMv4's structure, or special arrangements will need to be made with Modular Merchant to hire one of our developers to update them.