Create a wp-cli script to test AMP compatibility of native WordPress widgets #839
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 An alternative method, however, could be creating a test page (much like in the script you mentioned) and filtering Any thoughts? |
|
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, |
|
Sure, go for it @kienstra |
Adds an instance of every default WordPress widget to the first registered sidebar. First, it checks if a widget with the same settings exists in the sidebar. Then, it conditionally creates the widget. And adds all of them to the sidebar. Mainly copies amp_get_widget_id() from import_theme_starter_content(). Props @westonruter.
Use get_attachment_url() to get the image's URL. Also, access the height and width with array index notation, Not with object operators. Also, pass array() as a second argument to get_option(). This will ensure that the default return is array().
Acceptance criteria:
AC1: Create a
wp-cliscript 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’t 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
The text was updated successfully, but these errors were encountered: