Zen Cart Documentation – Admin

Dev: Admin Request Sanitization

Mon, 01 Jan 0001 00:00:00 +0000

The Admin Sanitization features use a number of sanitization groups. Each group performs a sanitization on specific GET/POST parameters. For GET/POST parameters that are not already sanitized within these groups we then run a default sanitization (i.e.: simply running htmlspecialchars() on it).

Why Sanitize?

Historically, weaker sanitization was used for two reasons:

Firstly, Admin allows lots of parameters to include what would be considered dangerous characters. e.g. product descriptions allow script tags, and other inputs allow some html, such as product names.

Secondly, core code uses CSRF tokens for all form interactions. The use of these tokens mitigates against any exploiting of XSS, unless an admin session is already available.

However, reports such as https://www.trustwave.com/Resources/SpiderLabs-Blog/TWSL2016-006--Multiple-XSS-Vulnerabilities-reported-for-Zen-Cart/ made us reconsider. While we still contend that the CSRF protection mitigates these supposed XSS vulnerabilities, there are three good reasons to address them with extra sanitization:

We cannot guarantee that 3rd party plugins use the CSRF token system (although there are some safeties to ensure they do).
PCI scanning software may detect XSS vulnerabilities, even given the CSRF mitigation. (particularly where the scanner bypasses/grants admin logins)
Good security practice.

TEMPORARILY Disabling Strict Sanitization

If you find that some of your pre-v1.5.5 admin plugins are no longer working properly then you should look first to see if new versions of those plugins are available, i.e.: that support the sanitization methods implemented since v1.5.5.

If new versions are not available, or you need to keep your current admin working while you update, then you can disable the strict(default) sanitization by doing the following:

Create a new disable_strict_sanitize.php file in your /admin/includes/extra_configures/ directory. The contents of this file should be

  <?php
  define('DO_STRICT_SANITIZATION', false);

We encourage you to NOT do that unless truly necessary, and even then only as a temporary measure until your affected plugins have written their own custom sanitizers as described later in this document.

Logging

The AdminSanitizer class can log the actions it takes, and this may be helpful in debugging problems with plugins.

Logging is enabled/disabled using the DO_DEBUG_SANITIZATION define.

To enable logging create a new file in /admin/includes/extra_configures/ that contains

  <?php
  define('DO_DEBUG_SANITIZATION', true);

For Developers. How to use the sanitization in plugins.

If you are a developer who wants to update your current code, or you are developing a new plugin, the following are some tips to keep your plugin compatible with core functionality.

Parameter Naming

GET/POST parameters will be sanitized based on their parameter name and the sanitization group assigned to them. Therefore, if you are writing a plugin and use a parameter name that already exists in Zen Cart that parameter will be sanitized according to the group it is already assigned to in core code.

For example, the action parameter is assigned to the SIMPLE_ALPHANUM_PLUS group, and the sanitization for that group will always be applied to it.

There will be occasions where a plugin uses a parameter name that is already added to a sanitization group, and rewriting plugin code may be onerous. For these cases it is possible to override sanitization on a per page basis.

Adding Parameters/Groups

If a plugin needs to define its own sanitization or override the sanitization for an already defined parameter, it should create a php file in /admin/includes/extra_datafiles/

An example of the contents might be

$sanitizer = AdminRequestSanitizer::getInstance();
$group = array(
    'id' => array('sanitizerType' => 'CONVERT_INT', 'method' => 'both', 'pages' => array('edit_orders'), 'params' => array()),
    );
$sanitizer->addComplexSanitization($group);

$sanitizer = AdminRequestSanitizer::getInstance();
$group = array(
  'col_html_text' => array('sanitizerType' => 'PRODUCT_DESC_REGEX', 'method' => 'post'),
    );
$sanitizer->addComplexSanitization($group);

The structure of the defining array is:

sanitizerType = The name of a sanitizer group (see the group names below)
method = get|post|both
pages = (optional) an array of pages which this sanitizer rule will be applied to; (if not supplied, will apply to all pages)
params = (optional) this is used only for the MULTI_DIMENSIONAL sanitizer, which is explained below.

