Problem/Motivation

Running drush potx against a site with real contrib modules installed aborts before writing any output. Three separate parser defects each kill the run; core-only sites never hit them, which is why CI stays green.

  1. A schema mapping holding scalars is fatal. _potx_process_config_schema() (potx.inc:2611) declares array $schema_data and hands each mapping value to itself. A malformed element passes a string. Shipped by diff:
    diff.layout_plugins:
      type: config_object
      mapping:
        type: sequence
        sequence: ...

    TypeError: _potx_process_config_schema(): Argument #2 ($schema_data) must be of type array, string given

  2. Scalar dependencies in an .info.yml is fatal. potx.inc:2482 iterates the key and later array_merge()s it. dependencies: 'drupal:user' instead of a list gives foreach() argument must be of type array|object, string given, then array_merge(): Argument #2 must be of type array, string given. Shipped by force_password_change and htmlpurifier.
  3. Config exports are misread as module info files. potx.inc:2468 matches ~[^/]+\.info\.yml~, so a base field override for a field named "info" — core.base_field_override.block_content.basic.info.yml in a config sync directory — is treated as a module's info file. Its dependencies is a config mapping, giving Array to string conversion.

Each is independently fatal, so fixing one only exposes the next.

Steps to reproduce

  1. Install diff, force_password_change or htmlpurifier, or export config containing a base fielcode>info.
  2. Run drush potx from the Drupal root.
  3. The command terminates abnormally and writes no .pot file.

Also reproducible as a test failure: PotxCommandsTest::testCommands runs bare

Proposed resolution

Malformed third-party YAML should be skipped, not abort extraction.

  • Accept mixed $schema_data in _potx_process_config_schema() and retrray.
  • Cast dependencies and install to array when reading an .info.yml.<
  • Require type to be module, theme or profile before treating a *.info.yml

Remaining tasks

  • Review the fix and its kernel test coverage.

User interface changes

None.

Obligatory mention of use of LLM

Issue fork potx-3620739

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

heddn created an issue. See original summary.

heddn’s picture

Status: Active » Needs review

Test failures are pre-existing. Fixed over in https://git.drupalcode.org/project/potx/-/merge_requests/58/diffs?file_p.... Let me know if you want that extracted into a dedicated PR.

gábor hojtsy’s picture

Thanks for the report!

Of the problems the first one is fixed by #3630545: Config and YAML strings potx misses: invalid schema elements, schema of config dependencies, patterns without keys: potx reports an error for a schema element with a single value, like type: sequence in diff, and extracts the rest of the schema. I think the solution there was better because it reports an error instead of silently skipping it.

The other two crash 3.x too, with a TypeError at the end of the run.

Looking at localize.drupal.org data about prior parsing runs, these sample releases are actually affected too:

  • htmlpurifier 8.x-1.2 and force_password_change 2.0.2 have their dependency as a single value.
  • Releases of la_eu (10 releases), blokkli_starterkit (9) and sahaza_group_intranet (2) have config files named *.info.yml in config/default or config/sync. Config files in config/install and config/optional are not affected, because potx reads them as shipped config first and do not go on to parse them as info files. On localize.drupal.org, the crash means that the releases have no strings at all.

I decided to solve the problems a bit differently for 3.x.

  1. I think potx should read a file as the .info.yml file of an extension only when its name is the machine name of an extension, like ExtensionDiscovery does in core. Config names always have a dot, like core.base_field_override.block_content.basic.info.yml, so this does not depend on the type key. There was a slim chance that the type key could have false positives still, and using a file name pattern means we don't actually need to even parse the file.
  2. I agree that a dependency as a single value should be read as a list of one for convenience, but it is still not valid. potx should also report it as an error of the file: "The dependencies key has the value 'drupal:filter'. It should be a list of extensions instead."

Both have unit tests, and a kernel test runs a whole extraction with both files. The output of a sample of 51 core and contrib projects is the same with and without the change.

LLM disclosure

LLM was used to further diagnose, explain and fix this issue. With human review.

gábor hojtsy’s picture

Title: drush potx aborts on malformed module schema » Malformed info dependencies and info.yml lookalike config files cause problems

  • gábor hojtsy committed 616ce203 on 3.x
    fix: #3620739 Malformed info dependencies and info.yml lookalike config...
gábor hojtsy’s picture

Status: Needs review » Fixed

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.