Simone Fioravanti

@mattyrob yes I've already partially implemented to have a mockup. I've used an option but can be also stored in a file inside the plugin maybe?

Yes it needs to be public because it throws an error when called by `apply_filters`.

Seems that extra code will be needed to create the table. But on my first test the tables were created because of a database update triggered by switching from #1436...

I've tested on current `develop` and creation of a post using `REST API` and an application password is working for me.

@emojized can you please test with the plugin I've posted? You should change those line: ```php public $username = 'pippo'; public $application_password = '3MDb TDCU DIg2 4oAB oFDK K3aU'; public...

I've retested on other hosts, using CP 2.0.0 and the `develop` branch and works. Either using e-mail or nickname as username. @emojized can you give more details, like the error...

Something strange in the response. This is what I get with a wrong password: ``` Response message string(12) "Unauthorized" Response body object(stdClass)#1026 (3) { ["code"]=> string(18) "rest_cannot_create" ["message"]=> string(56) "Sorry,...

Can't reproduce.

If a plugin register it's own copy of a deprecated script this should not trigger the deprecation. Scenario: ```php wp_deregister_script('farbtastic'); wp_enqueue_script('farbtastic', plugins_url('js/farbtastic.js', __FILE__), ['jquery'], false, true); ``` The way I've...

`_cp_deprecate_wp_enqueue_scripts`, `_cp_deprecate_login_enqueue_scripts` and `_cp_deprecate_admin_enqueue_scripts` have the same code. Why not to hook the same function?