Here’s a specific example from the News Box Manager plugin. The file admin/includes/extra_datafiles/news_box_manager_sanitization.php sanitizes the fields news_title and news_content when they are updated:

if (class_exists('AdminRequestSanitizer') && method_exists('AdminRequestSanitizer', 'getInstance')) {
    $news_mgr_sanitizer = AdminRequestSanitizer::getInstance();
    $news_mgr_sanitizer->addSimpleSanitization('PRODUCT_DESC_REGEX', array('news_title', 'news_content'));
}

The pages parameter is not specified here because this particular plugin is designed for easy extension, so that pages can be added simply by copying a single file (and requiring someone to modify this file as well to add the new page would be contrary to that intention.)

General Sanitization Groups

Zen Cart defines the following default case-insensitive sanitizers:

SIMPLE_ALPHANUM_PLUS

GET and POST Values

Uses [^\/ 0-9a-zA-Z_:@.-] regex
CONVERT_INT

GET and POST values

converts value to Integer
FILE_DIR_REGEX

POST values only

uses [^0-9a-z.!@#$%^&()_-~`+^ \\] regex
ALPHANUM_DASH_UNDERSCORE

GET and POST values

Uses [^a-z0-9_-] regex
WORDS_AND_SYMBOLS_REGEX

GET and POST values

Uses (<\/?scri|on(load|mouse|error|read|key)(up|down)? ?=|[^(class|style)] ?= ?(\(|")|<!) regex
META_TAGS

POST Values only (Deep)

Uses htmlspecialchars($_POST[$parameterName][$pKey], ENT_COMPAT, $this->charset, false)
SANITIZE_EMAIL

GET and POST values

Uses filter_var($_POST[$key], FILTER_SANITIZE_EMAIL)
SANITIZE_EMAIL_AUDIENCE

POST values only

Uses htmlspecialchars($_POST[$parameterName], ENT_COMPAT, $this->charset, true)
PRODUCT_URL_REGEX

POST values only (Deep)

Uses ([^0-9a-z'.!@#$%&()_-~/;:=?[]]|[><]) regex
PRODUCT_DESC_REGEX

POST Values only (Deep)

Uses (load=|= ?\(|<![^-]) regex
CURRENCY_VALUE_REGEX

POST Values only

Uses [^a-z0-9_,\.\-] regex
FLOAT_VALUE_REGEX

POST Values only

Uses [^0-9,\.\-\+] regex
PRODUCT_NAME_DEEP_REGEX

POST Values only (Deep)

Uses (<\/?scri|on(load|mouse|error|read|key)(up|down)? ?=|[^(class|style)] ?= ?(\(|")|<!) regex
NULL_ACTION

GET/POST Values

Skips sanitization for the relevant parameter.
STRICT_SANITIZE_VALUES

Any parameters not previously sanitized will be sanitized with this method.
STRICT_SANITIZE_KEYS

All POST and GET “keys” containing any < or > symbols in the key will be unset()

MULTI_DIMENSIONAL Sanitization

The MULTI_DIMENSIONAL sanitizer is special in that it defines sanitization for an array of parameters, rather than one parameter as other sanitizers do.

For example, if you post the following array

[update_products] => Array
    (
        [13] => Array
            (
                [qty] => 1
                [name] => Microsoft IntelliMouse Explorer
                [onetime_charges] => 0.0000
                [attr] => Array
                    (
                        [3] => Array
                            (
                                [value] => 11
                                [type] => 0
                            )

                    )

                [model] => MSIMEXP
                [tax] => 0
                [final_price] => 70.95

normal sanitizers would only address the outer update_products parameter, while what you really want to do is define parameters for qty name onetime_charges etc, and you also want to sanitize the attr sub array recursively.

to address this, you can define a MULTI_DIMENSIONAL sanitizer like this:-

$sanitizer = AdminRequestSanitizer::getInstance();
$group = array(
    'update_products' => array(
        'sanitizerType' => 'MULTI_DIMENSIONAL',
        'method' => 'post',
        'pages' => array('edit_orders'),
        'params' => array(
            'update_products' => array('sanitizerType' => 'CONVERT_INT'),
            'qty' => array('sanitizerType' => 'CONVERT_INT'),
            'name' => array('sanitizerType' => 'WORDS_AND_SYMBOLS_REGEX'),
            'onetime_charges' => array('sanitizerType' => 'CURRENCY_VALUE_REGEX'),
            'attr' => array(
                'sanitizerType' => 'MULTI_DIMENSIONAL',
                'params' => array(
                    'attr' => array('sanitizerType' => 'CONVERT_INT'),
                    'value' => array('sanitizerType' => 'CONVERT_INT'),
                    'type' => array('sanitizerType' => 'CONVERT_INT')
                )
            ),
            'model' => array('sanitizerType' => 'WORDS_AND_SYMBOLS_REGEX'),
            'tax' => array('sanitizerType' => 'WORDS_AND_SYMBOLS_REGEX'),
            'final_price' => array('sanitizerType' => 'WORDS_AND_SYMBOLS_REGEX'),
        )
    )
);
$sanitizer->addComplexSanitization($group);

Note that sanitizers for sub parameters are defined in the params array and that you can recursively define deeper arrays with a further MULTI_DIMENSIONAL sanitizer array.

Custom Sanitizers

tbd

Dev: Admin cron jobs

Mon, 01 Jan 0001 00:00:00 +0000

Cron is a utility on Linux hosting accounts that allows you to automatically schedule jobs to run at specific intervals. An example of a job you might want to run is the exchange rate updater.

What if you want to create your own custom cron job?

The easiest way to do this is simply to follow the example of the exchange rate updater. The key points to note are as follows:

Copy the file admin/currency_cron.php to admin/my-script_cron.php Change the references to currency_cron to my-script_cron, and call your own function in place of zen_update_currencies.
Copy the file admin/includes/auto_loaders/currency_cron.core.php to admin/includes/auto_loaders/my-script_cron.core.php Change the inclusion of localization.php to your own functions file.

Now you are ready to create a cron job in your hosting company’s control panel to run the update automatically on a scheduled basis. The command to give it is as follows. Work with your hosting company’s tech support team if you need help with determining the correct path and the correct php binary to call.

php /full/server/path/to/admin/my-script_cron.php

Existing Cron Jobs within Zen Cart

admin/products_cron.php (added in 2.2) will allow you to activate products at a time of your own choosing. Note that if you use this feature, you will want to set Admin > Configuration > Stock > ENABLE_DISABLED_UPCOMING_PRODUCT to Manual.
admin/currency_cron.php will allow you to update your store’s exchange rates.

Dev: Admin Templating Capability

Mon, 01 Jan 0001 00:00:00 +0000

In Zen Cart v1.x.x, the Admin section is driven by pages that combine a lot of business logic with presentation logic. That is, there isn’t much of a “template” system, especially when compared to the Storefront side of the application.

While it embraces an MVC structure, it doesn’t currently fully separate presentation from backend logic.

That said, since v1.5.7 many (v1.5.8 expands it to all) admin pages support some degree of per-page CSS and JS file inclusion. (This is driven by the use of admin_html_head.php instead of directly outputting all the <head> tag content directly within the page itself.)

In the examples below, PAGENAME and pagename refer to either the cmd=pagename value or the /admin/pagename.php value, depending on the page/URL.

Per-Page CSS Files

You may put your custom CSS for individual Admin pages into page-specific files that will automatically load on those pages.

The convention (and loading order) is:

/YOURADMIN/includes/css/stylesheet.css (this is a core file, but is loaded on every page; only edit if your changes are for everywhere)
/YOURADMIN/includes/css/PAGENAME.css
/zc_plugins/plugin_path...../admin/includes/css/global_stylesheet.css
/zc_plugins/plugin_path...../admin/includes/css/PAGENAME.css
/YOURADMIN/includes/css/PAGENAME_*.css (note the _, followed by additional characters) (THIS IS WHERE YOU PUT YOUR CUSTOM CSS)

It is a good practice to put your own page-specific customizations into a non-core file (eg: pagename_mystore.css) so that there are fewer file conflicts when upgrading.

Plugins not using the zc_plugins structure should put their page-specific CSS additions into a file using a naming convention akin to: pagename_pluginname.css

Per-Page JS Files

You may put your custom JavaScript for individual Admin pages into page-specific files that will automatically load on those pages.

The convention (and loading order) is:

/YOURADMIN/includes/javascript/PAGENAME.js
/YOURADMIN/includes/javascript/PAGENAME.php
/zc_plugins/plugin_path...../admin/includes/javascript/global_jscript.php
/zc_plugins/plugin_path...../admin/includes/javascript/global_jscript.js
/zc_plugins/plugin_path...../admin/includes/javascript/PAGENAME.php
/zc_plugins/plugin_path...../admin/includes/javascript/PAGENAME.js
/zc_plugins/plugin_path...../admin/includes/javascript/PAGENAME_*.php (note the _, followed by additional characters)
/zc_plugins/plugin_path...../admin/includes/javascript/PAGENAME_*.js (note the _, followed by additional characters)
/YOURADMIN/includes/javascript/PAGENAME_*.js (note the _, followed by additional characters)
/YOURADMIN/includes/javascript/PAGENAME_*.php (note the _, followed by additional characters)

It is a good practice to put your own page-specific customizations into a non-core file (eg: pagename_mystore.js) so that there are fewer file conflicts when upgrading.

Plugins not using the zc_plugins structure should put their page-specific custom JavaScript into a file using a naming convention akin to: pagename_pluginname.js

Site Specific Overrides

Starting in Zen Cart 1.5.8, an admin site-specific override capability exists.

Customizing your Admin

Dev: Building a Home Page widget

Mon, 01 Jan 0001 00:00:00 +0000

Creating a widget of your own is just a matter of modifying admin/index_dashboard.php and adding in your logic. For example, one store wanted to monitor orders in a specific status, and make them visible on the home page. Here’s what they did:

    <div class="reportBox">
        <div class="header"><?php echo "Held Orders"; ?> </div>
        <?php  $orders = $db->Execute("SELECT o.orders_id AS orders_id, o.customers_name AS customers_name, o.date_purchased AS date_purchased, ot.text AS order_total FROM " . TABLE_ORDERS . " o LEFT JOIN " . TABLE_ORDERS_TOTAL . " ot ON (o.orders_id = ot.orders_id and class = 'ot_total') WHERE orders_status = 7 ORDER BY orders_id DESC");

        if ($orders->EOF) {
          echo '              <div class="row">No Held Orders</div>' . "\n"; 
        } else { 
          while (!$orders->EOF) {
            echo '              <div class="row"><span class="left"><a href="' . zen_href_link(FILENAME_ORDERS, 'oID=' . $orders->fields['orders_id'] . '&action=edit&origin=' . FILENAME_DEFAULT, 'NONSSL') . '" class="contentlink"> ' . $orders->fields['customers_name'] . '</a></span><span class="center">' . $orders->fields['order_total'] . '</span><span class="right">' . "\n";
            echo zen_date_short($orders->fields['date_purchased']);
            echo '              </span></div>' . "\n";
            $orders->MoveNext();
          }
        }
        ?>
    </div>

A plugin called Orders in Status Dashboard Widget can be used to build something similar for your site.

Dev: Building a Report

Mon, 01 Jan 0001 00:00:00 +0000

Adding a custom report to your site’s admin is a common customization.

The easiest way to do this is simply to follow one of the built-in examples. We’ll use the Products Low Stock report.

There are two files that make up this report:

admin/stats_products_lowstock.php
admin/includes/languages/english/stats_products_lowstock.php

Copy those files to files with names that match the data shown on the report. For example, if the report is designed to show products with zero weight, call the new files:

admin/stats_products_zero_weight.php
admin/includes/languages/english/stats_products_zero_weight.php

Then edit the new code file admin/stats_products_zero_weight.php and change the query to do what you want. In our case, the query for products with zero weight might be:

            $products_query_raw = "SELECT p.products_id, pd.products_name, p.products_quantity, p.products_type
                                   FROM " . TABLE_PRODUCTS . " p,
                                        " . TABLE_PRODUCTS_DESCRIPTION . " pd
                                   WHERE p.products_id = pd.products_id
                                   AND p.products_weight = 0 
                                   AND pd.language_id = " . (int)$_SESSION['languages_id'] . "
                                   ORDER BY pd.products_name";

You may need to make other changes to this file of course depending on your needs.

Then edit the new language file admin/includes/languages/english/stats_products_zero_weight.php and change the title, then make any other appropriate changes.

You can now run your report using the URL

https://MYSTORE.com/MYADMINNAME/index.php?cmd=stats_products_zero_weight

but you don’t see it in the dropdown Admin > Reports. Why not?

The answer is, it needs to be added to the admin pages table, which requires some defined constants. If you look at any of the reports in the Plugins area, you’ll see how this is done. We will look at Disabled Products Report to see one example:

This report creates a third file called admin/includes/extra_datafiles/products_disabled.php. So create your own file, using the naming convention above, called admin/includes/extra_datafiles/products_zero_weight.php.

You’ll want the contents to be something like:

<?php
define('FILENAME_ZERO_WEIGHT','stats_products_zero_weight');
define('BOX_REPORTS_ZERO_WEIGHT','Zero Weight Report');

Now you have to populate the database with these constants so the system knows to show this option in the Reports dropdown.

You can provide an external SQL and run it by hand in Admin > Tools > Install SQL Patches, as this report does.

The query would be something like

INSERT INTO admin_pages (page_key, language_key, main_page, page_params, menu_key, display_on_menu, sort_order) VALUES ('productsZeroWeight', 'BOX_REPORTS_ZERO_WEIGHT', 'FILENAME_ZERO_WEIGHT', '', 'reports', 'Y', 500);

alternately, you can run this query in a file in admin/functions/extra_functions automatically, to make installing this report easier. It’s your choice.

Dev: Creating a new Admin menu item

Mon, 01 Jan 0001 00:00:00 +0000

Let’s say that you have a new tool (plugin, addon, etc) named new_tool.php that you want to plug into the Tools menu.

Most of the files that you distribute in the new_tool.zip file are identical with previous Zen Cart versions:

/YOUR_ADMIN/new_tool.php. Contains the code that implements your new tool.
/YOUR_ADMIN/includes/extra_datafiles/new_tool_filenames.php. Contains the filename (without extension) definition for your new tool, e.g. define('FILENAME_NEW_TOOL', 'new_tool');.

Be careful to leave off the .php extension when doing this.
/YOUR_ADMIN/includes/languages/english/extra_definitions/new_tool_name.php. Contains the menu entry text definition for your new tool, e.g. define('BOX_TOOLS_NEW_TOOL', 'New Tool');. Can be repeated as multiple files for additional languages if needed.
/YOUR_ADMIN/includes/languages/english/new_tool.php. Contains the language-specific defines for your new tool; the filename of the language file must be the same as the filename of the tool itself. Multiple language files may be used.
To install the actual menu entry, you can use either one file to do the install without any messages being displayed, using /YOUR_ADMIN/includes/functions/extra_functions/init_new_tool.php, or if you want to display a message indicating that your tool has been installed, you’ll need two files (/YOUR_ADMIN/includes/auto_loaders/config.new_tool.php and /YOUR_ADMIN/includes/init_includes/init_new_tool.php instead of the extra_functions file):

The config.new_tool.php file will contain something similar to:

$autoLoadConfig[200][] = array(
    'autoType' => 'init_script',
    'loadFile' => 'init_new_tool.php'
);

In either case, the init_new_tool.php will contain something like:

if (!defined('IS_ADMIN_FLAG')) {
    die('Illegal Access');
} 

//----
// Register the New Tools tool into the admin menu structure.
//
// NOTES:  
// 1) Once this file has run once and you see the Tools > New Tool link in the admin
// menu structure, it is safe to delete this file (unless you have other functions that
// are initialized in the file).
// 2) If you have multiple items to add to the admin-level menus, then you should 
// register each of the pages here, just make sure that the "page key" is unique or 
// a debug-log will be generated!
//
if (function_exists('zen_register_admin_page')) {
    if (!zen_page_key_exists('toolsNewTool')) {
        zen_register_admin_page(
            'toolsNewTool', 
            'BOX_TOOLS_NEW_TOOL', 
            'FILENAME_NEW_TOOL',
            '' , 
            'tools', 
            'Y'
        );

        // Optionally display a message here, using the $messageStack
        $messageStack->add_session(BOX_TOOLS_NEW_TOOL . ' installed', 'success');
    }    
}

The value toolsNewTool is a (hopefully) unique value that identifies your new tool.
The values BOX_TOOLS_NEW_TOOL and FILENAME_NEW_TOOL are defined within the other files within your toolset.
The fourth parameter (’’) has any parameters that your tool might require. Rarely used, except when you’re adding a configuration-page element.
The fifth parameter ('tools' in the example) identifies which of the high-level menu items your tool “attaches” to, one of: configuration, catalog, modules, customers, taxes, localization, reports, tools, gv, access, or extras.
The sixth parameter (‘Y’) identifies whether (‘Y’) or not (‘N’) to display the page on the admin menu.
The seventh (optional) parameter is the sort order for the page, i.e. where it lives on the drop-down menu in relation to the sort order of others. Leave this entry empty and the function will place new_tool at the bottom of the selected menu dropdown.

To remove your menu item, in the case a store-owner chooses to un-install your plugin, simply include a file in your distribution zip-file named /uninstall_new_page.sql that contains

DELETE FROM admin_pages WHERE page_key = 'toolsNewTool';

Notes:

Instead of distributing the init_new_tool.php file, you could include instructions to install using the Admin Access Management > Admin Page Registration tool.
1. Set Page Key to toolsNewTool
2. Set Page Name to BOX_TOOLS_NEW_TOOL
3. Set Page File Name to FILENAME_NEW_TOOL
4. Leave Page Parameters blank
5. Select “Tools” from the Menu dropdown
6. Check the Show on Menu box
7. (optional) Set the Sort Order value to position your new tool on the displayed menu dropdown.
If you don’t see your newly added item, it’s likely somewhere in the middle of the menu’s dropdown list.
Use 999 (or any other large number) for the sort order value if you want to ensure that your item is at the bottom of the menu’s list.
To reposition an item within one of the admin menus, use your cPanel’s phpMyAdmin tool and browse the admin_pages table to find the added menu item and adjust its sort_order value as desired.

One thing NOT to do!

Rather than simply using the call toolsNewTool to see if the menu entry has already been added, some developers will delete the registration file.

@unlink(DIR_WS_INCLUDES . 'functions/extra_functions/somescript_admin_page_reg.php');

PLEASE don’t do this. If you do, it becomes difficult to create copies of the site for testing. Instead, simply test the existence of whatever you’re trying not to re-do. For example, to see if an admin menu exists, use zen_page_key_exists.

Rather than write code as shown above, some developers prefer to provide a SQL file that can be run from Admin > Tools > Install SQL Patches.

INSERT INTO admin_pages (page_key, language_key, main_page, page_params, menu_key, display_on_menu, sort_order) VALUES ('mod_list', 'BOX_TOOLS_MOD_LIST', 'FILENAME_MOD_LIST', '', 'tools', 'Y', 999);

The advantage of this approach is that it’s a one time operation with no checking overhead in the future.

Still others simply point users to the Admin Page Registration page. Note that this approach is not encouraged.

Using the Encapsulated Plugin Manager

For developers targeting 1.5.7 and above, the encapsulated plugin architecture is the new standard. For details on SQL actions in encapsulated plugins, see Plugin SQL Installation.

Dev: Sorting an Admin menu

Mon, 01 Jan 0001 00:00:00 +0000

Top Level Menus (Configuration, Tools, etc.)

By default, the list under each of the main admin menu titles (Configuration, Catalog, Modules etc…) are ordered according to each menu items sort_order in the database (which is set on initial installation). However, it is possible to alpha-sort these entries which may be more desirable as they often become extended with Plugins.

In Zen Cart 1.5.8 and above, this functionality is controlled in the admin main language file, eg. admin/includes/languages/lang.english.php

In Zen Cart 1.5.7, this functionality is controlled in the admin main language file, eg. admin/includes/languages/english.php

The constant which is set in these files is

MENU_CATEGORIES_TO_SORT_BY_NAME

which sets a comma-separated list of the menu_key values to be sorted alphabetically. (Note these values come from the admin_menus database table.)

The default value of the constant MENU_CATEGORIES_TO_SORT_BY_NAME is reports,tools, which means the Reports menu and the Tools menu are all sorted alphabetically. To sort more menus alphabetically, add the desired menus to this list.

eg: 'configuration,catalog,modules,customers,taxes,localization,reports,tools,gv,acccess,extras'

Under the Configuration menu (My Store, Minimum values etc,), the list in each submenu can also be alphasorted.

Zen Cart 1.5.8

In release 1.5.8 and forward, the new constant CONFIGURATION_MENU_ENTRIES_TO_SORT_BY_NAME is used to determine which submenus are sorted by adding a comma-separated list of the configuration IDs (gID) of each submenu, e.g. ‘1,2,3,4’ etc

The gID of each submenu can be ascertained by hovering the cursor over each submenu item and noting the number of the final parameter gID of the link,

eg. for Minimum Values: https://MYWEBSITE/MY_ADMIN/index.php?cmd=configuration&gID=2

The default value of this constant is ‘1’, which means that by default, only Configuration > My Store is alphabetically sorted; other configuration menus are sorted according to the sort_order value of each entry in a configuration group.

Zen Cart 1.5.7

In release 1.5.7, to sort a Configuration submenu listing (such as My Store) by name, admin/configuration.php must be modified manually to check for the gID of the desired menu and alter the SELECT query at the start of the tbody, to ORDER BY configuration_title instead of ORDER BY sort_order for that menu.

Dev: View Builders

Mon, 01 Jan 0001 00:00:00 +0000

These are a set of classes used to aid the rapid development of pages/views that display tabular data.

Initially they are meant to aid in the building of admin pages, however some aspects will also be able to be used catalog side as well.

The structure of view builder classes and the data formats they use allow for much easier integration with plugins that need to add extra columns or actions in admin pages.

Zen Cart Documentation – Admin

Dev: Admin Request Sanitization

Why Sanitize?

TEMPORARILY Disabling Strict Sanitization

Logging

For Developers. How to use the sanitization in plugins.

Parameter Naming

Adding Parameters/Groups

General Sanitization Groups

MULTI_DIMENSIONAL Sanitization

Custom Sanitizers

Dev: Admin cron jobs

Existing Cron Jobs within Zen Cart

Dev: Admin Templating Capability

Per-Page CSS Files

Per-Page JS Files

Site Specific Overrides

Dev: Building a Home Page widget

Dev: Building a Report

Dev: Creating a new Admin menu item

One thing NOT to do!

Alternate Approaches to Menu Creation

Using the Encapsulated Plugin Manager

Dev: Sorting an Admin menu

Top Level Menus (Configuration, Tools, etc.)

Sorting Sub-Menus under the Configuration Menu

Zen Cart 1.5.8

Zen Cart 1.5.7

Dev: View Builders

Zen Cart Documentation – Admin

Dev: Admin Request Sanitization

Why Sanitize?

TEMPORARILY Disabling Strict Sanitization

Logging

For Developers. How to use the sanitization in plugins.

Parameter Naming

Adding Parameters/Groups

General Sanitization Groups

MULTI_DIMENSIONAL Sanitization

Custom Sanitizers

Dev: Admin cron jobs

Existing Cron Jobs within Zen Cart

Dev: Admin Templating Capability

Per-Page CSS Files

Per-Page JS Files

Site Specific Overrides

Related

Dev: Building a Home Page widget

Dev: Building a Report

Dev: Creating a new Admin menu item

One thing NOT to do!

Alternate Approaches to Menu Creation

Using the Encapsulated Plugin Manager

Dev: Sorting an Admin menu

Top Level Menus (Configuration, Tools, etc.)

Sorting Sub-Menus under the Configuration Menu

Zen Cart 1.5.8

Zen Cart 1.5.7

Dev: View Builders