googleforcreators / web-stories-wp

Web Stories for WordPress

Web Stories for WordPress

Visual storytelling for WordPress.

Build Status

Web Stories are a free, open-web, visual storytelling format for the web, enabling you to easily create visual narratives with engaging animations and tappable interactions, and immerse your readers in great and fast-loading full-screen experiences.

With Web Stories for WordPress, we're bringing first-class Web Stories support to WordPress. Use Web Stories for WordPress by installing it directly from the WordPress admin dashboard or manually downloading the plugin from the WordPress.org plugin directory.

Support

If you find any issues, please reach out by visiting the support forum to ask any questions or file feature requests.

Contributing

We'd love to accept your patches and contributions to this project. There are just a few small guidelines you need to follow. Please check out our Contributing documentation and the Getting Started guide.

web-stories-wp's Issues

Copy and Paste Keyboard Shortcut

Feature description

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

• Would like to tie these action to keyboard shortcuts

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

• Ensure that Copy&Paste works with keyboard shortcuts outside of the context menu.
• The Page block should handle the pasting event.

Implementation brief

QA testing instructions

Demo

Changelog entry

Buttons

Feature description

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:

• Various buttons / links used for user interactions.

UX Required: Yes

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

• The existing Buttons are ported to the new stories editor
• The Buttons are integrated into the new design

Implementation brief

QA testing instructions

Demo

Changelog entry

Page Reordering

Feature description

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

• Design has not been finalize for this. Ideally we need a UI that lets a users quickly view all pages (especially if the pages exceed the the width area at the bottom) and drag and drop to reorder.

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

• The existing Page Reordering is ported to the new stories editor
• The Page Reordering is integrated into the new design

Implementation brief

QA testing instructions

Demo

Changelog entry

Pre-publish Tab and Checklist MVP

Feature description

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?

Product brief

MVP requirements (for this ticket)

