CPT: Render basic post details in custom post type listing

[aduth]

This pull request seeks to continue iterating on the layout of the custom post type post listing screen, adding featured image, last edited date, a view button, and edit link to each post list entry.

Before	After

Note: The layout is very much a work-in-progress and will continue to be refined over time.

Reference design: https://cloudup.com/cdHFJ0ddwl7

Implementation notes:

• getSiteSlug must have been reimplemented, as while it does currently exist on the decorated site object, this is non-ideal and calculated values will be removed from the Redux store site state in the near future. See Site.prototype.updateComputedAttributes for the reference implementation and Framework: redux sites contains functions #2757 as the tracking issue for site state cleanup.
• <PostTypePost /> will likely be split into separate components in a future iteration as each piece of the layout continues to be fleshed out.

Testing instructions:

1. Navigate to My Sites
2. If the current site does not have a custom post type enabled (e.g. Testimonials, Portfolio), switch to a site which has at least one enabled
3. Click the custom post type navigation item in the sidebar
4. Note that after posts have loaded, the layout reflects the "After" screenshot above for any posts which exist
5. Note that the edit link (title), view link, updated date, and featured image are accurate

Caveats:

• There is no loading indicator for posts
• There is no warning shown if no posts exist, only a blank page

[nylen]

This differs from the current implementation in that hasConflict is not included: https://github.com/Automattic/wp-calypso/search?q=hasConflict

More background at 5836-gh-calypso-pre-oss - looks like this is intended to handle fairly extreme edge cases around Jetpack and WP.com sites ending up with the same URL, and the current implementation would need some changes to fit with a reduxified sites list. I personally think it would be ok to punt on it but wanted to mention.

[aduth]

This differs from the current implementation in that hasConflict is not included: https://github.com/Automattic/wp-calypso/search?q=hasConflict

Good eyes. I must have had my blinders on when I had overlooked that part of the condition ( 🙈 ).

@enejb : There's quite a bit of background here. Do you think this is logic that needs to be preserved moving forward in the sites state? Apologies to shine light on this again, but I'm finding it difficult to find the conclusion of the previous discussion.

[enejb]

@aduth without it some users will not be able to access the site that they want. hasConflict is set when it sees that a .com site has the same url as a jetpack site. It sets the primary domain of the .com site to the something.wordpress.com even the site is domain mapped for example. This allow the user to navigate calypso without conflicts.

Since otherwise the user would not be able to land on the site that they want. Please keep it otherwise I am sure we will get someone telling us that they can't access the site.

[nylen]

Works as intended. Code looks good apart from the notes above.

One thing worth noting, but I doubt we can do anything about it, is that featured images still show up in the listing even if the theme doesn't do anything with them:

_{Source: https://jnylen0.wordpress.com/testimonial/}

[aduth]

@nylen : Interesting, the theme's functions.php file does add support for post-thumbnails, and the /post-types endpoint for your site reports that the type does support thumbnails, though the /sites/%s endpoint claims that options.featured_images_enabled is false. Clearly the images aren't shown on the front-end of the site, but also curiously can be assigned in the wp-admin editor.

I've opened #4124 as a follow-up task for this, as there's much more to be fleshed out with regard to thumbnails in any case.

[aduth]

Rebased and added bba3d2c to account for site conflicts, including two new site state selectors getSiteCollisions( state ) and isSiteConflicting( state, siteId ). See also reference implementation.

[aduth]

@enejb : Would you mind reviewing the latest changes in bba3d2c to confirm that it covers the collisions needs well?

[aduth]

bba3d2c#commitcomment-16765942:

Looks great!
One case that still might cause a conflict is when we the .com site is set to https://example.com and the jetpack site is set to http://example.com. Which would result in the same slug. ( As far as I know ) which would prevent the user from visiting one of the urls on calypso.

Thanks for writing the tests.

@enejb : Good point, and one that doesn't seem to be accounted for in our current sites-list implementation. I've pushed d72d607 to ensure it's considered here.

[enejb]

Thanks for the fix!