Taxonomy paging and search for Categories and Tags.

[kurzee]

This is required implementation for work on Menus management and also for the upcoming work on Categories and Tags management. There is more work to be done between categories and tags across the whole app, but will await a larger refactor with many more dependencies observed.

1. Refactors TaxonomyServiceRemote for paging and searching taxonomy results via REST and XML-RPC.
2. Refactors PostTagService for supporting search and paging via remotes.
3. This also resolves an issue seen in XML-RPC connections in which a category created via the app with a parent category was not setting the parent correctly according to the XML-RPC.

Note on PostCategoryService: I did not include the methods on PostCategoryService for supporting paging or search. Upon testing I noticed it will require additional refactoring that will have to pay careful attention to current dependencies of PostCategoryService and how it merges the PostCategory entities.

Testing should be done with both REST and XML-RPC sites.

1. Open "Settings" for a site.
2. The "Default Category" should be presented correctly.
3. Selecting the "Default Category" cell should present a site's categories.
4. Hitting the + button should create a new category for the site.
5. Creating a new category with a parent should work correctly, particularly on XML-RPC (broken previously)
6. Create a new post for a site.
7. When the post is posted, the default category should have been automatically assigned.
8. Create a post with a different category, the post should have the correct category.

Additional testing for the PostTagService will come with upcoming Menus PRs, since there are no current users of the PostTagService within the project.

Please review @aerych.

[aerych]

Documentation comments need the /** opener vs /*

[aerych]

This looks identical to the REST version. Maybe its a good candidate to extract into a helper class vs duplication?

[kurzee]

I'd like to keep these separate as the APIs are just a tad different and any further implementation would need to be treated as such.

[aerych]

👍

[aerych]

Hiya @kurzee! Good stuff :) I left some nitpicky comments through through the code, all really minor.

I tested a wpcom blog and a Jetpack connected blog and the default category updated as expected, and was correctly reflected in post options. Very nice.

I tested a self-hosted-no-jetpack blog and confirmed the fix for parent/child categories.

The default category does not seem to be working for self-hosted blogs via XML-RPC. When adding a self-hosted blog, the default category in the app was "Uncategorized", ignoring what was set on the blog and selecting a default category in the app did not update the default category on the blog. From what I can tell, default_category, while a valid option, is not returned by wp.getOptions nor can it be set by calling wp.setOptions. At least this is the behavior when I try those calls. I've been looking through the XML-RPC API docs and I'm not finding any other way to get/set the default category. Maybe this is just not currently supported via XML-RPC? Should we hide the feature for those blogs?

[kurzee]

Thanks for the great review @aerych! I added new commits earlier and did some more testing.

I also spent some time trying to find a way to get/set that default category on XML-RPC and couldn't find a working method either... Strange that it isn't included in the XML-RPC.

I'd say we should keep the current default category implementation within the app as it allows the user to select a different default category for use within the app editor. This way, they don't have to keep selecting a category each time they open the editor.

[aerych]

This way, they don't have to keep selecting a category each time they open the editor.

I'm a little worried about either confusing a user, or breaking expectations when a change to the default category in the app is not reflected on the web (and vice versa). If we keep the default category selector for self-hosted folks, could we somehow clarify its usage?

[kurzee]

could we somehow clarify its usage?

I think that would be best so users understand that any change is only within the app. This is also the same for the "Default Post Format" option. I'll come up with some copy to place above the table section as a header label.

[aerych]

I'll come up with some copy to place above the table section as a header label.

Awesome. Thanks @kurzee !

[kurzee]

@aerych I'm going to create a separate issue/PR for the XML-RPC default category changes. There's a couple other changes that need to be made that are out of context with this PR. Let me know if you have any other notes on this PR.

[aerych]

Hiya @kurzee :)
I had one last very very nitpicky comment. But otherwise :)

[kurzee]

Thanks @aerych! Changed the variable name and added a helper function for logging those errors! Merging.