googleforcreators / web-stories-wp Goto Github PK
View Code? Open in Web Editor NEWWeb Stories for WordPress
Home Page: https://wp.stories.google
License: Apache License 2.0
Web Stories for WordPress
Home Page: https://wp.stories.google
License: Apache License 2.0
As an author I want to be able to set auto advanced settings for my story
Do not alter or remove anything below. The following sections will be managed by moderators only.
The current approach of having the amp_story
post type and exposing the editor there covers well the (probably most) common case of using stories within a "traditional" website content infrastructure. However, there are cases for which it doesn't work as seamlessly:
post
and amp_story
. While such a site could theoretically hide the backend UI for posts, the functionality of the post
post type is unfortunately (way too) deeply integrated into WordPress's behavior, so a straightforward approach would be to just have posts behave as stories.In both of these cases, having an amp_story
post type in addition to WordPress's default content infrastructure is unnecessary. While what we currently support is probably most common, we should decouple the AMP story editor from a specific post type. For now, at least developers should be able to modify the default behavior.
stories
/ amp_stories
or similar.amp_stories_enabled_for_post_type
that receives the current $post_type
as argument. While this would have the same outcome as the above, it may be more suitable since it's more verbose, and having a post type become an AMP story is a quite substantial change, different from other post type features like title
, or revisions
.is_amp_story
receiving the current $post
as argument. This may be a bit too granular though, and particularly for the new post screen it might be tricky. But I still wanted to throw this idea in the mix.amp_story
post type with function call, e.g. post_type_supports( $post_type, 'amp_stories' )
(approach 1) or amp_stories_enabled_for_post_type( $post_type )
(approach 2)..post-type-amp_story
. This should be replaced with a more generic class specifically introduced for that purpose.amp_story
post type does not cause any side effects. I believe that's already the case today though, but still flagging it.As a contributor, I want to have a better testing strategy.
Our test strategy will be mainly informed by the ideas of Kent C Dodds.
The most important aspects of his thinking is covered in these posts:
Preliminary considerations include the following stack:
Do not alter or remove anything below. The following sections will be managed by moderators only.
The CTA element was one of the more complex elements in the old editor, as it came with a bunch of restrictions and special handling logic. This needs to be properly abstracted in the new editor to avoid special cases sprinkled across the code.
Page Attachment is another element with related restrictions, but not as many as the CTA. However, their restrictions are also combined - you can only have one of any of them on a page - either none, one Page Attachment or one CTA. That’s a fairly annoying business requirement, that calls for some very specific code.
UX will take lead after being informed about all the potential pitfalls.
Do not alter or remove anything below. The following sections will be managed by moderators only.
Animations in Web Stories provide more freedom for creators to make stories stand out as more immersive and differentiated. Web Story animations can be very elaborate. We are balancing full flexibility with simple-to-use controls in the Web Stories editor, and as such the range of supported features is necessarily limited.
In future versions of the editor we will continue to expand what the story editor supports.
This ticket should also unblock:
Do not alter or remove anything below. The following sections will be managed by moderators only.
This ticket was taken from a row in this spreadsheet. This ticket can be used to track research and work related to porting this existing feature from the "old" editor to the "new" editor.
Settings Sidebar:
UX Required: Yes
Do not alter or remove anything below. The following sections will be managed by moderators only.
This ticket was taken from a row in this spreadsheet. This ticket can be used to track research and work related to porting this existing feature from the "old" editor to the "new" editor.
Page (Block) Preview:
UX Required: Yes
Do not alter or remove anything below. The following sections will be managed by moderators only.
This ticket was inspired by this comment in slack
Do not alter or remove anything below. The following sections will be managed by moderators only.
This ticket was taken from a row in this spreadsheet. This ticket can be used to track research and work related to porting this existing feature from the "old" editor to the "new" editor.
Buttons:
UX Required: Yes
Do not alter or remove anything below. The following sections will be managed by moderators only.
AC: A CSS-in-JS library is chosen for usage in the new AMP Stories tool.
AC: At least 2 different libraries are compared and the pros and cons brought out for each.
We need to add all the extra element types. Most are fairly trivial to add, but e.g. adding all the desired shapes to the shape library require a decent level of abstraction to reduce code duplication.
This includes the five main elements:
And some elements not necessarily duplicated and definitely less important:
Do not alter or remove anything below. The following sections will be managed by moderators only.
This ticket was taken from a row in this spreadsheet. This ticket can be used to track research and work related to porting this existing feature from the "old" editor to the "new" editor.
UX Required: Yes
TBD on design. I have not included the layers in the design and will update and flag team with design when done
Do not alter or remove anything below. The following sections will be managed by moderators only.
This ticket was taken from a row in this spreadsheet. This ticket can be used to track research and work related to porting this existing feature from the "old" editor to the "new" editor.
UX Required: Yes
Do not alter or remove anything below. The following sections will be managed by moderators only.
Not complex, but essential to get right from day one. For videos, we even want the ability to re-encode videos with external plugins if available.
Must be abstracted in order to allow easier porting to other platforms.
The old editor has a pretty confined code snippet, that can be reused.
Do not alter or remove anything below. The following sections will be managed by moderators only.
Implement the WP media manager backbone library, using media-utils
PoC.
A new source taxonomy will be added to attachment post type and a term of stories will be added to every attachment that is uploaded. This term will be used to easily filter media later.
Currently, the idea based on the new PoC is to save the data for the editor in JSON format and separately the content for rendering in the FE, in AMP HTML.
We should look into the different ideas and options to determine which is the preferred and viable way for saving the content and if there are better alternatives for the currently suggested idea.
Note that Gutenberg stores data in the post_content
field, including both the blocks' configuration and the HTML to render.
Also consider CPT suggestion from ampproject/amp-wp#3743
AC: There is a document comparing at least 2 different options for storing content in the DB for editor + the FE.
AC: A suggestion is made based on the findings.
story_data
and saves this to the post_content_filtered
field on the WP_Post
object.content_filtered
will be registered as an array, so care must be taken to use wp_json_encode
and json_decode
where possible.useLoadStory
will be changed to load these fields into state.useSavePost
, to change the call to the API hook useAPI
and setting the isSaving
global state.isSaving
state will be tracked, so a spinner can be displayed to user and save button disabled while saving.PoC can be found here.
This ticket was taken from a row in this spreadsheet. This ticket can be used to track research and work related to porting this existing feature from the "old" editor to the "new" editor.
UX Required: Yes
Do not alter or remove anything below. The following sections will be managed by moderators only.
This ticket was taken from a row in this spreadsheet. This ticket can be used to track research and work related to porting this existing feature from the "old" editor to the "new" editor.
Page Inserter:
UX Required: Yes
Do not alter or remove anything below. The following sections will be managed by moderators only.
This ticket was taken from rows in this spreadsheet. This ticket can be used to track research and work related to using the Moveable library.
Resizing:
Handles resizing a block from each side and corner.
Rotation:
Handles rotating a block
Block Mover/Dragging:
Handles dragging a block
Do not alter or remove anything below. The following sections will be managed by moderators only.
AC: There are documented findings with a recommendation if to use Moveable library or something else.
AC: The chosen library has been implemented to provide basic resizing, rotation and dragging.
The conclusion from looking into Moveable is that it can be used for Resizing, Dragging, and Rotation.
Overview
We will use Moveable and implement basic dragging/rotating/resizing. For the initial version, we will follow a similar logic as Google Slides has: an outline of the element is being dragged/resized/rotated instead of the element directly. Once the action has stopped, the properties of the element are updated, too. Using just the outline has the benefit of simplicity -- we won't have to worry about updating the element while it's being resized (e.g. font sizes, image ratio, etc.) which was causing a lot of issues in the previous iteration of the Story editor. This can be improved in a future iteration.
This ticket was taken from a row in this spreadsheet. This ticket can be used to track research and work related to porting this existing feature from the "old" editor to the "new" editor.
Font Picker:
UX Required: ?
Do not alter or remove anything below. The following sections will be managed by moderators only.
We need to understand what is the best way for storing templates.
AC1: A comparison document with the pros and cons brought out exists for the following options:
amp_template
custom post type.wp_blocks
(reusable blocks post type)amp_story
post type but with an extra meta for noting it being a template
.AC2: Based on the doc there is a clear recommendation for which option to choose.
Things to consider:
The right-click menu will enable easy operations without relying on remembering keyboard shortcuts or having to find some common actions in the design panel. A few actions that are difficult to find today and good candidates for the right-click menu include:
Right click on page elements
Right click on media element in foreground
Right click on page with no background
Right click on page with background image
Note: some of these may not make sense to include if included in the Quick Actions menu #5896
This ticket was taken from a row in this spreadsheet. This ticket can be used to track research and work related to porting this existing feature from the "old" editor to the "new" editor.
UX Required: Yes
Do not alter or remove anything below. The following sections will be managed by moderators only.
Previously, for the purposes of responsiveness, the width, height, and positioning of the element were all measured in percentage. This ensured that if an element took half of the width of a Page in the editor that it would do the same in the FE independent of the viewport measures.
There have been suggestions for an alternative approach using pixels instead.
Do not alter or remove anything below. The following sections will be managed by moderators only.
Basic text fields have limited rich text editing capabilities in the old editor. We need some level of support in the new editor too. It needs to support at least: bold, italic, underline and pasting text with these features. Are links supported? If so, can you only create links by pasting?
The old editor uses Gutenberg’s RichText component, but it seems to be pretty stuck inside the Gutenberg block-editor package and would probably need forking to be reused. Some of the internals are separated into its own package however, but not all of it.
Alternatively, find another well-licensed open editor, we can reuse.
This is an important discovery required for this to be a viable approach.
Do not alter or remove anything below. The following sections will be managed by moderators only.
Implement Text element basic features, this includes:
Note that Text element font size adjustment when resizing is handled within #9
Note that Text element font-size adjustments when updating font-related attributes, padding, or typing is handled within #8
Do not alter or remove anything below. The following sections will be managed by moderators only.
Text element:
In Gutenberg there's a link to the revisions comparison screen in the document tab when there are some:
It would be nice to do the same in the story editor as well, maybe in the PublishPanel
component (packages/wp-story-editor/src/components/documentPane/publish/publish.js
) below the poster image / publisher logo setting
We can use a similar icon as well:
Original discovery ampproject/amp-wp#3179
This ticket was taken from a row in this spreadsheet. This ticket can be used to track research and work related to porting this existing feature from the "old" editor to the "new" editor.
Block Inserter:
UX Required: Yes
Do not alter or remove anything below. The following sections will be managed by moderators only.
This is a follow-up issue for ampproject/amp-wp#3798.
Also to consider: keypress events for resizing, rotating, dragging. That's on hold though until we have information about the best practices using keyboard for doing that.
Do not alter or remove anything below. The following sections will be managed by moderators only.
When more than one element is selected, one additional Moveable will be displayed which has all the selected elements as targets in an array (target={ arrayOfTargets }
). Moveable displays an outline around the selected elements by default:
For dragging, resizing, and rotating, we will need to set the initial values to the frames
as an array of objects, e.g.
const frames = [
{
translate: [ 0, 0 ],
rotate: rotationAngle1,
},
{
translate: [ 0, 0 ],
rotate: rotationAngle2,
},
];
where rotation angle should be the respective initial rotation angle of each element.
Based on the documentation, this should work for updating the style for all the elements while dragging in onDragGroup
(tested and it does work):
events.forEach( ( { target, beforeTranslate }, i ) => {
const frame = frames[ i ];
frame.translate = beforeTranslate;
target.style.transform = `translate(${ beforeTranslate[ 0 ] }px, ${ beforeTranslate[ 1 ] }px)`;
} );
Then, in onDragGroupEnd
we can update the x
and y
params of all the elements by adding the translate
values to the original x
and y
.
Rotation works in a similar way with a difference that once we finish rotating, we can just set the rotation angle directly from the frames
values as the updated element property since it already considers the initial rotation angle as well.
Resizing works in a similar way as resizing for a single element with the difference of having to loop through the targets to assign the values to each target separately.
Within this issue, in all three cases, the element values in the state are updated only when ending the activity, within onResizeGroupEnd
, onDragGroupEnd
and onRotateGroupEnd
.
The selected elements should remain selected.
For simplicity, this implementation of this issue will not "care" about the following:
This ticket was taken from a row in this spreadsheet. This ticket can be used to track research and work related to porting this existing feature from the "old" editor to the "new" editor.
Snapping:
UX Required: Yes
Do not alter or remove anything below. The following sections will be managed by moderators only.
This ticket was taken from a row in this spreadsheet. This ticket can be used to track research and work related to porting this existing feature from the "old" editor to the "new" editor.
Toolbar above the Page below the title which includes:
UX Required: Yes
Do not alter or remove anything below. The following sections will be managed by moderators only.
This ticket was taken from a row in this spreadsheet. This ticket can be used to track research and work related to porting this existing feature from the "old" editor to the "new" editor.
Font Picker:
UX Required: Yes
Do not alter or remove anything below. The following sections will be managed by moderators only.
AMP_Fonts
, so not linked to old implemenation found in class-amp-story-legacy-post-type.php
maybeEnqueueFontStyle
function from old stories editor.FontProvider
to store state of fonts.This ticket will now be for solid backgrounds only. Color picker and Gradient editing to be done in other tickets.
This ticket was taken from a row in this spreadsheet. This ticket can be used to track research and work related to porting this existing feature from the "old" editor to the "new" editor.
Color Picker
UX Required:
Do not alter or remove anything below. The following sections will be managed by moderators only.
This ticket was made out of this conversation in slack.
Do not alter or remove anything below. The following sections will be managed by moderators only.
How does full-bleed components work? This will be used a lot, so it has to be considered carefully. Should width-height be disabled in the inspector panel? What if you want to zoom in even more on a full-bleed image?
Also, we need to consider how to select the page itself when a full-bleed element is covering the entire canvas. You can click outside the page on the background, but is that sufficiently clear to users?
It's not complex, but it's important to consider this, as it's a day-1 feature.
Do not alter or remove anything below. The following sections will be managed by moderators only.
isFullbleed
property. The reasons: it's now a truly logical property and we may want to be able to toggle back to the previously available width/height/x/y.units
context to translate between "story units" and "editor pixels".isFullbleed
editor into a single FullbleedLayerPanel
.This ticket was taken from a row in this spreadsheet. This ticket can be used to track research and work related to porting this existing feature from the "old" editor to the "new" editor.
Animations:
Do not alter or remove anything below. The following sections will be managed by moderators only.
This issue was inspire by this slack comment.
I think we should consider removing all the_content filters when rendering the story post type other than the ones we know we are using. This will prevent things like this from happening: https://wordpress.org/support/topic/amp-stories-blank-page/
This came up before as well for someone who had an estimated reading time plugin that prepended a paragraph to the content.
ampproject/amp-wp#3321
Do not alter or remove anything below. The following sections will be managed by moderators only.
AC: We have a clear understanding of which existing components / and features we can reuse after moving away from the edit-post
package.
AC: Each listed out component has been looked into and has a description and brief review of what needs to be done.
We can use this doc for the initial discussion, notes, reviews and communication before adding to the final doc. Write your name next to the component if looking into it.
As discovered in ampproject/amp-wp#3712 we need an extensible theming approach to allow other parties to re-skin the editor with different colors, fonts, etc.
We need some kind of theming approach, that will allow this in a way, that doesn't create too much work for us.
The overall idea is:
styled-components
or emotion
(still undecided as of ampproject/amp-wp#3712) to style core components.We can go about this in two way:
The former runs the risk of us not remembering to expose all relevant parts of the codebase and not documenting this properly. The latter comes with the extra work required to do double-styling - both in CSS-in-JS for functionality and layout and secondarily in a CSS file for look and feel.
The difference between the two approaches is also the need to define what constitutes "the theme". If we want to split our own CSS in "functionality" and "theme" (approach 2), we'll continually run into the problem of having to choose which CSS properties go where - does the button padding belong to functionality or theme? What about the margin? And so forth. For approach 1, that is not an issue.
Do not alter or remove anything below. The following sections will be managed by moderators only.
We need to make sure our data storage protocol is future-proof to allow future extensibility not compromising old stories, requiring complex migrations or defuncting old features.
A JSON approach is probably sufficient, but deprecation aspects need to be considered.
Do not alter or remove anything below. The following sections will be managed by moderators only.
A conflict of needs occur, when you both want the ability to drag a text element as well as select text for editing. The two interactions are indistinguishable on the surface.
The previous editor used double click to enable object editing, and then you had to click either the border or deselect/reselect to be able to drag the element around on the canvas.
Another approach could be the one used by Google Slides and similar tools. In order to drag an object, you have to click in certain places - if you just click/drag in the center of a text element, you select the text / try to insert text. We can also even have a physical anchor-icon placed next to the element that you need to use to drag the element around on the page.
In the most recent version of the Figma design document, a similar double-click-to-edit approach is suggested for editing images - in this case editing is changing the focal point and maybe even the zoom inside the available viewbox. The Figma sketch suggests a view change when double clicking (graying out the background), so it's clear that you're in “edit mode”. This same visual style can be used for other elements, text elements in particular.
For either case it’s necessary to define some sort of link from an element to the element’s editable version. Who handles this switching? Who checks if edit mode is even supported by the given element (as not all elements will have that)?
These ideas must be explored and in particular merged with whatever transformation library we go with in the above. This is however also a UX discussion.
Do not alter or remove anything below. The following sections will be managed by moderators only.
See also ampproject/amp-wp#2554.
AC: A custom package is used for displaying the AMP Stories editing screen.
AC: Stories editing screen is not dependent on edit-post
package.
AC: There is a document stating the findings from PoC.
We need a proof of concept to understand better how complex it might be to replace the edit-post
package with a custom one and what issues it might bring with. For that, we need a proof of concept which should include a custom package for displaying the Stories edit screen.
This is a follow-up issue for ampproject/amp-wp#3798.
Do not alter or remove anything below. The following sections will be managed by moderators only.
Page
.General overview:
The implementation of Moveable
will be moved to a separate file under components
and imported to the Page
instead of being part of it.
Instead of dragging/resizing/rotating just the outline and then moving the element after that, the element is manipulated directly.
For doing that, we will remove the separate Selection
element and set the element itself as the target for Moveable
directly. The Selection
element was originally to mark an outline for the selected area, however, the element (outline) created by Moveable
can replace that. We might want to add a wrapper around the original element for target for Moveable, with the actual element being inside it.
For now, we will ignore the content of the element being resizing, meaning that if there's text inside the element, the font size will stay as it is. This can later be addressed once Text editing and automatic resizing has been implemented.
Dragging will be possible without selecting the element first.
This is related to the previous point as well. Previously, the dragging was applied to Selection
which only existed if the element was selected which makes it possible to drag it even if not selected previously. This means that we will need to add a Moveable
component for each element by default for not having to repaint everything. Currently, the elements are re-rendered after selecting and there is only one Moveable
for the selected element.
Additionally, the dragged element will be selected within the onDragEnd
event. The selection should ideally persist without having to set it after each action, currently the selection "gets lost" due to backgroundClickHandler
being triggered after dragging, which clears the current selection -- needs debugging.
Currently, there is no way to remove an element (other than Undo after creating it). It should be possible to delete a Page.
Do not alter or remove anything below. The following sections will be managed by moderators only.
The helper tool is not fully described yet (if at all), but we're assuming it will contain some kind of smart positioning of elements in a grid, perhaps with margins.
The pre-publish checklist is a list with critical and recommended idea. Easy to visually make, but complex to create. UX and product has lead on this.
Product question: Should we think about opening this up to extension early? Should other plugins be able to provide items and rules for this checklist?
MVP requirements (for this ticket)
Do not alter or remove anything below. The following sections will be managed by moderators only.
OLD AC (Additional tickets for the Helper Tool will be created) :
This ticket was taken from a row in this spreadsheet. This ticket can be used to track research and work related to porting this existing feature from the "old" editor to the "new" editor.
Carousel (below pages):
UX Required: Yes
Do not alter or remove anything below. The following sections will be managed by moderators only.
The concept of global and story settings has been introduced in ampproject/amp-wp#1995, but it may not always be clear to the user which set of settings is applied when.
We should discuss possible UI tweaks to make the feature more intuitive.
Context
https://github.com/ampproject/amp-wp/pull/3201/files#r323636486
https://github.com/ampproject/amp-wp/pull/3201/files#r323638800
We’ve recently seen some good and much needed accessibility improvements in the design panel (#2879). Let’s take this momentum to further improve accessibility to meet minimum requirements for stable release (see a11y guidelines for reference).
This ticket was taken from a row in this spreadsheet. This ticket can be used to track research and work related to porting this existing feature from the "old" editor to the "new" editor.
UX Required: Yes
Do not alter or remove anything below. The following sections will be managed by moderators only.
This ticket was taken from a row in this spreadsheet. This ticket can be used to track research and work related to porting this existing feature from the "old" editor to the "new" editor.
Notifications
UX Required: Yes
This is part of Global error + Helper mode.
Do not alter or remove anything below. The following sections will be managed by moderators only.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.