Perhaps one of the most challenging configuration aspects of the SEO-G module are the supported Types. Each type the SEO module support is effectively a parameter to be decoded for a friendly URL. Categories, Products, Manufacturers are the fundamental parameters and each one has an SEO-G type behind it to support it.

Available from the Administration Panel -> SEO-G -> G-Types the page shows several entries following a proper installation procedure. Here will examine the operation and requirements to setup the SEO-G for the types applicable for an e-shop. Figure-1 indicates the access path for the SEO-G types via the administrator panel.

Figure-1 SEO-G Types Access

Now lets take a look on the generated SEO URL components by SEO-G. Figure-2 shows a basic URL along with the use of the prefix and subfix fields. The critical component in the example of figure-2 is the products name itself. The product name "car" in this case will be listed for every one of the handlers. The name itself is driven by the products identifier. A record for the products name is located in the products_description database table along with the products_id. It is the way the web-engine components can retrieve the vital information to service the client's request.

Figure-2 SEO-G URL Components

Each URL breaks down in several components. The first 2 Transport and Domain are part of every URL. The Prefix, Entity's name (products name in the example), Subfix and Extension are handled by the SEO-G Module. By the term entity name we mean the various entities the module can handle. Such entities imply products, categories, manufacturers along with every other custom one SEO-G may have in place. The prefix and subfix fields are optional and are discussed in detail later. The extension can be setup via the SEO-G configuration options, SEO-G extension. Lets now see how these components are associated and mapped with the SEO-G Types.

There are 9 columns for the SEO-G types page. Each of these is analyzed here:

1. Entries Checkbox
The checkbox is the first column of the list and must be set/ticked for entries to be deleted or updated. Any action that is driven by the delete or update buttons processes the entries that are set/ticked.

2. Name
This optional entry is used so the operator can remember the purpose of each entry. The name of an entry will show under the list of the G-Controller. It has no operation on the catalog end or for the URL structure.

3. Handler
The handler entry represents what files/php scripts from the catalog side of the e-commerce store are used and target the original URL parameters. The handler is a critical component of the SEO-G and to understand the purpose of it lets examine two different files that handle the products_id parameter. One is product_info.php, the other is product_options.php. Both php scripts handle the products_id parameter for links that will be generated by the SEO-G. (although there is no product_reviews_info.php with the I-Metrics layer it is simply mentioned here to explain its usage). SEO-G needs to know the scripts authorized to handle the products_id. Without a handler SEO-G would either had to accept any script (which is not secure) or a hard-coded value for the scripts had to be in place. Therefore it's important to store the handlers SEO-G needs to manage.

Figure-3 SEO-G Handler Processing

The handler list is a coma separated list that identifies the catalog php files handling a parameter. For the osCommerce engine and the I-Metrics layer the primary handler is the product_info.php. The primary handler is not stated because we need the minimum name being generated for the products_id. The minimum length of the product name by default is extracted from the products_name column of the products database table. When a handler is present, SEO-G will prefix or append at the end of the name the prefix and subfix values of the same entry (see below prefix and subfix paragraphs). Subfix and Prefix are also coma separated lists. 

The following figure illustrates how the handler list is processed in SEO-G.

Since the product_info.php is the main script that processes the products, there is no reason to be listed with the handlers. Also note the secondary handlers should be used for pages that indirectly related to the primary handler. You should not use the subfix and prefix for general pages as it will cause problems for the generated URLs. For instance deploying a menu with secondary handlers that is listed on all pages will bring up the wrong URLs as the SEO-G class will generate links based on the primary handler.

SEO-G is designed to generate the shortest URL possible and so the primary scripts need only the entity/identifier to be passed. We could had listed the product_info.php with a prefix and subfix but then the default products URLs will all have a prefix and subfix and it would have been the same for all products. Handlers should be provided so the module can distinguish between the scripts and consequently a different URL can be generated. In any case the prefix and subfix that correspond to a handler should represent keywords of the marketing campaign.

If a handler is listed and the subfix or prefix is blank SEO-G will not append anything to the URL and will treat the entry as the default/primary one. Therefore you must ensure for each handler either a prefix or subfix or both are defined.

4. Handler Subfix and Prefix

These 2 fields are subject to the handler settings and are optional. Both can be set as a coma separated list of keywords. Each keyword must correspond to a valid handler. If we setup 3 handlers for an entity because we have 4 scripts that handle the entity, each of  the subfix/prefix fields can be up to 4 keywords and each list of keywords must be separated by a coma. SEO-G during URL generation will extract the prefix prepend the URL for the corresponding script and ammend the URL with the given name from the subfix list.

5. Linkage and Sort Order with SEO-G Types

Linkage and Sort Order are settings dependent on each other. When the Linkage of 2 or more entities is the same the sort order has special meaning for the SEO-G module. The sort order instructs the module in which order to process the entities. The Linkage value behaves like a group mechanism for entities. By setting the linkage to the same value we can concatenate multiple entities together if and only if a script parses these entities together.

For instance the index.php script is the file that handles the categories listings with the stock code. When the listings are invoked for a specific category an additional filtering mechanism can be applied by default via the manufacturers id. Therefore if we setup the categories and manufacturers for the SEO-G types to have the same linkage value both entity names will be recorded and presented with the friendly URLs. In which case the sort order will define which entity will show first with the finalized link. Figure-4 demonstrates the Sort Order importance when the Linkage is identical for 3 entities.

The Linkage is critical for the URL structure inside the e-shop. Not only can shift the keyword exposure of the URLs in a certain way but it can also present the e-commerce store with a specific hierarchy. We could setup a store to operate just with manufacturers and products. Each product is assigned a manufacturer and every manufacturer can then appear as a category. We may want to position the URLs in this way as the keywords for the manufacturers are of greater importance than the keywords of categories.

The URL structure is subject to support functions and scripts a store has in place. If we group multiple entities by setting the linkage to the same value but not having the necessary support in place SEO-G will be unable to detect all entities for each URL. The problem is while with categories listings the tep_href_link function is called with the category and product entity, with the new products, specials and other script it is called just with the products entity. Unless you have a thorough understanding of the module and of the scripts in place you should leave the SEO-G defaults to take care of the URLs.

6. Class

The Class field specifies which class file on the administration end will handle the entity. Each of the entities has a class because the information stored in the database for a product, category and so forth needs to be extracted and stored separately with a different name that can be edited by the administrator. This provides flexibility for developers as they can create virtually any class for any entity the e-commerce store supports.

When a new class is added inside the SEO-G types an entry in the SEO-G controller appears with the name of the type and it invokes the class as defined in this list. Unless you have developed new classes do not attempt to insert new SEO-G types.

7. Status Controls

Finally the status lamps allow the administrator of the e-shop to enable or disable the SEO-G types. When a type is disabled there is no processing of the entity by SEO-G. The parameter the entity represents is treated as any other unknown parameter and is left to the main tep_href_link() function for processing.