Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Gutenberg] 1008: Extend core blocks to add AMP-specific functionality. #1026

Merged
merged 33 commits into from
May 21, 2018

Conversation

miina
Copy link
Contributor

@miina miina commented Mar 19, 2018

Fixes #1008.

Note that this PR is not a complete solution. It doesn't fully implement AMP Layout, also it doesn't include overriding render_callbacks of dynamic blocks. This is partly implementing AMP Layout of all the core blocks (except for the front-end view of dynamic blocks which could be likely done in a similar way to #1010). The logic is not tested on all the blocks and was mainly using paragraph and code blocks as examples during development, and some others briefly, it's possible that some of the blocks will need separate logic.

What does the PR do?

  • Adds new ampLayout attribute to all the core blocks which are converted to AMP elements leveraging the filter blocks.registerBlockType;
  • Extends edit of each core block with filter blocks.BlockEdit. Adds Amp Layout select control to Inspector Controls (settings under Block tab when clicking on a block) which currently allows choosing between options that the specific element supports;
  • Extends save of each (non-dynamic) core block with filter blocks.getSaveElement. Wraps the saved block in <amp-layout layout=[ampLayout value] width=1 height=1></ampLayout> tags.
  • Edit: adds noloading support for relevant blocks;
  • Edit: makes amp-carousel optional for gallery shortcode;

Todo

  • Add AMP Layout attribute to embeds;
  • Add AMP Layout attribute to audio, video, image blocks, gallery;
  • Make amp-carousel optional for gallery;
  • Add noloading support for image, video, and other embeds;
  • Add tests;
  • Test everything;
  • Reflect amp layout changes in editor?

@westonruter
Copy link
Member

Oh, I wasn't aware of the amp-layout component. In my mind I was thinking specifically of the layout attribute. I think perhaps the attribute route may be better to focus on instead. In fact, some work has been done to support the layout attribute in #937 (comment) whereby the sanitizer is modified to convert data-amp-layout attributes over to layout attributes when rendering as AMP. I think this could potentially make it much easier to implement this since it would mean adding a new data attribute to existing elements rather than adding new wrapper elements. Also it would mean the data attribute could be rendered in non-AMP responses and still be valid HTML5.

@westonruter
Copy link
Member

Another AMP attribute that could be good to add support for is noloading for image, video, and other embed blocks: https://www.ampproject.org/docs/reference/common_attributes#noloading

@westonruter
Copy link
Member

For layout, one thing that comes to mind is how the editor can visually indicate the difference between the various layout attributes. To do so it would seem that we should enqueue the amp-runtime script and try to let it apply the changes to the styling based on changes to the layout attribute. (Actually, for the edit function be easier to use the amp-layout element because then changes to its layout attribute should get picked up by the AMP runtime?) Adding AMP components to the Gutenberg editor is new territory as far as I know, so some discovery is needed here.

wp_enqueue_script(
'amp-editor-blocks',
amp_get_asset_url( 'js/amp-editor-blocks.js' ),
array( 'underscore', 'wp-hooks' ),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should include amp-runtime

);
return [
inspectorControls,
el( BlockEdit, _.assign( { key: 'original' }, props ) ),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The following is what I have in mind, though it is pretty broken in my testing:

diff --git a/assets/js/amp-editor-blocks.js b/assets/js/amp-editor-blocks.js
index c4d826a..c1ad182 100644
--- a/assets/js/amp-editor-blocks.js
+++ b/assets/js/amp-editor-blocks.js
@@ -82,9 +82,14 @@ var ampEditorBlocks = ( function() {
 						} )
 					)
 				);
+
+			const original = el( BlockEdit, _.assign( { key: 'original' }, props ) );
+
 			return [
 				inspectorControls,
-				el( BlockEdit, _.assign( { key: 'original' }, props ) ),
+				wp.element.createElement( 'amp-layout',
+					{ layout: attributes.ampLayout, width: 1, height: 1, children: original }
+				),
 			];
 		};
 	};

@westonruter
Copy link
Member

I've also raised this in the amp-wp Slack channel:

Something else: in regards to leveraging AMP in the authorship of Gutenberg blocks, it is clear that we need to be able to load the AMP runtime into the Gutenberg editor itself. The editor naturally is not an AMP document so this is the “dirty AMP” scenario. We need to be able to render AMP components by React. For example, there is an open PR now to explore adding an AMP layout control blocks. In order to be able to preview how the layout will impact the block, the layout logic applied by the AMP runtime should be getting applied in the context of the Gutenberg edit function. I recall one thing needed by the runtime to be used in “dirty mode” is to disable resource management from running. There are other things that may need to be confirmed, such as dynamically re-applying class names in response to layout attribute changes at runtime. We'd appreciate any input you have

https://amphtml.slack.com/archives/C4J8QHGBZ/p1521501878000295

@miina
Copy link
Contributor Author

miina commented Mar 20, 2018

Thanks for looking into the PR and for the comments, @westonruter, very helpful thoughts!

On layout vs amp-layout tag -- looks like in case of tags that are AMP elements or get converted to AMP elements (e.g. img => amp-img) we could just add the attribute layout. However, this wouldn't work in case of non-amp elements, e.g. p or pre etc. So basically layout attribute works on AMP components and amp-layout supports any HTML as children.

Are you thinking that maybe we should add layout support only to AMP elements and not to other HTML? One option would be to use both -- amp-layout in case of non-AMP elements and layout attribute in case of AMP elements. It's true that using amp-layout as a wrapper for AMP elements that already support the layout attribute seems like overkill.

Thoughts?

@miina
Copy link
Contributor Author

miina commented Mar 20, 2018

In case of AMP elemenets and layout attribute -- as discussed in #937 (comment) it seems that would generally be better to use data-amp-layout instead of just layout, and then it should get converted correctly in the sanitizer. Do I understand correctly that this is something that doesn't exist right now and needs adding to the sanitizers within this PR?

… attributs instead of amp-layout (commented out ATM).
@westonruter
Copy link
Member

@miina:

On layout vs amp-layout tag -- looks like in case of tags that are AMP elements or get converted to AMP elements (e.g. img => amp-img) we could just add the attribute layout. However, this wouldn't work in case of non-amp elements, e.g. p or pre etc. So basically layout attribute works on AMP components and amp-layout supports any HTML as children.

Are you thinking that maybe we should add layout support only to AMP elements and not to other HTML? One option would be to use both -- amp-layout in case of non-AMP elements and layout attribute in case of AMP elements. It's true that using amp-layout as a wrapper for AMP elements that already support the layout attribute seems like overkill.

Great points. One idea is that there could be an data-amp-layout attribute added to the block's wrapper element regardless if it will be converted to an AMP component or a standard HTML5 element, and then during post-processing (sanitizer) it could look to see if any such attributes are present and then create wrapper amp-layout elements with the layout attribute for HTML5 elements, but convert data-amp-layout attributes to just layout on any AMP components.

In other words, given a <img data-amp-layout="responsive"> this could result in <amp-img layout="responsive"> whereas <div data-amp-layout="responsive"> could result in <amp-layout layout="responsive"><div>….

As I noted in #937 (comment) I'm not totally familiar with the intricacies of the AMP layout system, so take my input with a grain of salt.

it seems that would generally be better to use data-amp-layout instead of just layout, and then it should get converted correctly in the sanitizer. Do I understand correctly that this is something that doesn't exist right now and needs adding to the sanitizers within this PR?

This is partially implemented in #937 but it is not yet merged. You could copy the relevant code and put it into this PR. In particular, that PR is specifically looking at adding layout to images. You'd be looking to add it to all elements. (Note the use of wp_kses_allowed_html filter to ensure the data attributes are not removed.)

@westonruter westonruter added this to the v1.0 milestone Apr 12, 2018
@pbakaus
Copy link

pbakaus commented Apr 23, 2018

Note on <amp-layout>: This component should really be treated as an additional component, not a way to wrap everything in, as the inner portion won't magically adapt to the situation. So if you create a fill amp-layout, the inner p won't magically fill as well.

TBH, I'd not worry about the amp-layout-as-wrapper scenario too much right now, and only make it available as optional Gutenblock, and use the layout attribute for all other core AMP components.

@miina
Copy link
Contributor Author

miina commented Apr 23, 2018

@westonruter Picked up the PR today to continue work here, was looking at amp-image, amp-audio, and amp-video. Some notes on that -- it looks like although many layout options are supported for these elements, it might not make sense to display these as options for the layout for some blocks, for example in case of amp-video it doesn't look like the height and width are set by just uploading the video, meaning that some layout options for amp-video wouldn't work, and would use the fallback of fixed-height layout with default height. As an example responsive and intrinsic layout don't seem to make sense in case of amp-video, there are probably some others for other elements. Alternative would be adding additional fields to be able to set the height and width in the editor, too. Thoughts?

Also, started looking into adding Layout attribute to embeds and was wondering what would be a good approach -- the embed methods don't have access to the attributes saved within Gutenberg nor their parent HTML element (which has the data-amp-layout attribute), thus it's not so straightforward to add the layout attribute. One option could be for example filtering the content and looking for blocks that include the embed, and then adding additional param to the end of the embed URL with layout, which would be remove later. E.g. if the original URL is http://youtube.com/video123 then somehow adding ?amp-data-layout='something' to the ending, and then in the AMP_YouTube_Embed_Handler::shortcode remove that and add the layout attribute to the amp-youtube tag. Or perhaps it would be possible to override the Gutenberg embed block's save method to add the layout directly there. Or perhaps there's some other better way. Thoughts?

@westonruter
Copy link
Member

it doesn't look like the height and width are set by just uploading the video

I'm looking at a video that I uploaded in my install and I'm seeing there is a _wp_attachment_metadata postmeta that contains:

{"filesize":24004120,
"mime_type":"video\/mp4",
"length":9,
"length_formatted":"0:09",
"width":1920,
"height":1080,
"fileformat":"mp4",
"dataformat":"quicktime",
"audio":{"dataformat":"mp4","codec":"ISO\/IEC 14496-3 AAC","sample_rate":48000,"channels":1,"bits_per_sample":16,"lossless":false,"channelmode":"mono"},
"created_timestamp":1512335233}

So at least for this video there is indeed width/height. For some reason these dimensions fetched and output by the default video shortcode, but it seems it is available for us to use via wp_get_attachment_metadata().

Also, started looking into adding Layout attribute to embeds and was wondering what would be a good approach

So the problem is that a Twitter block, could look like this:

<!-- wp:core-embed/twitter {"url":"https://twitter.com/westonruter/status/988577526741061632","type":"rich","providerNameSlug":"twitter"} -->
<figure class="wp-block-embed-twitter wp-block-embed is-type-rich is-provider-twitter">
    https://twitter.com/westonruter/status/988577526741061632
</figure>
<!-- /wp:core-embed/twitter -->

And get output as this:

<figure class="wp-block-embed-twitter wp-block-embed is-type-rich is-provider-twitter">
    <amp-twitter data-tweetid="988577526741061632" layout="responsive" width="600" height="480"></amp-twitter>
</figure>

And if data-amp-layout were added to figure.wp-block-embed that the markup generated by the embed handler wouldn't be able to see it, right?

Here's an idea: what if you go ahead and add a data-amp-layout attribute to the figure element, and then in the sanitizer that is already looking for data-amp-layout attributes, look for it being on any elements that contain a single element that itself has a layout attribute, and in that case cause the outer layout to override the inner layout? In other words, if wanting to have a fixed layout for a Tweet with markup stored like:

<figure data-amp-layout="fixed" class="wp-block-embed-twitter wp-block-embed is-type-rich is-provider-twitter">
    <amp-twitter data-tweetid="988577526741061632" layout="responsive" width="600" height="480"></amp-twitter>
</figure>

This could get post-processed by a sanitizer into:

<figure class="wp-block-embed-twitter wp-block-embed is-type-rich is-provider-twitter">
    <amp-twitter data-tweetid="988577526741061632" layout="fixed" width="600" height="480"></amp-twitter>
</figure>

The question then in my mind is whether that “inheritance override” behavior should be limited to figure.wp-block-embed elements, or if it should apply to any [data-amp-layout] > [layout] elements. Maybe the override behavior should be made explicit by calling it a data-amp-layout-override attribute instead of just data-amp-layout, or maybe that is unnecessary.

*
* Modifies elements created as blocks to match the blocks' AMP-specific configuration.
*/
class AMP_Block_Sanitizer extends AMP_Base_Sanitizer {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@westonruter That's still WIP but if you happen to have time, could you check if this approach for embeds seems to make sense?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you're on the right track!

} else {
width = 600;
}
// @todo Should we try to add width and height according to the layout?
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@westonruter Another issue with AMP Layout is rendering in Gutenberg -- in case of embeds the content of the block in the editor is replaced once the content (e.g. from Youtube) has been loaded and the added attributes would get removed. The point being that currently looks like for trying to match the layout behavior in Gutenberg editor, possibly the whole edit method of the core block should be replaced. Or perhaps the width and height could be modified later, not sure. Also, since the block within Gutenberg is quite separated from the outer divs of the content, then likely it would still not show a matching result. Thoughts on showing the layout changes in Gutenberg?

public function override_gallery( $html, $attributes ) {
public function maybe_override_gallery( $html, $attributes ) {
if ( isset( $attributes['amp-carousel'] ) && false === filter_var( $attributes['amp-carousel'], FILTER_VALIDATE_BOOLEAN ) ) {
return $html;
Copy link
Contributor Author

@miina miina Apr 26, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@westonruter Added editor support for making displaying gallery shortcode as amp-carousel optional by adding a shortcode attribute amp-carousel. The attribute is hidden from the user in editor view, and the Inspector Control is displayed only if [gallery is found in the shortcode text, seems to be working as expected.
screen shot 2018-04-26 at 4 30 05 pm

Do you think this approach makes sense? Thoughts?
(Logic added within fea3434)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I think that makes sense and it seems to work great.

At first I was thinking that carousel option should also be made available to the Gallery block in addition to the gallery shortcode, but maybe that's something that will be coming in Gutenberg as a separate block type in its own right.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you think that just using amp-carousel attribute within post content when using Classic Editor for gallery shortcode could be a fix for #1065, too?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't it be the case anyway here? It's just that at the moment the user would have to manually add the amp-carousel attribute to the [gallery] to achieve that with the changes here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it would, just thinking if this should be the official fix that closes #1065, too, or if an alternative approach would be needed for that.

@miina miina changed the title [WIP] [Gutenberg] 1008: Extend core blocks to add AMP-specific functionality. [Gutenberg] 1008: Extend core blocks to add AMP-specific functionality. May 3, 2018
@miina
Copy link
Contributor Author

miina commented May 3, 2018

@kienstra Thank you for testing. Guess the PR should be ready for review.
(cc @westonruter)

@westonruter
Copy link
Member

@miina I tried adding intrinsic layout to an image. Then I tried switching to fixed-height and upon doing so I got an error in my console:

Warning: Cannot update during an existing state transition (such as within render or another component's constructor). Render methods should be a pure function of props and state; constructor side-effects are an anti-pattern, but can be moved to componentWillMount.

Additionally, the window froze, apparently due to an infinite loop until finally an error was thrown:

Uncaught Error: Maximum update depth exceeded. This can happen when a component repeatedly calls setState inside componentWillUpdate or componentDidUpdate. React limits the number of nested updates to prevent infinite loops.

It seems to be specifically a problem when setting the layout to fixed-height. I don't get this error when switching to another layout.

@westonruter
Copy link
Member

@miina also, as we chatted about today, if I add a responsive layout for example and save the post. And then I switch the AMP plugin branch back to develop and reload, I then get:

image

So I think we need to save out the layout in a class instead of data-amp-layout, but this layout-specific class shouldn't appear in the “Additional CSS Class” field when the AMP plugin is active. I think this is similar to what you did for the gallery shortcode.

@miina
Copy link
Contributor Author

miina commented May 4, 2018

@westonruter:
Fix for fixed-height issue added (separate commit b107296). Also reworked the code to use CSS classes instead of data-amp-*. Note that had to use REST API filters for saving the class to post_content without showing it in editor, let me know if this approach seems reasonable.
(Edit: found some issues with embeds, still making changes)

One additional note, this appears actually on develop branch, too. Getting this error when using an image block in editor:
screen shot 2018-05-04 at 5 31 15 pm
The responseText in the error is this:
screen shot 2018-05-04 at 5 34 09 pm
Looks like in case of attachment the content is not set and thus the error.

Can you also see this error or is it just me?

miina added a commit that referenced this pull request May 16, 2018
* Use _.extend() consistently instead of _.assign()
* Use "Default" instead "None" for non-set layout.
* Just return in each loop instead of returning true.
* Use wp.editor.InspectorControls instead of deprecated wp.blocks.InspectorControls.

_.each( component.data.ampLayoutOptions, function( option ) {
// Exclude options from layout that are not supported.
if ( 'core/image' === blockName || 'core/video' === blockName || 'core-embed/twitter' === blockName ) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It may be easier to read if the logic in this each loop were broken up into isAvailable( blockName ) functions that are defined with each of the ampLayoutOptions.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed within dbc1c7c, used notAvailable param for ampLayoutOptions, let me know if isAvailable param seems to make more sense.

data: {
dynamicBlocks: [],
ampLayoutOptions: [
{ value: 'nodisplay', label: 'No Display' },
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Strings need localization.

ampAttributes[ 'data-amp-noloading' ] = attributes.ampNoLoading;
}

return _.assign( ampAttributes, props );
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should consistently use _.extend instead of _.assign. The former is from Underscore and the latter is from lodash. Only underscore is marked as a dependency for this script. Interesting that the post edit screen loads both Underscore and lodash, with the latter doing noConflict.

isSelected = props.isSelected,
name = props.name,
el = wp.element.createElement,
InspectorControls = wp.blocks.InspectorControls,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wp.blocks.InspectorControls is deprecated and will be removed from Gutenberg in 3.1. Please use wp.editor.InspectorControls instead.


if ( attributes.ampLayout ) {
if ( 'core/image' === name ) {
component.setImageBlockLayoutAttributes( props, attributes.ampLayout, inspectorControls );
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Calling this here results in a warning:

Warning: Cannot update during an existing state transition (such as within render or another component's constructor). Render methods should be a pure function of props and state; constructor side-effects are an anti-pattern, but can be moved to componentWillMount.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should be done in some onChange callback somehow.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed within dbc1c7c.

// Exclude options from layout that are not supported.
if ( 'core/image' === blockName || 'core/video' === blockName || 'core-embed/twitter' === blockName ) {
if ( 'container' === option.value ) {
return true;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This might as well just return.

*/
component.getLayoutOptions = function getLayoutOptions( blockName ) {
var layoutOptions = [
{ value: '', label: 'None' }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably “Default” is more clear than “None”, since the latter could be confused with “No Display”.

public function override_gallery( $html, $attributes ) {
public function maybe_override_gallery( $html, $attributes ) {
if ( isset( $attributes['amp-carousel'] ) && false === filter_var( $attributes['amp-carousel'], FILTER_VALIDATE_BOOLEAN ) ) {
return $html;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't it be the case anyway here? It's just that at the moment the user would have to manually add the amp-carousel attribute to the [gallery] to achieve that with the changes here?

* @param array $amp_data Array of AMP attributes.
* @return array
*/
public function set_data_amp_attributes( $attributes, $amp_data ) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think instead of set_ this should be prefixed with filter_, since it's not actually setting any attributes on a node. That would align with filter_attributes method in the image sanitizer.

* @param string $layout Layout.
* @return array New attributes.
*/
public function set_attachment_layout_attributes( $node, $new_attributes, $layout ) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above:

I think instead of set_ this should be prefixed with filter_, since it's not actually setting any attributes on a node. That would align with filter_attributes method in the image sanitizer.

But that gets tricky here because here there are side-effects on the parent node. So it's not so clear what is the best to do.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed this to filter_ within dbc1c7c since even with setting the parent node attributes it seems to be more consistent. One option could be to separate setting the parent node attributes from the filtering method into a separate method, would that be a more clear / better alternative? Thoughts?

Copy link
Member

@westonruter westonruter left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@miina I'm seeing the editor freeze when I attempt to insert a Gallery block. Seems like an infinite loop.

Also, can the carousel toggle be added to the Gallery block in addition to the Shortcode block for a gallery? See #1121

}
}

// Return original.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this this the original or copied?

break;

case 'nodisplay':
return [
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see where this return value is ever used?

* @return mixed Modified array.
*/
public function whitelist_layout_in_wp_kses_allowed_html( $context ) {
foreach ( $context as $tag ) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this is working. At least it needs &$tag to ensure the array modifications get set into $context.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That was not working, indeed. Changed within dbc1c7c.

* @param array $context Array of contexts.
* @return mixed Modified array.
*/
public function whitelist_layout_in_wp_kses_allowed_html( $context ) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that $context should be $tags.

public function set_attachment_layout_attributes( $node, $new_attributes, $layout ) {

// If either height or width is missing, try to get these from original file.
if ( empty( $new_attributes['width'] ) || empty( $new_attributes['height'] ) ) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't the width and height discovery be delegated to the AMP_Img_Sanitizer and AMP_Video_Sanitizer respectively? The image sanitizer is already using advanced logic to fetch image dimensions. The video sanitizer could be augmented with this logic instead, as I believe it is only needed for video?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moved within dbc1c7c, missed the fetching image dimensions logic within AMP_Img_Sanitizer when creating this, thanks for noting that!

@miina
Copy link
Contributor Author

miina commented May 21, 2018

@westonruter On editor freeze with Gallery block -- just to confirm, do I understand correctly that the editor freeze is with inserting the default Gallery block and not the gallery shortcode into Shortcode block? Asking since couldn't reproduce the issue at this moment (using Gutenberg 2.9.1 on WP 4.9.6 on VVV), in theory this PR shouldn't influence the Gallery block. Does the freeze occur when clicking the block or already when inserting the block without any additional action?

el( ToggleControl, {
label: __( 'AMP loading indicator disabled' ),
checked: ampNoLoading,
onChange: function() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For some reason, the first time I check the checkbox I get a warning:

Warning: A component is changing an uncontrolled input of type checkbox to be controlled. Input elements should not switch from uncontrolled to controlled (or vice versa). Decide between using a controlled or uncontrolled input element for the lifetime of the component. More info: https://fb.me/react-controlled-components

Maybe it's a bug in Gutenberg. It doesn't seem to cause a problem.

@westonruter
Copy link
Member

I just pulled down the latest from Gutenberg and I'm not able to reproduce the editor freezing when adding a Gallery block.

…onents cannot yet be used in the React context
@westonruter westonruter merged commit a68c93f into develop May 21, 2018
@westonruter westonruter deleted the add/1008-core_blocks_amp_specific_features branch May 21, 2018 17:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants