CsCart SDK

Version 26.08.22

Download

Command-line tools for CS-Cart / Multi-Vendor development (F:\jobs\cscart-sdk-3). Standalone Composer project, not bootstrapped inside a CS-Cart install - runs against any installation by pointing it at the cart’s root path as an argument.

php bin/cscart-sdk <command> [arguments] [options]
php bin/cscart-sdk list          # see every registered command
php bin/cscart-sdk help <command> # full argument/option reference for one command

Σημείωση

The find:* commands all connect to the target cart’s database (via Doctrine, reading connection params straight out of config.local.php / local_conf.php the same way the cart itself does) to know which addons are actually active - inactive addons” files exist on disk but never actually run, so results are filtered/annotated accordingly. A DB connection failure doesn’t block the command; it degrades gracefully and says so, showing everything unfiltered instead.

addon:export

Copies (or moves) one addon’s files out of a live cart install into a separate directory, preserving the relative folder structure - the usual first step before committing an addon to its own repo.

php bin/cscart-sdk addon:export <name> <addon-directory> <cart-directory> [-d|--delete] [--templates-from-design]

  • name - the addon ID.

  • addon-directory - where to export to; files land under <addon-directory>/src.

  • cart-directory - the CS-Cart installation to export from.

  • -d, --delete - move instead of copy (source files are removed from the cart).

  • --templates-from-design - changes where frontend template files are read from and how they’re placed in the export. Without this flag (the default), files matching design/themes/... in the cart are exported into var/themes_repository/... inside the addon package. With the flag, files already sitting under var/themes_repository/... in the cart are exported as-is (no design/themes/ involvement at all). Worth testing on a throwaway export first if the addon’s template layout is unfamiliar - the option’s own description text reads almost the opposite of this, so go by the behavior above, verified straight from the command’s source, not the --help wording.

If a target file/directory already exists, you’re asked to confirm overwriting it individually (or the whole target directory up front, if <addon-directory>/src already exists).

Example:

php bin/cscart-sdk addon:export jcd_payroll addons_git/jcd_payroll ./jcclubbelize-staging

find:fn-hooks

Given a core function or class method, finds every fn_set_hook() call inside it, and for each hook found, every place across core and every addon that could handle it - covering all five ways CS-Cart actually wires up a hook handler:

  1. classic fn_register_hooks() (fn_<addon>_<hook>(), including the addon-override array form)

  2. fn_core_<hook>() (fires unconditionally, no registration)

  3. fn_<edition_acronym>_<hook>() (fires only if the install’s PRODUCT_EDITION matches - pro/mve/ult)

  4. the modern OOP mechanism (v4-scheme addons, addon.xml → Bootstrap.php → getHookHandlerMap(), resolved through the addon’s ServiceProvider)

  5. an unregistered handler that exists but was never wired up at all - flagged explicitly, since that’s silent dead code otherwise

php bin/cscart-sdk find:fn-hooks <cart-directory> <fn>

  • fn - either a plain function name (fn_get_cart_product_data), or ClassName::methodName for hooks living inside an app/Tygh class (Shippings::groupProductsList). A fully-qualified Namespace\ClassName::methodName also works.

Example:

php bin/cscart-sdk find:fn-hooks ./jcclubbelize-staging fn_get_cart_product_data

find:template-files

Given a template path, walks the whole Smarty rendering graph CS-Cart would actually touch for it: the base/core file, every active addon’s full override (with the priority-based winner flagged), every {hook}/{include}/{include_ext} found along the way (resolved recursively through the same override/hook logic), and any dynamic {include file=$var} expression flagged as needing manual follow-up rather than silently skipped.

php bin/cscart-sdk find:template-files <cart-directory> <template> <area> [--exclude=common,buttons]

  • template - path relative to the templates root, e.g. views/products/update.tpl.

  • area - backend, or a theme name (e.g. responsive) - not the literal themes/responsive path, just the theme’s own name.

  • --exclude - comma-separated path roots to record but not expand into (generic UI chrome pulled in by almost everything). Defaults to common,buttons; pass an empty string to disable.

Example:

php bin/cscart-sdk find:template-files ./jcclubbelize-staging views/products/update.tpl backend

find:unbalanced-html-tags

Scans every TEXT/MEDIUMTEXT/LONGTEXT database column (WYSIWYG content, product/category descriptions, static blocks, …) for unbalanced or improperly nested HTML tags, and reports results as a table.

php bin/cscart-sdk find:unbalanced-html-tags <cart-directory> [--company-id=N] [--exclude-tables=...] [--exclude-only-tables=...] [--only-tables=...] [--only-tags=...] [--ignore-tags=...]

  • --company-id - only scan rows for this company; tables without a company_id column are scanned regardless of this filter.

  • --exclude-tables - table names (without prefix) to skip, in addition to the built-in default list (logs, log, user_activity, search_words, session_data, change_log, template_snippets, template_emails, original_values).

  • --exclude-only-tables - table names to skip instead of the default list, replacing it entirely (and overriding --exclude-tables if both are given).

  • --only-tables - restrict the scan to exactly these tables.

  • --only-tags / --ignore-tags - restrict which HTML tag names get checked.

This one buffers everything and renders one table at the end rather than streaming results - it’s meant to be reviewed at your own pace afterward, not watched while it runs.

Example:

php bin/cscart-sdk find:unbalanced-html-tags ./jcclubbelize-staging --company-id=3

find:controller-mode

Given an area and a controller.mode (the same shape visible in the admin/storefront URL, e.g. products.update), finds every controller file across core and every addon that could be handling it - the file cascade CS-Cart’s own dispatcher builds (.pre → main → .post, core + common/ + every active addon, in that order), each one searched for a $mode check against the target mode.

php bin/cscart-sdk find:controller-mode <cart-directory> <area> <controller-mode>

  • area - backend or frontend.

  • controller-mode - e.g. products.update.

Also actively checks for the one hard constraint CS-Cart’s own dispatcher enforces at runtime: at most one active main (non-pre/post) controller file may exist for a given controller name - finding more than one is flagged as a conflict, since that’s exactly the condition that throws DeveloperException("Duplicate controller ...") in production.

Example:

php bin/cscart-sdk find:controller-mode ./jcclubbelize-staging backend products.update