Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug] TextDomainMismatch if checking a plugin via path #774

Open
hirasso opened this issue Nov 7, 2024 · 13 comments · May be fixed by #780
Open

[Bug] TextDomainMismatch if checking a plugin via path #774

hirasso opened this issue Nov 7, 2024 · 13 comments · May be fixed by #780
Labels
[Type] Bug An existing feature is broken

Comments

@hirasso
Copy link

hirasso commented Nov 7, 2024

Expected behavior

When running wp plugin check path/to/my-plugin, the checked text domain should be my-plugin

Actual behavior

When running wp plugin check path/to/my-plugin, the checked text domain actually is the full path: wp plugin check path/to/my-plugin

Context

After the explanation in #773 that a local zip file is not supported yet, I now tried to check my plugin via path:

  1. I am creating a scoped package of my plugin using php-scoper. The scoped package is created in a subfolder of my plugin with the same name as my plugin. Seen from the plugins folder it looks like this: ./my-plugin/my-plugin
  2. I make sure plugin-checker is available in wp-env
  3. I check the subfolder in wp-env
{
    "composer scoped:create",
    "npx wp-env run cli wp plugin install plugin-check --activate",
    "npx wp-env run cli wp plugin check wp-content/plugins/my-plugin/my-plugin"
}

The plugin check works this time, except for one issue: The expected text domain contains the full path wp-content/plugins/my-plugin/my-plugin instead of simply my-plugin, which produces a lot of WordPress.WP.I18n.TextDomainMismatch errors.

@hirasso hirasso changed the title [Bug] TextDomainMismatch if checking a plugin via path [Bug] TextDomainMismatch if checking a plugin via path Nov 7, 2024
@hirasso
Copy link
Author

hirasso commented Nov 7, 2024

Another issue: Due to the fact that my path happens to begin with wp-content, I'm also getting a trademarked_term warning.

@swissspidy
Copy link
Member

I‘d suggest moving your folder to a different location. That just asks for trouble.

If a plugin is in wp-content/plugins we expect to jusf pass the slug. But nested plugins are not really a scenario we support in Plugin Check nor in the plugin directory.

Have you tried moving it to wp-content/plugins directly? That would be the best solution. This way we can also actuvate the plugin during runtime checks.

Have you tried moving it to a tmp folder?

Alternatively, have you tried wp plugin check my-plugin/my-plugin?

@hirasso
Copy link
Author

hirasso commented Nov 7, 2024

Have you tried moving it to wp-content/plugins directly? That would be the best solution. This way we can also actuvate the plugin during runtime checks.

That's a chicken-and-egg problem. I already have the development version of my plugin under the /plugins folder. So I can' really name my built version the same. I'll try

...I have just both your other suggestions. In all of them, I'm getting errors with the text domain. This is my script now:

{
      "npx wp-env run cli wp plugin install plugin-check --activate",
      "npx wp-env run cli mv wp-content/plugins/my-plugin/my-plugin my-plugin",
      "npx wp-env run cli wp plugin check ./my-plugin"
}

The errors:

Mismatched text domain. Expected './my-plugin' but got 'my-plugin'

Same with a tmp folder:

Mismatched text domain. Expected '/tmp/my-plugin' but got 'my-plugin'

...so there is definitely something I'm missing. I found the --slug option for the WP_CLI command in the docs and thought that I could control the text domain that way, but it doesn't work:

@hirasso
Copy link
Author

hirasso commented Nov 7, 2024

...OMG I think I have it! Passing the --slug actually solves all my issues!! This is what works for me now:

{
  "plugin:check": [
      "composer scoped:create",
      "npx wp-env run cli wp plugin install plugin-check --activate",
      "SLUG=$(basename \"$(pwd)\"); npx wp-env run cli wp plugin check wp-content/plugins/$SLUG/$SLUG --slug=$SLUG"
  ],
}

This works because in my setup I

  1. Am inside wp-content/plugins/my-plugin/my-plugin when I run the script
  2. Build my plugin into wp-content/plugins/my-plugin/my-plugin
  3. Set the slug to the current basename(pwd), so it's my-plugin

I found the elegant trick with $(basename \"$(pwd)\") in plugin checker's package.json. Thanks for that! :)

@ernilambar
Copy link
Member

"npx wp-env run cli wp plugin check ./my-plugin"

AFAIR, relative path is not supported. Full absolute path is expected.

--slug was introduced to fix similar issue of incorrect calculation of plugin slug. What was the error message when --slug was passed?

@hirasso
Copy link
Author

hirasso commented Nov 7, 2024

@ernilambar you guys are just too quick for me ☺️ ...see my previous comment – --slug actually does the trick! 👏

@hirasso
Copy link
Author

hirasso commented Nov 7, 2024

AFAIR, relative path is not supported. Full absolute path is expected.

I just tested this statement. It doesn't work with absolute paths:

{
    "plugin:check": [
      "composer scoped:create",
      "npx wp-env run cli wp plugin install plugin-check --activate",
      "SLUG=$(basename \"$(pwd)\"); npx wp-env run cli wp plugin check /var/www/html/wp-content/plugins/$SLUG/$SLUG"
    ],
}

The expected text domain becomes the full path: /var/www/html/wp-content/plugins/my-plugin/my-plugin

@ernilambar
Copy link
Member

Hmm. Makes sense. That support for path was implemented keeping in mind that plugin will be outside of the WordPress setup, somewhere in the same server.

@hirasso
Copy link
Author

hirasso commented Nov 7, 2024

It also doesn't work if the plugin is in /tmp/my-plugin. Outside of WP.

I would consider this a bug, after all 🐛

@ernilambar
Copy link
Member

I tried wp plugin check /tmp/sample-plugin --slug=sample-plugin and it is working as expected.

@hirasso
Copy link
Author

hirasso commented Nov 7, 2024

Yes! With the --slug option it's also working if the plugin resides inside the wordpress plugin folder. Without the --slug option, it doesn't work, no matter where the plugin lies.

This won't work:

wp plugin check /tmp/sample-plugin

@davidperezgar
Copy link
Member

davidperezgar commented Nov 7, 2024

Yes, the best approach is to enforce language checks by giving the slug.

Anyway, I think we should check that command, as it should run with slug as sample-plugin.

@swissspidy
Copy link
Member

Agreed, this is a bug.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Type] Bug An existing feature is broken
Projects
None yet
4 participants