Manage Magento 1 store settings

A Magento 1 or OpenMage App keeps four store settings in its authoritative App YAML under the magento1 key. synsmarts renders the table prefix, admin frontName, and install date into the store’s app/etc/local.xml, and the PHP entry points into the App’s Nginx routes. You don’t edit local.xml yourself; synsmarts renders the whole file and mounts it read-only.

The portal doesn’t present these settings. Read and change them with the CLI, the API, or a Control MCP connection. Both operations work only on a Magento 1 or OpenMage App; on any other App they return 409 with MAGENTO1_SETTINGS_NOT_APPLICABLE.

Understand permissions

• Team owners, admins, and developers can read the settings. API keys and MCP connections need config.read.
• Only Team owners and admins can change them. API keys and MCP connections need config.write.
• Each user can save these settings 30 times per hour. A save past that limit returns 429 with RATE_LIMITED and a Retry-After header.

Understand the settings

Field	Default	Accepted values	Rendered into
table_prefix	Empty (no prefix)	0-32 letters, digits, and underscores	local.xml global/resources/db/table_prefix
admin_frontname	admin	1-64 letters, digits, and underscores	local.xml admin router frontName
install_date	Mon, 26 Oct 2026 00:00:00 +0000	An RFC 2822 date of up to 64 characters, using only letters, digits, spaces, ,, :, +, and -	local.xml global/install/date
php_entry_points	None	Up to 20 unique store-root-relative .php paths	Exact-match Nginx locations passed to PHP-FPM

A field missing from the saved block renders with its default.

• table_prefix is the prefix Magento 1 puts in front of every table name. It must match the tables already in the App’s database; changing it points the store at differently named tables.
• admin_frontname is the path segment of the store’s admin URL, such as /admin/.
• install_date is the date Magento 1 reads to decide that the store is installed. For a migrated store, use the date from the source store’s local.xml, for example Tue, 13 Jun 2017 14:02:11 +0000.
• php_entry_points lists extra PHP scripts the store serves.

PHP entry points

Nginx passes these Magento 1 scripts to PHP-FPM: index.php, api.php, get.php, js/index.php, errors/report.php, errors/404.php, and errors/503.php. It returns 403 for every other .php, .phtml, or .phar request, including cron.php and install.php. Add a path here when the store’s code has another script that must answer web requests.

Each path:

• is relative to the store root, with no leading /;
• ends in .php and is at most 255 characters;
• uses segments that start with a letter, digit, or underscore and contain only letters, digits, _, ., and -;
• has no wildcard and no . or .. segment;
• isn’t under app/, var/, or media/.

A listed path matches that exact URL path only. If the file isn’t in the deployed release, the request returns 404.

Read the settings

From a CLI configured with your Team and App:

synsmarts deploy --team <team> --app <app> config-magento1-show

The command prints each field ((default) for a field the block doesn’t set), the entry points, and Config revision, the App YAML revision a save is based on. Add --json for the full response.

Through the API, send GET /api/v1/t/{team}/a/{app}/config/magento1. Through MCP, call get_magento1_settings with an app_id from list_apps. Both return the saved magento1 block and head_sha. The block is empty when the App YAML has no magento1 key.

Change the settings

From the CLI, pass only the fields you’re changing:

synsmarts deploy --team <team> --app <app> config-magento1 \
  --admin-frontname backoffice_7f3

The CLI reads the current block and its revision, applies your flags, and saves the result. Fields you don’t pass keep their saved values.

• --table-prefix, --admin-frontname, and --install-date each set one field.
• --php-entry-point <path> replaces the whole entry-point list. Repeat it for each path you want to keep.
• --clear-php-entry-points removes every entry point. It can’t be combined with --php-entry-point.

Through the API, send PUT /api/v1/t/{team}/a/{app}/config/magento1 with revision set to the head_sha you read and the complete set of fields you want. Through MCP, call update_magento1_settings with app_id, revision, and the same fields.

The API and MCP save replaces the whole block. A field you omit returns to its default, so send every field the store depends on, not only the one you’re changing. In a REST request, the App comes from the URL path: the body accepts only revision and the four settings, and any other field fails validation.

A save that changes nothing commits nothing and returns the current revision.

Choose when the change applies

Saving commits the settings to the App YAML and marks the App’s configuration pending, the same as Save for next restart. Nothing restarts, and the running store keeps its current routes and local.xml.

1. Reapply the committed configuration to render the saved settings: synsmarts deploy config-reconcile <app-id> --yes, or reconcile_configuration through MCP. See Reapply committed configuration. The apply replaces Nginx, so a php_entry_points change takes effect when the apply completes.
2. For table_prefix, admin_frontname, or install_date, deploy the App after the apply completes. PHP-FPM, Scheduled Jobs, and the shell read local.xml when their containers start, and a deploy starts new ones. Restart PHP reloads PHP-FPM inside its existing containers, so it doesn’t pick up a new local.xml.

If you don’t reapply, synsmarts applies pending configuration on a later scheduled pass, and the local.xml settings still wait for new containers.

Caution

A new admin_frontname moves the admin URL as soon as new PHP-FPM containers start. Bookmarks and integrations that use the old admin path stop working.

Verify the change

1. Read the settings again and confirm the saved block and the new revision.
2. After the apply, request each new entry point and confirm the store answers instead of returning 403.
3. After the deploy, open the admin at its new path and load a storefront page. A wrong table prefix or install date shows up here as a store error.

Recover from a problem

• 422 with CONFIG_VALIDATION_FAILED. Nothing was saved. Each failure is under field_errors, keyed magento1.<field> or magento1.php_entry_points.<index>, with a code: INVALID, TOO_LONG (a table prefix over 32 characters), DUPLICATE (an entry point listed twice), or UNKNOWN_FIELD. A missing revision is reported under revision as REVISION_REQUIRED. Correct the flagged values and save again.
• 409 with CONFIG_REPO_CONFLICT. The App YAML changed after the revision you sent, so nothing was saved. Read the settings again, review the newer change, and resubmit with the new head_sha.
• 409 with MAGENTO1_SETTINGS_IN_FLIGHT. A deploy, reconfigure, or other App operation is running. Retry after it finishes; the response suggests a delay in Retry-After.
• 503 with CONFIG_REPO_UNAVAILABLE or a lock-unavailable code. The platform couldn’t read or lock the App’s configuration, and nothing was saved. Retry after the suggested delay.

See Customer configuration schema for the rest of the App YAML, and API reference for both operations.