Amp-wp: Create a wp-cli script to test AMP compatibility of native WordPress widgets

Created on 2 Jan 2018  路  8Comments  路  Source: ampproject/amp-wp

Acceptance criteria:
AC1: Create a wp-cli script in the directory bin/.
AC2. This will add widgets to a sidebar, in order to test their AMP compatibility (see this script for reference).
AC2: Add an instance of every native WordPress widget.
AC3: The success message should simply ask the user to visit a page that has the sidebar. It doesn鈥檛 need to create a test page, like in create-embed-test-post.php.
AC4: Need to conduct a Discovery to determine all native WordPress sidebar widgets, and the support that exists for them today. Screenshot: https://d.pr/i/vBQaFt .
AC5: One story will be created as an outcome of the Discovery to address enhanced/added support for sidebar widgets.

Tasks

  • [x] Create script, like was done for embeds, that generates core widgets in all their relevant variations, to populate the first registered sidebar it the theme.

Most helpful comment

See also the Monster Widget

@kopepasah I think the script should just add the widgets to the first registered sidebar.

I think the script should skip adding a given type of widget if the given instance data already exists in the sidebar for that given type. That way we can just re-invoke the script to replenish a sidebar after some widgets have been deleted. The script should also sometimes create multiple instances of a given widget type when its instance properties vary the widget in significant ways. In particular I think of the Categories widget and how it allows you to list the categories as a dropdown instead of an unordered list. The dropdown will not be AMP-compatible because it depends on an inline script, whereas the UL will be fine. So this is the kind of thing that will be needed in the development of the script: finding the various permutations of core widgets that can result in any output that would not be AMP-compatible, and ensuring all are included in the script.

All 8 comments

@kienstra regarding AC2, I am not sure this will always work, as sometimes there may not be a sidebar. If we can assume that there is always at least one sidebar and to use the first registered sidebar in $GLOBALS['wp_registered_sidebars'], this this method could work.

An alternative method, however, could be creating a test page (much like in the script you mentioned) and filtering the_content to only display widgets.

Any thoughts?

CC @ThierryA @MackenzieHartung

See also the Monster Widget

@kopepasah I think the script should just add the widgets to the first registered sidebar.

I think the script should skip adding a given type of widget if the given instance data already exists in the sidebar for that given type. That way we can just re-invoke the script to replenish a sidebar after some widgets have been deleted. The script should also sometimes create multiple instances of a given widget type when its instance properties vary the widget in significant ways. In particular I think of the Categories widget and how it allows you to list the categories as a dropdown instead of an unordered list. The dropdown will not be AMP-compatible because it depends on an inline script, whereas the UL will be fine. So this is the kind of thing that will be needed in the development of the script: finding the various permutations of core widgets that can result in any output that would not be AMP-compatible, and ensuring all are included in the script.

@kopepasah could you push what you have been working on so that a BE Engineer can take over please?

@ThierryA I do not have push access to neither this repo nor our internal fork.

Originally I was building this script to add all necessary widgets to a sidebar (AC2), but I think it would be a good idea to create a AMP test widget (similar to the Monster Widget mentioned by @westonruter). This way the test widget can easily be programmatically added and removed as needed.

@kopepasah you should have access to push now to https://github.com/xwp/amp-wp

The Monster Widget serves the same purpose as what we need, but I think it's not ideal as it nests widgets inside of each other. It also is likely designed as it is to allow a user to easily drag it into a sidebar, without the availability of the command line. However, we have WP-CLI at our disposal now, and we can leverage it to fully populate a sidebar with all the various instance variations that we want to test for.

In Progress

Hi @ThierryA and @westonruter,
If it's alright, I'm going to work on this.

Sure, go for it @kienstra

Was this page helpful?
0 / 5 - 0 ratings

Related issues

westonruter picture westonruter  路  4Comments

westonruter picture westonruter  路  5Comments

maciejmackowiak picture maciejmackowiak  路  5Comments

nickcernis picture nickcernis  路  4Comments

swissspidy picture swissspidy  路  4Comments