Closed mowshon closed 7 years ago
I like the idea a lot. I'll also try to get my hands around this and help with development of this beast. It will open a lot of possibilities for automatization 🚀 🚀
:+1:
What we have now is nice, but I've got a couple of points on it.
First, we'd have to distribute unyson-cli
as a separate WP_CLI
package in their package-index
for a couple of reasons (The other option will be to distribute it with the plugin itself, as @mowshon started):
We'll have a separated commit timeline for it and if we'll commit a mistake in our CLI code we won't break any websites that already depend on Unyson. I know, we're protecting with defined( 'WP_CLI' )
but that's not enough in my point of view.
Having to distribute unyson-cli
with the plugin means we'll have to already have Unyson installed. I'd like to create a couple of scaffold commands that we'll be able to run without the Unyson being already installed (In fact, you'll be able to run them even without WordPress):
wp unyson install
- it will install latest version from wp.org repowp unyson install --edge
this will install latest master. or something else? We can even provide defaults via wp-cli.yml
wp unyson scaffold test-site
I plan to integrate my quick and dirty script for quickly spinning off a new WordPress install for dev testingWe'll loose the power of @when
. This allows us to specify when the command will run:
@when
This is a special tag that tells WP-CLI when to execute the command. It supports all registered WP-CLI hooks.
@when after_wp_load
Do keep in mind most WP-CLI hooks fire before WordPress is loaded. If your command is loaded from a plugin or theme, @when will be essentially ignored.
It has no effect if the command using it is loaded from a plugin or a theme, because by that time WordPress itself will have already been loaded.
What do you guys think about that?
@mowshon By the way, that's the trick for list
to work properly:
/**
* @subcommand list
*/
function _list( $args, $assoc_args ) {
...
}
I have made a few changes in subcommands structure. https://github.com/ThemeFuse/Unyson/pull/2278/commits/305e9e44b40fd5a2e4ee739b1739fd5f7a453503
New version
# wp unyson (FW commands)
# wp unyson-ext (extensions commands)
wp unyson version
wp unyson-ext list
wp unyson-ext activate seo
Old version
wp unyson extensions
wp unyson extensions list
wp unyson extensions activate seo
The new version works with WP-CLI help
method, because unyson-ext
is independent command with his own subcommands.
@mowshon I just found a neat trick for that!
You can add commands like that and this way you get free namespacing!
WP_CLI::add_command( 'unyson extensions', 'FW_CLI_Command_Extensions' );
That's how wp-cli-buddypress achieves namespacing.
@andreiglingeanu thanks for help!
The old commands syntax is back. Also, we add Filesystem initialization. Now we can to uninstall extensions.
wp unyson extensions deactivate seo
wp unyson extensions uninstall seo
Great!
Update:
Add extension install command
wp unyson extensions install page-builder
Add documentation for commands.
wp help unyson extensions install
Commit: https://github.com/ThemeFuse/Unyson/pull/2278/commits/642727387f8501488fbb19352f79044df15cbd34
where can I download unyson package for wp-cli ( can't find it on their site, in packages section)? Also I'm working on docker image (and complete docker compose setup ) that uses wp cli via YAML file and installs themes and plugins automatically. Will share it when I'm done.
At the moment, there's no package to download. @mowshon is just scratching the surface. We'll have to build an installable package and submit it to the wp-cli index soon, though.
Great to hear that that's there's some need for the unyson cli!
For documentation:
$ wp unyson theme-settings set --help
$ wp unyson theme-settings get --help
$ wp unyson theme-settings reset --help
# Full theme settings structure.
$ wp unyson theme-settings get --format=json
# A part of theme settings.
$ wp unyson theme-settings get link/color
# Set new value.
$ wp unyson theme-settings set link/color/value #00000
# Output:
array(
link => array(
color => array(
value => #00000
)
)
)
# Save value as array.
$ wp unyson theme-settings set logo/img '{"link": "logo.png"}' --array
#Output
array(
logo => array(
img => array(
link => logo.png
)
)
)
# Save json as string.
$ wp unyson theme-settings set user/info '{"age": "20"}'
#Output
array(
user => array(
info => '{"age": "20"}'
)
)
$ wp unyson theme-settings reset --confirm
We created a new repository for Unyson CLI: https://github.com/ThemeFuse/Unyson-CLI By @andreiglingeanu suggestion, we think to add Unyson CLI in WordPress Packages Repository
WP_CLI is useful tool for Wordpress automatization from console. More info: http://wp-cli.org/
I have some realisation of WP-Cli and Unyson integration: Fork: https://github.com/mowshon/Unyson commit: https://github.com/mowshon/Unyson/commit/862fcba87d4c01a3d339d43f40340c4f3a3d0076
Unyson CLI is avaible only from console. https://github.com/mowshon/Unyson/blob/862fcba87d4c01a3d339d43f40340c4f3a3d0076/framework/wp-cli/fw-cli-autoload.php#L7-L9
Examples:
List of extensions
Activate/Deactivate extensions
@moldcraft the changes in Unyson core:
Checking for
defined( 'WP_CLI' )
.Problems:
When I try to call method
uninstall_extensions
directly, I got error:WP Filesystem is not initialized
I know the meaning of this error, but this also mean that we need more changes in Unyson Core if we will start WP_Cli integration.
What do you think about Unyson commands from console?