Exploring collaboration with Customize Posts

[westonruter]

Hey @johnjamesjacoby and @tlovett1 :wave: :smile:

Would you like to collaborate? As discussed on Twitter, I wanted to validate a POC to see if the Customizer could be leveraged as the foundation for managing post/postmeta, in addition to leveraging Customizer UI as you've done a great job here. What are your thoughts on the Customize Posts prototype?

There's also obvious overlap here with @avryl's WP Front-end Editor, which I've also noted on that project: https://github.com/avryl/wp-front-end-editor/issues/87

What would you like to do to move forward with collaboration? I mentioned on Twitter that I could delete x-team/wp-customize-posts and then fork the this 10up repo (perhaps doing some gymnastics to delete, then fork Post-Customizer, then rename to wp-customize-posts, then rename to wp-post-customizer so that nothing would 404 and names would be consistent.)

Or would you want to keep the two plugins separate, but just advertise each other's plugins in the respective READMEs so that people can get directed to the prototype they are interested in?

Cheers!

[westonruter]

I did look at Post Customizer first as the starting point for what I wanted to prototype, but then I saw that it took a very different approach to what I was envisioning, so that's why I didn't fork your existing repo at that time since it didn't seem merging would be possible.

[JJJ]

Howdy @westonruter!

I like that your version leverages the WordPress core customizer API. In my opinion, that's definitely worth merging into the Post Customizer plugin.

Having direct access to each post field was not in our roadmap, and I'm not convinced it's necessary. It feels more like a power-user feature to me, and goes against the "WordPress way" style of plugins we generally lean towards.

You are correct that we also implemented front-end editing of the post content and title areas. We chose to lean heavily on the existing "Post Preview" editorial workflow, where a post is originally conceived in TinyMCE, and later edited from within the theme so that stylistic tweaks could be made to the content (like looking for widows in paragraphs, image sizes, etc...)

There's definitely overlap with our intentions, approaches, goals, and even our end results. On our end, this plugin was largely an experiment that came from an after hours talk over beers at our 10up all-company meet-up. Once we pushed it over the finish line, we haven't really circled back to it.

I'd love for us to work together to find where our visions align, and merge our code together into one great post customizing experience that's tested and prepared for core inclusion someday (should that make sense at the time, etc...)

How does that sound?

[tlovett1]

@westonruter do you Skype?

[westonruter]

@johnjamesjacoby @tlovett1 Sorry for the delay on replying here. It's been hectic to wrap things up for Memorial Day weekend.

I like that your version leverages the WordPress core customizer API. In my opinion, that's definitely worth merging into the Post Customizer plugin.

Great. Hopefully the underlying WP_Customize_Posts class can be abstract enough to suit the needs of Post Customizer, when it adds Customizer support.

You are correct that we also implemented front-end editing of the post content and title areas. We chose to lean heavily on the existing "Post Preview" editorial workflow, where a post is originally conceived in TinyMCE, and later edited from within the theme so that stylistic tweaks could be made to the content (like looking for widows in paragraphs, image sizes, etc...)

Yeah. I really like how fast you load up the Customizer UI on top of the edit post page, so it feels fast. This approach, however, means that the full Customizer (wp-admin/customize.php) can't be loaded up. But perhaps that's not really necessary. All that is needed is for the iframe to be populated with the response from a POST request that includes a customized field and then the logic for the Customizer preview could be loaded up, and then filtering could be done on the post fields that were drafted in the post editor. So in that way, your customizer overlay approach could work really well!

But loading a separate Customizer UI, it also means that you wouldn't have to bother with the other Customizer sections and controls for other registered settings. Also, by not using the Customizer here, it means that the contributors, authors, and editors would be able to access it. The Customizer currently requires edit_theme_options to even be able to access it, which I think definitely needs to go.

Having direct access to each post field was not in our roadmap, and I'm not convinced it's necessary. It feels more like a power-user feature to me, and goes against the "WordPress way" style of plugins we generally lean towards.

Regarding the ability to edit all postmeta, it's just exposing the standard “Custom Fields” metabox that appears on the post edit screen. My vision is that each metabox that appears on the post edit screen should also be able to be shown in the Customizer.

Is there a roadmap for Post Customizer?

There's definitely overlap with our intentions, approaches, goals, and even our end results. […] […] I'd love for us to work together to find where our visions align, and merge our code together into one great post customizing experience that's tested and prepared for core inclusion someday (should that make sense at the time, etc...)

Absolutely. And now that I've given more thought to Post Customizer and Customize Posts, I now see that the two projects are complimentary. My vision for Customize Posts is to be able to load up any number of posts to be able to edit concurrently in the customizer, as one possible use case: say if you've loaded up the Customizer with a preview of some category archive page, you would be able to edit the post data and postmeta for all posts that appear on that previewed URL. So what I have in mind for Customize Posts is being able to edit posts that have already been written, whereas Post Customizer is more about making final touches on posts that are being edited prior to publishing.

So instead of deleting our plugin and forking the 10up one, it seems they will do well to live concurrently since they focus on different use cases. They can and should share code as much as possible. I've updated the README in Customize Posts to explicitly highlight Post Customizer and this discussion between the two plugin projects.

do you Skype?

@tlovett1 yes, x-team_thunderboy