xwp / wp-customize-posts Goto Github PK

When editing a post, there should be a easy way to add the post to one or more nav menus. This is the opposite of #49, where a post should be able to be created from the “add menu item” UI.

At least while waiting for the customizer preview to refresh. This would likely require explicit opt-in on a theme-by-theme basis.

Allow admins to edit all fields, even protected ones.

In addition to editing existing posts, entirely new posts/pages should also be able to be created in the Customizer. There are two approaches we could go here:

(1) It could use the approach of creating new nav_menu_item posts where the pre-created post has a negative post ID which is used to designate a post that has not been inserted yet.
(2) Or it could actually create an auto-draft post in the DB which would give us a real ID to reference.

It would definitely be less complicated to implement (2), since all the DB queries would work in the preview without having to inject pseudo-posts into query results. However, I also like (1) because it is more philosophically pure in that it truly does not touch the DB before Save & Publish.

Once the technical architecture for representing a pre-created post is settled, there is then the question of the UI for creating these posts. One integration option is in Customizer Nav Menus via the Add Item UI (see #49). Another integration option is to extend the post type's panel to add a “New Post” button before the list of post sections (see #50).

Do same thing as was done for Widgets.

Selective refresh currently applies title and content changes based on the hEntry microformat, looking for .entry-title and .entry-content. This works well for The Loop.

When updating a post/page which appears in a Recent Posts widget or Pages widget, the new title should ideally appear in the widget as well as in The Loop. The Pages widget (via wp_list_pages()) does add CSS class names for the underlying post ID for each page that is listed, which will make it easy to target the update. The Recent Posts widget does not include these class names, however, so it won't be as easy. If pretty permalinks are turned off (#42) it could find posts by looking at the URLs directly since they will include the post ID (e.g. /?p=123). This assumes, of course, that the link text is actually the post title itself and not some other text. This is definitely a nice to have, and not something very important.

For other post lists, it may make sense to require microdata/microformats in order for the updates to apply. This is a sensible requirement for themes to have.

We can do instant previews of post titles by injecting the post title into the .entry-title via JS as a low-fidelity preview until we wait for the selective refresh response to return. This is similar to what has been implemented for blogname and blogdescription in 4.5.

When previewing a post from the post edit screen, it should open in the Customizer. This avoids requiring the user to click an additional “Customize” link from the admin bar and to navigate to the post in the Customizer pane.

• There needs to also be a post status dropdown in the Customizer (#40) so that drafts can actually be published from the Customizer. (We can just skip allowing post to be published from Customizer view.)
• When clicking “Preview” the Customizer should be loaded via customize-loader and any changes made to the post should be synced back to the parent frame in case “Save & Publish” is not clicked.
• Clicking “Close” should not prompt with AYS confirmation because the value should have been synced to the editor in the parent frame.

See also http://wordpress.org/plugins/customizer-everywhere/

When a post type panel is expanded, before the list of posts currently shown in the preview, there should be a button to start authoring a new post of that type.

Depends on #48.

Since each setting gets registered with the cap that is required to update it, there is no need to gate the whole customizer for a specific capability (edit_theme_options) as well.

This would allow the Customizer to be opened for Contributors, Authors, and other roles who create posts.

Instead of just relying on wp_update_post() when the data finally gets updated in the DB, we should ideally be doing similar checks in the sanitization_callback so that the right data gets supplied in the preview. For example, it would probably be good to run it through wp_insert_post_data.

Some suggestions have been raised (see #45 for mobile-specific improvements):

“I think removing the need to click the edit content button and showing the wysiwyg right away would actually be more straightforward what do you think?” (@jonathanbardo via Facebook)

“Make it full screen. :) Not fullscreen mode. I think it would be better to make it full height by default (and maybe full width). + view toggle.” (@MichaelArestad via Twitter)

“I really like the idea of Open Editor, I think as the editor opens, the customizer window should be minimized so that one could write in a full width WYSIWYG editor.” (@ahmadawais via WP Trac)

When opening a draft post in the Customizer, it would be ideal to be able to make changes and then publish the post from there. For example in a workflow to preview how changes to a title wraps: https://youtu.be/sXu2pA42J88

As part of this, we can also implement the Trash button (#137) alongside the post status dropdown.

Previewing will be dependent on #36.

To start, this can be a simple text field containing the date. For specifics regarding the UI, see #53.

Care will need to be taken when modifying the date time so that the post will continue to appear in the preview when the date is in the future. Also, it would seem logical that changing the date should result in the order of the posts changing in the preview.

There may need to be a partial registered for the display of a post date. If not, then the entire content part will need to be refreshed (#36).

https://core.trac.wordpress.org/ticket/28605

Deep links to posts in the Customizer look like this: http://src.wordpress-develop.dev/wp-admin/customize.php?autofocus[section]=post[post][1234]&url=http%3A%2F%2Fsrc.wordpress-develop.dev%2F%3Fpost_type%3Dpost%26p%3D1234.

Populate settings for post_content and other post fields with the previewed values, so they will appear in the customizer. Including postmeta may be tricky. See https://core.trac.wordpress.org/ticket/20299

When there are post save conflicts due to concurrent editing of a post, the post fields get an error message indicating the their version of each conflicted field. In addition to showing the error message, we should focus on the first specific conflicted field (if the section is expanded), instead of just focusing on the first control regardless.

When editing postmeta or some aspect of a post that does not have a specific partial, the entire post will need to be updated in the preview as opposed to just the specific partial representing the field modified. In all of the core themes, the posts have a content template part which is a perfect candidate for this. So when editing a post field or post meta that doesn't have a partial (or placement) in the preview, the fallback should be refreshing the entire post template part. This will require a new WP_Customize_Partial that is aware of the path to the template part, whether it is content, template-parts/content.

The editor is not currently optimized for mobile in the Customize Posts integration.

Deeper UX/UI work is needed on the mobile editor, but some issues that could improve thing:

• Collapse button for editor should not get overlapped by editor.
• Editor shouldn't get positioned above other controls when pane is expanded. Editor should appear inline.
  
• Editor should be able to expand to full screen in mobile properly.
  

Depends on #58

After hitting:

It does not change to "Saved" but remains stuck.

Instead of having one monolithic control, there should be separate controls for:

• Title
• Content
• Excerpt
• Publish Date
• Slug
• Author
• Status
• Parent
• Menu order
• Page template
• Featured image
• Meta (custom fields)

Doing it in this way will help users opt-in to the fields they need, and it would make it easier to extend and add new controls more modularly for metaboxes.

We'll also need to break up the settings as well.

The gotcha here is the "Select post to edit" dropdown. In the way it is right now, it would be hard to manage the breakup into individual controls because everything is in one section. An alternative is to switch to using panels, so each post resides within a section in a Posts panel. This would require sections to be dynamically generated in the panel, but there is no JS API for this right now (see #28709).

In the mean time, it is probably better to get rid of the "Select post to edit" control altogether, and automatically load up posts when the preview has them as the queried object.

A page template and featured image are both stored in postmeta. These should use a WP_Customize_Postmeta_Setting with unique UIs for a page dropdown and (re-used) image media selector control. These can serve as the basis for creating more complex controls that map to multiple postmeta, or a control which manipulates a non-scalar postmeta value (an array).

If the editor is expanded and the collapse link for the Customizer pane is clicked, the pane will slide away but the button to re-expand the panel will be behind the editor and so the user will be stuck.

See https://core.trac.wordpress.org/ticket/39389

Just as the Customizer has a sanitize_js callback, which converts a PHP value into an equivalent JSON representation which then gets converted back to PHP when saving/previewing, we could take the same approach for handling PHP-serialized postmeta.

It would be handy to have a keyboard shortcut to open and close the editor instead of clicking the button. I thought Ctrl+Shift+E on PC and Cmd+Shift+E on Mac would make sense.

I created a feature branch with this functionality, but realised its probably better to do a fork to PR back. Will fix.

Related to #7

This problem is being addressed by the Frontend Editor project, so any effort here should be harmonized.

If the user changes the post_name or changes the post parent, it could be that the post being previewed could become a 404 in the preview. So the URL should update when it is changed.

• Pre-select the currently-previewed post.
• Allow any number of posts to be added to the customizer for previewing. Each post gets its own dynamically-created control (and setting).
• Use the queried-posts message from the preview to suggest which post to edit.
• Send the queried object post as the highest suggestion.

This could also be how page hierarchy is managed.

Careful we don't want to duplicate existing logic for nav menu management.

When adding a nav menu item to a nav menu, if the desired post/page does not exist yet, there should be a way to create it right then and there. With a stub post initially created, there can be a link to flesh out the post in the Customizer. This is the opposite of #51

Depends on #48.
Requires #156.

See https://core.trac.wordpress.org/ticket/34923

This will help ensure that changes to the post_name won't result unexpectedly in the preview showing a 404, or requiring the preview to change the URL being previewed when editing a post.

Published date input can use the type="date"

I would have submitted a PR but looks like the new version doesn't contain this date input meta only W.org version does.

— We can use type="date" here (In the old W.org repo version)

GPL? What?

A post should be able to be assigned to a category, post tag, post formats, or any other taxonomy and see a preview of what would happen.

When hovering or focusing on a collapsed section for a post, the element with the post_class() should receive a highlight, such as a flashing outline, as is currently implemented for widgets.

The post elements made available by Shortcake should be able to be added and manipulated in Customizer editor.

When a post_content partial is refreshed, any dynamic elements like Twitter and Facebook, need to be dynamically constructed such as has started to be developed for widgets in Jetpack: https://github.com/xwp/wp-customize-partial-refresh/blob/master/js/plugin-support/jetpack.js

And which Jetpack's Infinity Scroll does for post content: https://github.com/Automattic/jetpack/blob/master/modules/infinite-scroll/infinity.js

In fact, if we just trigger the post-load event when a post content partial is refreshed, this may get us most of the way by allowing us to piggyback on Jetpack's infinite scroll.

I love the concept. Want to integrate it in as a feature of Redux Framework perhaps? We're one of the largest option frameworks out there and we already have a really powerful metaboxes extension that does stuff like this:

It would be amazing to add a preview option as well to that. ;)

Depends on #1.