Alain Schlesser

@Aaron-Ritter This is indeed still an issue. The latest update for this is that release 5.9 showed that the WordPress update process is broken as well and will be rethought...

The idea is generally interesting. However, we need to be aware of some limitations regarding such an approach. These mostly come from the fact that this goes against the design...

I realized another thing that needs consideration here: If we have an active WordPress process listening to outside commands, we open up a whole can of **security** implication worms. As...

> This is probably not gonna be possible as all the block transforms are written in JavaScript. Easy... => `wp eval-js "transform_block( source, dest );"` ;)

There's more and more work being done on improving the server-side awareness of blocks, so I'm approving the general idea of adding a `wp block` command here. It needs to...

@benlk Your proposed solution sounds good to me, with one potential caveat: > Do not display "Success" if the safety checks in wp core update abort an update I'm not...

I assume in the reporter's case, the issue is something similar to an extension missing. I agree that WP-CLI should do a better job here of letting the user know...

I cannot replicate this on my system. WP-CLI basically just calls the WordPress `wp_install()` function, it doesn't generate any of the rewrites itself. I'd guess that your cli/server environment is...

I did a bit of digging. The rewrite rules are built with this `index.php` prefix because WordPress (not WP-CLI) came to the conclusion that your server environment does not support...

@eyalroth This page might help diagnose the actual issue: https://docs.bolt.cm/3.6/howto/making-sure-htaccess-works