MIVA Merchant 5.x Module API Tid Bits

This is where we are going to keep bits of information about working with the MIVA 5 API that we feel is important but doesn't fit into any other section. Things may be here and then suddenly vanish as they are moved to new sections created where they become appropriate. If you have any tid-bits to share please feel free to email Jeff Huber and he can decide if they should go here or someplace else on the site.

What happened to stores.d.code and other database values [back]

Developers used to the MIVA Merchant 4.x and previous Module API will quickly notice the absence of some key database values such as stores.d.code, basketlisd.d.cust_id, and others. These values no longer exist because MIVA Merchant is no longer opening xbase data tables and leaving pointers at certain key records. So, since you no longer have access to those data table fields, where can you find the values? Well in the case of the stores table those are now available in a global structure named g.store so you can use g.store:code as a replacement for stores.d.code and there is a global variable called g.basket that has values like g.basket:cust_id that can be used as a replacement for basketlist.d.cust_id.

Understanding the new database schema [back]

Understanding the design of the database that is created can save you a lot of trouble trying to figure out coding problems. One of the best things you can do is to have a copy of the database someplace where you have easy access to it so you can examine the tables and their field names. A great tool to use to help with this is the freely available phpMyAdmin software which is a really great tool for viewing MySQL databases.

If you are using MIVASQL on a given site that doesn't stop you from keeping a separate copy of the data base structure in MySQL. If you install MIVA Merchant 5 using MySQL first you can use phpMyAdmin to dump the entire structure and contents of the data to a file and can use that to import the data into an offline database. Then you can reinstall the software using MIVASQL.

MIVA may at some point release a database diagram that lets you see all the tables and their relationships but even if they do it is not likely to be kept up to date. And you certainly can't run test queries against a database diagram the way you can against a copy of the database.

Some important considerations about the list of features assigned for your module [back]

The list of features for your module is very important. Not only does it determine what function are required and thus when your software can/will be called but determines how administrators can access it to install, uninstall and configure it.

Because a module no longer has a set single type but the MIVA Merchant 5 admin interface still organizes modules based on types so that installation check boxes still appear under System Extension configuration, Payment configuration, etc. This created a real problem in the initial release of MIVA Merchant 5 because the module wouldn't necessarily get installed or uninstalled when the administrator thought it was or should. The ambiguity needed to be addressed badly and MIVA's solution, implemented as of sometime after the PR 2 release, is modules are considered to have a primary feature which is the first installable feature listed in the feature list. This feature controls when the module is installed and uninstalled. A module may now only be installed and uninstalled in the store via the primary feature type admin screen. The other store module record(s) for any additional feature types, excluding components which are dealt with specially, will be added automatically.

For example, assume a module with features of system, shipping, vis_system, vis_shipping, component, data_store. This module is of primary type "system", since this is the first installable feature in the list. It can only be installed or uninstalled from the System Extension Configuration and once installed, will automatically also be installed in the Shipping Configuration. The component feature is excluded from the automatic additional installation because components can be added either as items or item extensions in the store, and can be assigned to pages programmatically during installation.

Note that if the primary feature for a module is the component feature the module won't be able to be installed or uninstalled by the more intuitive method that is familiar to those who have used MIVA Merchant in the past because checking all the boxes anywhere under the normal configuration locations isn't going to do anything. Only when the module is added or removed as an item or item extension will the install and uninstall functions be called and at that time any additional store module records will be created as necessary.

Because the example module has vis_system and vis_shipping, it can be configured in both sections. If vis_system were removed from the list then while the module would still only be installed or uninstalled form the system configurations menu it could only be configured from the shipping menu.

As a developer you should think carefully before deciding which features to include and which one to make primary.