osCommerce 2 Documentation

The catalog/index.php file serves as the primary entrypoint for the customer-facing storefront. It handles routing for different types of content based on the request state:

1. Site Pages: If OSCOM::hasSitePage() returns true, the system fetches a specific page file via OSCOM::getSitePageFile() and renders it within the site template (top and bottom).
2. Category Navigation: If a category path ($cPath) is provided, the system determines the category_depth:
   • nested: The category contains sub-categories. The system renders the category name, description, and uses the index_nested template content.
   • products: The category contains products. The system builds a dynamic SQL query to list products based on configured columns (e.g., PRODUCT_LIST_NAME, PRODUCT_LIST_PRICE) and renders the product_listing.php content.
3. Manufacturer Views: If manufacturers_id is present in the GET parameters, the system displays products associated with that manufacturer.
4. Default Home Page: If no specific page or category is matched, it renders the default index content using the index template content.

Key Components Involved:

• OSCOM: Core static methods for site page detection, configuration, and link generation.
• $oscTemplate: Handles template file retrieval (template_top.php, template_bottom.php) and content injection (getContent()).
• $OSCOM_Db: Used for prepared statements to fetch categories, products, and manufacturers.
• $OSCOM_Language: Manages language IDs and definition loading.
• $messageStack: Handles displaying user messages (e.g., product_action).

The sage_pay/server.php file acts as the callback entrypoint for Sage Pay server-to-server notifications. It validates incoming POST data from Sage Pay using a security signature and a security key associated with a specific skcode provided via GET.

Workflow

1. Validation: The script checks for the presence of skcode (GET) and required POST parameters (VPSSignature, VPSTxId, VendorTxCode, Status).
2. Signature Verification: It constructs a signature string by concatenating specific transaction fields and the security key retrieved from the sagepay_server_securitykeys table. The signature is verified against the provided VPSSignature using an MD5 hash.
3. Success Handling: If the signature is valid and the status is OK, AUTHENTICATED, or REGISTERED, the transaction details are sanitized and saved to the database. The script returns a Status=OK response with a RedirectURL pointing to checkout_process.php.
4. Failure Handling:
   • If the signature is invalid, it returns Status=INVALID and redirects to the shopping cart.
   • If the transaction status is not successful, it returns Status=OK (to acknowledge receipt to Sage Pay) but redirects the user to an error page (checkout_payment.php or a custom redirect script) and deletes the security key record.
5. Response Format: The script outputs a plain text response in the format:

   Status=[OK|INVALID|ERROR]
   RedirectURL=[URL]

6. **Session Management**: Upon completion, the current session is killed via `Registry::get('Session')->kill()` to prevent session fixation or reuse.

The Admin Dashboard is populated by modules defined in the MODULE_ADMIN_DASHBOARD_INSTALLED constant. This constant accepts a semicolon-separated list of module identifiers.

Modules can be specified in two ways:

1. Namespaced Classes: A fully qualified class name (e.g., \Namespace\ModuleClass). The system uses Apps::getModuleClass($adm, 'AdminDashboard') to resolve these.
2. File-based Modules: A filename (e.g., module_name.php). The system will attempt to load the class from includes/modules/dashboard/{class}.php after loading the corresponding language definitions from modules/dashboard/{filename}.php.

Each dashboard module must implement an isEnabled() method and a getOutput() method to render its content.

// Example of how the constant might be defined in a configuration file
define('MODULE_ADMIN_DASHBOARD_INSTALLED', 'ModuleClass1;\Namespace\ModuleClass2;module_name.php');