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

[FEATURE REQUEST] Allow dynamic configuration of the WP-CLI binary path via module configuration #764

Closed
overclokk opened this issue Nov 26, 2024 · 6 comments · Fixed by #765

Comments

@overclokk
Copy link

Ciao Luca,

Is your feature request related to a problem? Please describe.
Currently, the CliProcess class always uses a hardcoded location for the wp-cli.phar binary and if the file is not found, it will download the binary, so an internet connection is required.

This approach limits flexibility, as users cannot dynamically define or override the WP-CLI binary path through the module configuration or suite settings. For example, if a custom version of WP-CLI is required, users must manually replace the default binary instead of specifying a custom path or if the binary is already present in the project.

Describe the solution you'd like
I would like the ability to specify the WP-CLI binary path through the module configuration using a new key, such as bin. This configuration should propagate to CliProcess to dynamically set the binary path, allowing users to define their own WP-CLI binary without modifying the default implementation.

Example configuration:

modules:
  enabled:
    - lucatume\WPBrowser\Module\WPCLI:
  config:
    lucatume\WPBrowser\Module\WPCLI:
        bin: '/custom/path/to/wp-cli.phar'

The CliProcess class could support a method like setBin or a new parameter in the constructor to accept and use this custom path, and if no path is provided, it should default to the current behavior.

Describe alternatives you've considered

  • Manually replacing the default wp-cli.phar in the output directory (codecept_output_dir('bin')). This approach is not user-friendly and complicates automated workflows.
  • Overriding the methods in WPCLI or creating a custom implementation to handle the binary configuration. This introduces additional maintenance overhead.

Additional context
This feature would make the library more flexible and better suited for environments where multiple versions of WP-CLI are required or where users already have custom binaries. It would also align with the overall modular and configurable nature of Codeception modules.

@lucatume lucatume self-assigned this Nov 26, 2024
lucatume added a commit that referenced this issue Nov 26, 2024
This adds support and tests for the `bin` configuration parameter in the
`WPCLI` module.

Fixes #764
@lucatume
Copy link
Owner

Ciao,

thank you for taking the time to open an issue and provide a possible solution.

I think you're making a good case and it would improve the experience for those user requiring it.
I've drafted an implementation in #765, you can test it out pulling the branch in Composer:

composer require --dev lucatume/wp-browser:dev-v4-wp-cli-custom-bin

Let me know.

lucatume added a commit that referenced this issue Nov 26, 2024
This adds support and tests for the `bin` configuration parameter in the
`WPCLI` module.

Fixes #764
@overclokk
Copy link
Author

Thank you, it works as expected, I noticed one thing, the cache/wp-cli folder is always created even if I did not add a path in the module configuration. I expect that the behavior should be to create this dir only if I add it in the config, of course if I configure a custom bin, what do you think?

@lucatume
Copy link
Owner

Good call.

I've pushed a commit to address that on the branch.

@overclokk
Copy link
Author

Perfect, it works like a charm 😊
Thank you.

@lucatume
Copy link
Owner

Thank you for confirming, I've released this in version 4.3.8.

@overclokk
Copy link
Author

Thank you too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants