Skip to content

Fix #18510 - Use database and table aliases in export filename template - #20374

Open
TowyTowy wants to merge 2 commits into
phpmyadmin:QA_5_2from
TowyTowy:fix/18510-export-filename-aliases
Open

Fix #18510 - Use database and table aliases in export filename template#20374
TowyTowy wants to merge 2 commits into
phpmyadmin:QA_5_2from
TowyTowy:fix/18510-export-filename-aliases

Conversation

@TowyTowy

Copy link
Copy Markdown
Contributor

Description

When exporting with the rename exported db/table/columns option and a filename template that uses @DATABASE@ / @TABLE@, the generated filename used the original database and table names instead of the aliases the user entered.

Export::getFilenameAndMimetype() built the filename via Util::expandUserString($filenameTemplate) with no variable overrides, so @DATABASE@ and @TABLE@ always resolved to $GLOBALS['db'] / $GLOBALS['table']. The export aliases were already assembled in ExportController but were never passed to the filename generator.

This passes the aliases down and, when an alias is defined for the current database or table, uses it as the replacement for @DATABASE@ / @TABLE@. Database/server exports (empty $table) are unaffected.

Adds a regression test that fails on current QA_5_2 (test_db-test_table.php) and passes with the fix (aliasdb-aliastbl.php); phpcs clean.

Fixes #18510

This change was prepared with the assistance of AI (Claude); it has been reviewed and tested, and I take responsibility for it.

Before submitting pull request, please review the following checklist:

  • Make sure you have read our CONTRIBUTING.md document.
  • Make sure you are making a pull request against the correct branch (QA_5_2 — the bug affects released 5.2 and forward-merges to master).
  • Every commit has proper Signed-off-by line as described in our DCO.
  • Every commit has a descriptive commit message.
  • Every commit is needed on its own.
  • Any new functionality is covered by tests.

…ame template

When exporting with renamed database/table aliases (the "rename exported
db/table/columns" option), the @database@ and @table@ placeholders in the
filename template were replaced with the original names instead of the
aliases.

Export::getFilenameAndMimetype() called Util::expandUserString() without
any variable overrides, so the placeholders always resolved to
$GLOBALS['db'] and $GLOBALS['table']. Pass the export aliases down from
the controller and, when an alias is defined for the current database or
table, use it as the replacement for @database@ / @table@.

Co-Authored-By: Claude <noreply@anthropic.com>
Signed-off-by: TowyTowy <towy@airreps.link>
@TowyTowy

Copy link
Copy Markdown
Contributor Author

Pushed a small follow-up: Psalm (analyse-php, errorLevel 1) flagged two MixedAssignment errors because the new $aliases parameter is an untyped array, so the alias reads are mixed. Cast both to (string) before assigning into $updates (the values are always strings, guarded by ! empty()), which keeps Psalm green without adding baseline entries. phpcs and the new unit test still pass.

@TowyTowy
TowyTowy force-pushed the fix/18510-export-filename-aliases branch from 5162e79 to 15982ce Compare July 15, 2026 20:05
@TowyTowy

Copy link
Copy Markdown
Contributor Author

Follow-up for analyse-php: rather than the (string) casts (which are the wrong tool for PHPStan and bumped the counted baseline), I properly typed the $aliases parameter (array shape via an @var) and switched the alias substitution to strict isset() / !== '' checks instead of empty(). That removes the "cast mixed to string", "offset on mixed", and "empty() not allowed" occurrences at the source, so the PHPStan baseline counts match again. PHPStan is clean on the changed files and the alias unit test still passes.

Export::getFilenameAndMimetype() now reads the db/table aliases the same
way the existing exportDatabase()/exportServer() readers in this file do:
! empty($aliases[$db]['alias']) plus a (string) cast on the mixed alias
value. This is the natural pattern that already passes both analysers
everywhere else in Export.php, so its "offset on mixed" / "cast mixed to
string" / "empty() not allowed" notices are absorbed by the counted
PHPStan baseline instead of being worked around with typing that one
analyser rejects (is_string() narrowing tripped Psalm's RedundantCondition
at errorLevel 1).

- Type $aliases as mixed[] so the value type is specified (no extra
  "no value type in iterable" baseline entry needed) while the loose array
  passed by the controller still type-checks.
- Bump the five existing Export.php counts in phpstan-baseline.neon to
  cover the two new empty() checks, the two (string) casts and the new
  mixed-offset accesses. Psalm (errorLevel 1) needs no new entries.
- Reduce the test's server-config setup to a single assignment and
  baseline the one remaining $GLOBALS['cfg'] mixed-offset in the test.

Co-Authored-By: Claude <noreply@anthropic.com>
Signed-off-by: TowyTowy <towy@airreps.link>
@TowyTowy

Copy link
Copy Markdown
Contributor Author

Reworked the analyse-php fix once more, this time verified against both tools on PHP 7.2 (the CI environment). The alias reads now use the same pattern as the existing readers in Export.php (! empty() + (string)), with the resulting PHPStan notices absorbed by the counted baseline like their pre-existing counterparts, and the $aliases param documented as mixed[]. Psalm needed no baseline changes and reports no errors at level 1; PHPStan is green. Sorry for the churn on this one.

@TowyTowy
TowyTowy force-pushed the fix/18510-export-filename-aliases branch from bd5e8f2 to 1b57455 Compare July 16, 2026 10:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants