WP-CLI as a backend for steps
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 25/100
Línea de trabajo
Comienza con la documentación enlazada de los comandos de WP-CLI y el debate sobre plugins, descargas y comandos de shell. Se considera completado cuando se haya alcanzado y documentado un alcance de integración acordado y acotado para los pasos de Blueprint, en lugar de exponer todos los comandos de WP-CLI.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
How many of WP-CLI commands could Blueprints reuse instead of reinventing the same logic?
- plugin install
- Could potentially power the installPlugin step
- Accepts a plugin slug, a path to a local zip file, or a URL to a remote zip file.
- config set – could power the defineWpConfigConsts step
- core multisite-convert – could power the enableMultisite step
- config shuffle-salts
- export and import – could handle WXR processing
- language – we could support installing language packs
- server – could potentially run the server on native PHP and maybe in Node.js
- theme, plugin, user
- scaffold post types, taxonomies etc code generation
Discussion
- Should all Blueprint steps become just plugins to wp-cli?
- No, simple steps like cp, mv etc don't warrant loading the entire wp-cli machinery and could be handled higher up in the stack.
- Should all wp-cli commands be available as Blueprint steps?
- It seems like a bad idea. This would inflate the scope, tightly couple the Blueprint library to wp-cli, and require inventing ways to express shell commands as JSON.
- Let's handle all downloads outside of WP-CLI. WP-CLI is sequential in nature (download plugin X, then download plugin Y), and Blueprints need to parallelize the downloads (download plugins X and Y at the same time).
cc @schlessera @swissspidy @danielbachhuber
- Lenguaje dominante
- PHP
- Estrellas
- 61
- Forks
- 22
- Merge medio
- 19 h 34 min
- PR fusionados (30 d)
- 7
Preparar el entorno
Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.
- Incluye un Dockerfile o un archivo de Docker Compose
- Sin plantilla de pull request
- Sin guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de WordPress/php-toolkit
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
WordPress/php-toolkit#313 ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 58/100
WordPress/php-toolkit#306 ·
-
WPCS complianceAbierto
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
WordPress/php-toolkit#157 · 1 reacción ·
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
WordPress/php-toolkit#138 · 7 comentarios · 2 reacciones ·
-
[Blueprints v2] Constraint the Blueprint bundle formatQuizá libre de nuevo @JanJakes la tomó hace 430 días y no hay ningún pull request abierto. AbiertoBlueprints enhancement
WordPress/php-toolkit#132 · 4 comentarios · 1 asignado ·
Todos los issues de WordPress/php-toolkit
Issues similares
-
[Sync EN] Fix session read handler docs: false reports a failure, not a missing session (#5902)Abiertosync-en
Dificultad 2/5 1-2 días Aptitud para principiantes 84/100
Los mantenedores suelen responder en 2 días
-
feature-request needs-triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
aws/aws-sdk-php#3365 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 1-3 horas Aptitud para principiantes 90/100
-
bug status: unverified
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
woocommerce/google-listings-and-ads#3884 ·
Los mantenedores suelen responder en 1 día