1. P0: A simple list of errors, should indicate where the error is found (page #) at a minimum. Bonus points if by clicking on the error it takes me into the issue itself.
2. P0: List grouped by error type, P0 is errors, the rest are P1+ and could be added over time.
3. P0: If issues exist, they should not block creators from publishing their stories
4. P0: Add badging to Pre-publish tab so creators are aware issues exist.
5. P0: Add tooltip to publish button to help raise awareness that issues exist
6. P1: Add links to existing doc and help articles (bonus)
7. P1: Add badging to dashboard for stories (both draft and published) that have publishing issues.

Figma designs MVP Final

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

1. The helper component is created (framework, not including the canvas)
2. Additional helper features are able to be added in future tickets
3. The test for missing alt text is implemented
4. I am able to see if the post is live or not
5. I am able to view the post (story)
6. I am able to copy a link to the story
7. I am able to embed my story in a newly published WordPress post
8. I am able to embed my story in a newly drafted WordPress post
9. The checklist tells me if I am missing a feature image
10. The checklist tells me if a poster image is missing
    See #50 for multi resolution check on checklist

OLD AC (Additional tickets for the Helper Tool will be created) :

1. Helper is a mode that the user can turn ON and OFF to get design guidance.
2. After helper mode is turned on, the user sees visual guidance as they create their story.
3. The Pre-publish helper is shown on the right hand side under the Checklist Panel tab.
4. The same guidances from the helper are shown in the Checklist.

Implementation brief

QA testing instructions

Demo

Changelog entry

Block Component

Feature description

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:

• Block is not really a component per se, registering a block is really creating a set of directives based on what a component is put together.
• The block “module” includes everything related to editing and rendering a block, including settings in the sidebar, block drag handle, settings, alignment options, etc.

UX Required: ?

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

• The existing block component is ported to the new stories editor
• The block component is integrated into the new design

Implementation brief

QA testing instructions

Demo

Changelog entry

[Research] In-place editing

Feature description

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.

Acceptance criteria

• A suggestion is made based on the findings

Implementation brief

QA testing instructions

Demo

Changelog entry

Discovery: Storing templates in the database

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:

• A new amp_template custom post type.
• Using wp_blocks (reusable blocks post type)
• Using the amp_story post type but with an extra meta for noting it being a template.
• Hard coding them in JSON format.

AC2: Based on the doc there is a clear recommendation for which option to choose.

Things to consider:

• The user will be able to edit the templates (which requires very similar editing experience as for Stories)
• The user will be able to delete templates.
• The user will be able to convert a Story (or a Page) into a template.

Animations

Feature description

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.

Product Brief

Figma

This ticket should also unblock:

• #2206
• #2207
• #2208
• #2210
• #2212
• #2211

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Implementation brief

• See PoC: ampproject/amp-wp#4020.

QA testing instructions

Demo

Changelog entry

Sidebar / Document Inspector functionality.

Feature description

This ticket was made out of this conversation in slack.

"Old" Editor:

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

• The post visibility: Private functionality is ported into the new editor
• The post visibility: Public functionality is ported into the new editor
• The post visibility: Password Protected functionality is ported into the new editor
• The post status: Published functionality is ported into the new editor
• The post status: Draft functionality is ported into the new editor
• The post status: Scheduled functionality ( selection of publish date ) is ported into the new editor
• The post author functionality is ported into the new editor
• The move post to trash functionality is ported into the new editor
• The post permalink functionality is ported into the new editor
• The post excerpt functionality is ported into the new editor
• The featured image functionality for setting meta tags as primary image is ported into the new editor
• Author assignment and publish fields should only show to user that have this capability.

Implementation brief

• Load a list of users into state from REST API
• Load a list of post into state from REST API
• Do capability checks for publish / select author. If user does not have cap, do not show option.
• Refactor uploadMedia to be more reusable.
• Add field to REST API to get feature image.

QA testing instructions

Demo

Changelog entry

Moveable: dragging and rotating multi-selected elements

Feature description

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.

Acceptance criteria

• It's possible to resize, drag, rotate multiple selected elements at once.

Implementation brief

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.

Dragging

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.

Rotating

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

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:

• Boundaries
• Resizing limits
• Keyboard events (common practices TBD by UX)
• Content within the elements

QA testing instructions

Demo

Changelog entry

Notifications

Feature description

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

• Notices and errors displayed in admin when something happens or an action is completed (e.g. "Story saved" or an error occurred, etc.

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.

Acceptance criteria

• The existing notifications are ported to the new stories editor
• The notifications are integrated into the new design

Implementation brief

QA testing instructions

Demo

Changelog entry

Color Picker - Solid Background

Feature description

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

• Setting in the right sidebar which allows choosing text and background colors.

UX Required:

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

• The existing color picker is ported to the new stories editor
• The color picker is integrated into the new design

Implementation brief

QA testing instructions

Demo

Changelog entry

Document Panel - Auto Advance Functionality

Feature description

As an author I want to be able to set auto advanced settings for my story

Epic: Document Workflow

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

1. The author is able to set the story to auto-advance between pages
2. Auto-advance is the default behaviour
3. After selecting auto-advance, a duration slider is shown
4. The author is able to set the default page duration via slider ranging from 1 - 20 seconds.
5. The default auto-advance is set to 7 seconds,
6. The slider stepping should increment by 0.1 seconds. e.g. 1.0, 1.1, 1.2...
7. The default page duration is automatically overridden by video, audio or non-looping animation
8. If any of the above 3 elements are on the page, the page auto-advances after the element with the longest duration has finished playing.
9. The author is able to set the story to manually advance between pages
10. These settings are global (per story) not per page

Implementation brief

QA testing instructions

Demo

Changelog entry

Moveable: Visual/general Improvements for Dragging, Resizing, Rotating

Feature description

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.

Acceptance criteria

• Moveable component is a separate component outside of Page.
• Resizing/rotation handles are hidden while dragging (NEEDS UX CONFIRMATION)
• Resizing has minimum limits and doesn't allow decreasing an element to non-existing (NEEDS UX CONFIRMATION).
• Move the element itself instead of the outline.
• Dragging is possible without selecting the element first. The element will be selected after the dragging event (see Figma for details).

Implementation brief

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.

QA testing instructions

Demo

Changelog entry

Accessibility Review for Stable

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).

Overview doc for reference

Remove `the_content` Filter

Feature description

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.

Acceptance criteria

Implementation brief

QA testing instructions

Demo

Changelog entry

Design Panel

Feature description

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:

• Handles the sidebar on the right including Document and Block settings

UX Required: Yes

• This should include a new Checklist section which is closely tied to HELPER mode

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

• Create our custom sidebar since we need a different layout / order and more control on the sidebar.
• The Settings Sidebar is integrated into the new design
• Include a new Checklist section which is closely tied to HELPER mode

Implementation brief

QA testing instructions

Demo

Changelog entry

Text Element: alignment, letter-spacing, line-height, font-style

Feature description

Implement Text element basic features, this includes:

• padding
• text alignment
• letter spacing
• line height

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.

Acceptance criteria

Text element:

• User can change line-height.
• User can change letter-spacing
• User can change padding.
• User can align the text.

Implementation brief

QA testing instructions

Demo

Changelog entry

Create CSS theming for stories editor

Feature description

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:

• Use styled-components or emotion (still undecided as of ampproject/amp-wp#3712) to style core components.
• Add sensible class names to relevant components, document what these class names represent and how they can be used for theming.

We can go about this in two way:

1. Create the default theme using our internal styling method (CSS-in-JS) as done in WordPress/gutenberg#17963) and simply document how others can use the classes to alter the default theme. We can then potentially create alternative themes using this method later.
2. Use no theming in our internal styling method (CSS-in-JS) and create the default theme using the same means, that we would expose to others as the primary way of creating a theme. We can then use this default theme to create alternative themes later.

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.

Acceptance criteria

• AC1: Select and document our theming approach.
• AC2: Figure out where and how we document how to create themes.
• AC3: If necessary, create the default theme using this approach.

Implementation brief

QA testing instructions

Demo

Changelog entry

Measurement units in the editor and in the FE (`px` vs `%`)

Feature description

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.

Acceptance criteria

• AC: Create test cases in which using % works
• AC: Create test cases in which using % does not work

Implementation brief

QA testing instructions

Demo

Changelog entry

Page (Thumbnail) Preview

Feature description

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:

• Component that allows displaying a block (or a set of blocks aka template) in a disabled mode just for previewing, users can't interact with it but can see how it looks like. That was used for templates and also for reordering Pages.

UX Required: Yes

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

• The existing Page (Block) Preview is ported to the new stories editor
• The Page (Block) Preview is integrated into the new design

Implementation brief

QA testing instructions

Demo

Changelog entry

Media Upload Button

Feature description

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.

Epic: Media upload and management

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

• When a user clicks on the Upload button, a WordPress media manager dialog should appear.
• This should show the upload tab by default.
• Where possible uploads / results should be filtered to only show support file formats.

Implementation brief

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.

QA testing instructions

Demo

Changelog entry

Discovery: Reusability of current components / features

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.

• List out all the components / features in the sheet
• Write a description and review of what needs to be done for each component/feature.

Editor: Add link to revisions

Feature description

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:

https://fonts.google.com/icons?selected=Material%20Symbols%20Outlined%3Ahistory%3AFILL%400%3Bwght%40400%3BGRAD%400%3Bopsz%4048

Review Testing Strategy

Feature description

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:

• Write tests. Not too many. Mostly integration.
• Write fewer, longer tests.

Preliminary considerations include the following stack:

• jest for overall test running.
• react-testing-library for setup, manipulation and validation of React components.
• puppeteer for running a limited set of e2e tests.
• axe for accessibility testing.
• storybook for visual unit testing.

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

• AC1: This ticket is to begin the review and discussion surrounding the existing testing strategy (e.g. e2e tests).
• AC2: Additionally, we should be looking into the automation surrounding accessibility testing, as we examine our testing strategy as a whole.
• AC3: Testing should consider the new editor being developed

Implementation brief

QA testing instructions

Demo

Changelog entry

Page Remove Button

Feature description

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.

Acceptance criteria

• The existing Page Remove Button is ported to the new stories editor
• The Page Remove Button is integrated into the new design

Implementation brief

QA testing instructions

Demo

Changelog entry

Page Inserter

Feature description

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:

• Inserts a new page when clicked on, without having to search for a block.

UX Required: Yes

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

• The existing page inserter is ported to the new stories editor
• The page inserter is integrated into the new design

Implementation brief

QA testing instructions

Demo

Changelog entry

Deprecation

Feature description

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.

Acceptance criteria

• A suggestion is made based on the findings

Implementation brief

QA testing instructions

Demo

Changelog entry

Snapping

Feature description

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:

• Snapping of blocks to align with other existing blocks or Page (e.g. centering)
• Displays snap lines when a block is moved

UX Required: Yes

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

• Choose a library (e.g. https://daybrush.com/moveable/) that would already handle the resizing + rotation + moving + snapping and implement that with the blocks instead.
• Snapping is integrated into the new design

Implementation brief

QA testing instructions

Demo

Changelog entry

Animations

Feature description

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:

• Setting in the right sidebar responsible for assigning animations to a block and previewing animations.

UX Required: Yes

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

• The existing animations are ported to the new stories editor
• Need to adjust the preview etc. with the new block structure in the editor.
• The animations are integrated into the new design

Implementation brief

QA testing instructions

Demo

Changelog entry

CTA Validation

Feature description

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

• This will be part of the Global error handling work

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

• The existing CTA Validation is ported to the new stories editor
• The CTA Validation is integrated into the new design

Implementation brief

QA testing instructions

Demo

Changelog entry

All elements

Feature description

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:

• Image (special element for Gif perhaps - with extra settings)
• Video
• Text
• Shape (new, probably SVG based)
• Embed

And some elements not necessarily duplicated and definitely less important:

• Source code
• Preformatted
• Quote
• List
• Table
• Verse
• Post author
• Post date
• Post title
• HTML

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

• A suggestion is made based on the findings

Implementation brief

QA testing instructions

Demo

Changelog entry

Keyboard Shortcuts

Feature description

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.

Acceptance criteria

QA testing instructions

Block Inserter

Feature description

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:

• The "+" icon in the left Toolbar which allows searching and inserting blocks.

UX Required: Yes

• Team is still investigating whether any of the Gutenberg blocks are useful for visual stories

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

• The existing block inserter is ported to the new stories editor
• The block inserter is integrated into the new design

Implementation brief

QA testing instructions

Demo

Changelog entry

Improved UI for Story Settings

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

Library Toolbar

Feature description

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:

• Media inserter
• Insert background image / video
• Insert image / video block
• Block inserter
• Shortcuts

UX Required: Yes

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

• Create a new custom toolbar (not ported from the old one)
• The font picker is integrated into the new design

Implementation brief

QA testing instructions

Demo

Changelog entry

Storing Story content in the DB (JSON)

Description

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

Acceptance Criteria

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.

Implementation brief

• Modify the REST API controller, so it accepts 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.

• Implementation will tracking the following fields in WP
  • Title
  • slug ( post name ).
  • Status ( Post status ) i.e Published, auto-draft or draft.
  • Author
• useLoadStory will be changed to load these fields into state.
• Add a useSavePost, to change the call to the API hook useAPI and setting the isSaving global state.
• An isSaving state will be tracked, so a spinner can be displayed to user and save button disabled while saving.

PoC can be found here.

QA testing instructions

Demo

Changelog entry

Moveable Library for Resizing Rotating and Dragging

Feature description

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.

Acceptance criteria

• Research https://daybrush.com/moveable/ to see if it can handle the resizing of blocks.
• Research https://daybrush.com/moveable/ to see if it can handle the rotation of blocks.
• Research https://daybrush.com/moveable/ to see if it can handle the moving of blocks.

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.

Implementation brief

The conclusion from looking into Moveable is that it can be used for Resizing, Dragging, and Rotation.

• See this commit for a partially working demo of Moveable within our code and attaching it to an element. Note that this code does not update the properties of the moved/resized/rotated block yet, however, it shows that we can use Moveable.

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.

QA testing instructions

Demo

Changelog entry

Font Picker

Feature description

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:

• An autocomplete field used to pick font from list of defined google fonts.
• The font picker simple implements an autocomplete library. The autocomplete library is overwritten to add a clear autocoplete field. The list of google fonts will need be hydrated to new component.

UX Required: Yes

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

• The existing font picker is ported to the new stories editor
• The font picker is integrated into the new design

1. A simple dropdown is displayed to select fonts (font family). (Additional functionality will be added later in new issues)
2. Ensure the dropdown is performant (previously we were loading 1000s of fonts)

Implementation brief

PHP

• Abstract off current font code AMP_Fonts, so not linked to old implemenation found in class-amp-story-legacy-post-type.php
• Create a basic REST API to all font data into the stories editor.
  • Only load new API if new editor is enabled.
  • Make the API limited to only those who can editor a post can access.
  • Set a limit to API of 1000. ( In the future we may wish to paginate results )
• Load all fonts into state when editor is loaded. It is likely that font data will be used. ( In future will may wish to look at lazy loading this data in for performance reasons ).
• Load fonts from google fonts in Admin and front end, by looping through list of elements and exacting font family.

JS

• Create a basic select ( dropdown ) menu UI element for panels.
• Load all fonts into state when editor is init.
• Port maybeEnqueueFontStyle function from old stories editor.
• Load font when text element is displayed.
• Create a dropdown listing all fonts.
• Create a new FontProvider to store state of fonts.
• Change font weights list of avalible when font is selected.

PoC

QA testing instructions

Demo

https://youtu.be/lglp7C7y8U8

Changelog entry

Existing Carousel (w/ page reordering)

Feature description

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):

• Indicators below the Story Pages which allow selecting Pages and reordering Pages. There's one indicator displayed per each Page

UX Required: Yes

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

• The existing carousel is ported to the new stories editor
• The carousel is integrated into the new design

Implementation brief

QA testing instructions

Demo

Changelog entry

[Research] Rich text editing

Feature description

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.

Acceptance criteria

• A suggestion is made based on the findings

Implementation brief

QA testing instructions

Demo

Changelog entry

Allow different post types to use Stories editor

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:

• For example, a site that entirely focuses on stories (e.g. a blog of stories where the homepage is an archive of stories). There's no need for such a site to have two separate post types 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.
• Another (more edge case) variant is a (probably experimental) site that is a story. There are super simple image blogs out there with no other content whatsoever (like https://officetoday.wordpress.com, https://fishtacos.blog, or my own https://cocktails.felix-arntz.me), for which this may be an interesting alternative approach: a single story-like experience where each post is a story and they visually connect almost like a greater story in itself.

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.

Suggestions

• One of the following approaches could be used (or they could be combined):
  1. Allow post types to add support for stories / amp_stories or similar.
  2. Introduce a filter like 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.
  3. Introduce a filter like 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.
• Once such a mechanism exists, the rest would be fairly straightforward. We would need to replace all related post type checks in the plugin againnst the 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).
• Some of the styles for the Stories editor apply against .post-type-amp_story. This should be replaced with a more generic class specifically introduced for that purpose.
• Last but not least, we should make sure that someone unregistering the amp_story post type does not cause any side effects. I believe that's already the case today though, but still flagging it.

CTA Block

Feature description

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.

Acceptance criteria

• The existing CTA Block is ported to the new stories editor
• The CTA Block is integrated into the new design

Implementation brief

QA testing instructions

Demo

Changelog entry

Discovery: CSS-in-JS library

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.

Allow deleting a Page via "Delete" icon

Feature description

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.

Acceptance criteria

• The user should be able to remove a Page by clicking the Trash icon above the Page.

Implementation brief

• Add a new action for deleting the currently selected Page.
• When the Delete icon is clicked, the currently selected Page will be removed.

QA testing instructions

Demo

Changelog entry

Right-click / Context Menu

Feature description

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

• Copy, Paste, Delete
• Layer manipulation (Send to Back, Send Backward, Bring Forward, Bring to Front)
• Add link

Right click on media element in foreground

• Set as background
• Zoom/Crop

Right click on page with no background

• Copy would copy the background color

Right click on page with background image

• Copy would copy the background image to be pasted as background on another page
• Detach image from background
• Zoom/Crop (equivalent to double-click)

Note: some of these may not make sense to include if included in the Quick Actions menu #5896

Yoast SEO Integration for Metadata

Original discovery ampproject/amp-wp#3179

• Contribute upstream pull request to Yoast SEO.
• Test integration with Yoast
• Add Yoast SEO to testing environment

Special elements: CTA and Page Attachment

Feature description

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.

Acceptance criteria

• A suggestion is made based on the findings

Implementation brief

QA testing instructions

Demo

Changelog entry

Proof of concept: replacing edit-post package

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.

Full-bleed Components

Feature description

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.

Acceptance criteria

• A suggestion is made based on the findings

Implementation brief

• PoC: ampproject/amp-wp#3911
• Fullbleed is related to background, but not the same thing. The background feature is in TODO.
• There are three major issues with fullbleed components: "Layout fullbleed component", "Toggle fullbleed mode in the edit panel", "selectable/transformable changes". The PoC address "layout" and "edit panel" cases.
• PoC opts for a separate 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.
• At least x/y should be hidden/disabled in the edit panel. The PoC currently disables x/y/w/h/r. Will confirm this with the UX.
• PoC introduces units context to translate between "story units" and "editor pixels".
• PoC pushes isFullbleed editor into a single FullbleedLayerPanel.
• This story has strong dependencies on #71, Display/Edit mode, and decision on whether the wrapper can be used for x/y/w/h/r.

QA testing instructions

Demo

Changelog entry