Gutenberg: 增强功能：图像处理

创建于 2018-04-14 · 91评论 · 资料来源: WordPress/gutenberg

这是有关如何在编辑器和前端中处理图像的“小建议”（从＃4914开始跟进）。

目前：

图像将以原尺寸插入编辑器，即在大多数情况下，我们强迫用户下载2MB-5MB的文件。
当用户保存帖子而不更改检查员的图像来源时，前端访问者可能也必须下载大量文件。 WP添加了适当的srcset属性，但是sizes属性却毫无用处，因为它仅引用完整尺寸的图像文件： sizes="(max-width: 6000px) 100vw, 6000px" 。

要在编辑器中解决此问题，请执行以下操作：

始终插入“大”尺寸（1024px）的图片。如果不存在（如果上传的图像较小），请插入“完整”尺寸。
添加srcset属性，该属性还将列出2倍大尺寸的图像（因此图像可用于视网膜）。这是新的大小，必须将其添加到默认的WP大小，请参见下文。
将另一个属性添加到标记古腾堡图片，以便我们可以在PHP中轻松识别它们。这是必要的，因为我们将不得不稍微不同地计算前端srcset和size的属性。理想情况下，应该具有附件ID，例如data-wp-attachment-id="1234" 。然后，也许我们可以放弃传递ID的“旧”方式class="wp-image-1234" 。
对width =“ 123”属性的特殊处理。在HTML 5.0中，必须以像素为单位，但是由于编辑器的宽度与主题的宽度不同，因此结果通常是意外的。这主要影响当用户拖动角点或直接设置图像尺寸时调整大小的图像（请参阅＃4914）。对于这些情况，我们将需要更好的解决方案，也许在根据主题的宽度在前端显示图像时重新计算数字。

要针对前端解决此问题，请执行以下操作：

添加新的默认大小2x，最大宽度或高度为2048px。
在处理<img>标签和添加srcset等时添加一些逻辑，这些逻辑将产生可用的sizes属性。这将取决于新的data- *属性，并在计算尺寸时考虑主题的宽度。如果我们要重新计算硬编码的宽度属性（请参见上文），则可以在此处完成，并在两个属性中使用这些值。或者，我们可以在编辑器中以百分比（HTML 4.0样式）设置宽度，然后在此处将其替换为像素。

实施上述所有操作将确保在编辑器和站点上所有图像始终“视网膜就绪”。它还将改善前端的处理并优化前端的图像加载。

这也会影响其他增强功能，主要是＃4914。同样，如＃6131中所述，主题可以为不同的图像添加更精确的sizes属性。

Backwards Compatibility [Feature] Media [Status] In Progress

资料来源

azaozz

👍29 🎉3 👀1

最有用的评论

谢谢大家为此付出了很多思考和关心。我看到两个纠结的问题应分开处理以向前发展。

避免在5.0中出现明显破损（例如加载大图像）。
重新思考WordPress如何在灵活的观看体验世界中处理媒体空间。

首先，需要明确识别任何悬而未决的问题，并就“中断”的含义达成协议。特别是围绕新引入的功能，这些功能没有任何以前的期望（宽图像，封面等）。我的理解是，通过默认设置为“ large”可以解决加载太大源的主要障碍。

第二，我非常相信我们需要将整个周期投入到媒体中，因为从事情变得更简单的那一刻起，我们就一直在处理问题。现在，媒体存在于一个世界，在这个世界中，我们拥有的核心资产还远远不够，大量的设备以不同的期望，像素密度，屏幕尺寸等来访问网络。仅靠WordPress无法完全解决这一问题，需要WordPress的参与其他组，例如托管服务和带宽管理，浏览器，Web标准组等。期望在执行5.0的同时修复所有问题也是不合理的。

当我们查看WordPress默认情况下如何管理资产时，很明显它创建的变体不足以支持各种设备，查看条件和性能期望。在较大规模上，我们在常规安装中处理的是1024px或全尺寸。这还不够。 “源”和“大”之间存在巨大的鸿沟，几乎使任何尝试响应式图像或高dpi的尝试都可以带来一场失败的战斗。我们需要对媒体资产进行更好的细分，而又不会使服务器超负荷，以达到扩展和匹配质量预期的目的。

这些选项可由用户，主题和插件进行配置，这只会使情况进一步复杂化，因此，围绕“大”字样可以容纳的内容的假设不能过分。

能够在正确的环境中传递正确的图像至关重要。

理想情况下，用户根本无需干预即可使自己的作品看起来不错并且表现出色。

但是，我们目前的长期建议在技术或用户体验水平上看起来不够灵活，无法满足此要求，同时又增加了相当大的开销和复杂性：

扩展到其他非wp:image块仍未解决。
非正统的服务器实现（可能需要＃10108之类的东西）会增加复杂性。
复制图像标记_ad hoc_（服务器与客户端）的开销，与潜在的扩展和保真度客户端冲突。
围绕百分比大小的预期用户体验不确定。
主题方面的责任过多。
更重要的是，不确定性与第二阶段的条件和要求重叠。

在介绍此代码和期望（针对主题等）时，我们将创建一个复杂的需求网络，而错过了采用更全面的方法解决问题的机会。我相信随着时间的推移并结合阶段2会更好地完成此操作，因为对块所在位置和用户交互的期望将会大大提高。

主题将不再能够仅说出它们关心内容的宽度，因为块将放置在页面上的任何位置。块也可以在块区域之间移动，因此宽度应始终与上下文相关，并由直接的InnerBlocks根控制。这包括诸如主要内容区域内的列之类的内容，还包括内容本身以外的区域之类的内容。我们在此处开发的任何API都需要考虑这些期望，否则我们将创建一个遗留代码的网络，这些网络将很难有效地解开。

我看到的成为一种更健壮且面向未来的API是将媒体宽度责任附加到每个块容器，其中post_content只是其中之一。它可能看起来像这样：

innerBlocks( 'post-content', sizes: {
    default: 600,
    wide: 1000,
    full: 100vw,
}

这两者都为该根目录下的块指定了默认的最大宽度和宽度对齐的_availability_。一旦创建另一个根（如列），上下文就会更改。

这将使我们也可以：

innerBlocks( 'sidebar', sizes: {
    default: 300,
    wide: false,
    full: false
} )

等等。

这应该与固有的响应图像处理配对，更重要的是，如果有可行的话，还可以更好地分割资产创建或某种动态处理。

mtias 于 2018-11-29

❤11 👍8

所有91条评论

对编辑器执行Pinging @noisysocks和@iseulde 。我可以添加核心更改。

对于编辑器，更改（如我所见）将是：

向所有<img>标签添加data-wp-attachment-id="1234"属性。
始终插入“大”尺寸的图像。
添加具有中等，大和xlarge大小的srcset属性（我们会很快将xlarge图像大小添加到默认大小）。
在编辑器中添加适合图像宽度的sizes属性。
保存时，可能会同时删除srcset和sizes因为它们在显示时可能会有所不同。或者，我们可以在显示过滤器中覆盖它们。
为图像尺寸设置任何像素值时，请以编辑器宽度为基础。图像的宽度超出编辑器中可见的范围是没有意义的。

TODO：考虑将百分比宽度传递到前端的最佳方法是什么。

azaozz 于 2018-04-14

感谢您撰写本文，@ azaozz！很高兴为您进行必要的编辑器更改。他们对我来说听起来不错。

或者，我们可以在编辑器中以百分比（HTML 4.0样式）设置宽度，然后在此处将其替换为像素。

我的犹豫是，如果第三方（例如插件，RSS阅读器，API使用者）使用post_content而不对其进行处理，则他们将没有有效的HTML5标记。 “ Honouring HTML”是古腾堡的要求之一。

大声考虑：我们可以使用古腾堡元数据来完成其中的一些工作，例如存储附件ID和百分比宽度吗？

<!-- wp:image {"attachmentId":123,"horizontalScale":0.25} -->
<img src="https://example.com/image.jpg" width="600" height="500" />
<!-- /wp:image -->

noisysocks 于 2018-04-16

👍1

是的，图像是“动态块”（在经典编辑器中也是如此）。它们是最好的动态块，因为它们在那里具有“后备标记”，并在
前端来增强它们。

有了该后备标记，即使没有运行“显示过滤器”，图像也可以在“任何地方”工作（这实际上会使内容没有段落，因此不要以为任何插件都可以）。

我们当然可以将需要传递到前端的数据添加到blocks元，但是认为我们也需要<img>标签中的相同数据。原因之一是显示的解析块很慢，我们将获得更大的HTML块，而不是实际的img标签（带有标题的数字等）。另一个原因是（也许）并非所有图像都位于单独的块中，考虑块引用，表格单元格等中的图像。另一个原因是，如果帖子在任何其他编辑器中进行编辑，则块可能会被严重破坏，但是<img>标签将“生存”并保持完整（只要我们使用标准HTML）。

最后，可以归结为：

这更容易，更快，更简单，更具可读性/更易理解：解析该块，然后处理HTML块（可能包含多个元素），或者像我们目前一样解析<img>标签。
我们可以保证编辑器中使用的所有图像始终位于wp:image块中。其中包括粘贴的图像，表单元格中的图像，引号以及插件可能附带的任何其他块和标签组合。

恕我直言，我们应该同时使用block meta和img标签属性，然后（一天）我们可以选择在解析显示内容时使用哪个属性。

azaozz 于 2018-04-16

@azaozz这是一个深思熟虑的建议。我不完全理解为什么我们不使用现有的主题声明的图像大小。是否有关于此的事先讨论？

目前已经公开了一个百分比字段，但是我无法确定当前前端是否可以执行任何操作。 https://github.com/WordPress/gutenberg/blob/master/blocks/library/image/block.js#L266

百分比方法很不错，但它破坏了与主题API的向后兼容性。

davisshaver 于 2018-04-19

👍1

为什么我们不使用现有的主题声明的图像尺寸...

我们这样做:)在前端添加srcset属性时，我们将使用所有可用大小（具有相同的w / h比率）。然后，浏览器决定要使用哪个图像文件。

azaozz 于 2018-04-19

@azaozz我相信它的功能将与当前行为有所不同。图像尺寸还可以用于传递样式，而不仅仅是要使用的图像裁剪。我还认为现有的延迟加载插件期望src值是“正确”的大小，因此我不确定我们是否可以完全依靠srcset 。

编辑：这将是我认为的image_size_names_choose过滤器。

davisshaver 于 2018-04-20

@davisshaver在过去的一周中，我经历了几个延迟加载插件。他们中的许多人寻找现有的src和srcset属性，并使用the_content过滤器将它们简单地替换为PHP中的其他标记。这里的挑战是如何让核心首先生成正确的srcset和sizes属性以及物理图像。

mor10 于 2018-04-21

与响应图像相关的几个问题将具有重叠的解决方案。我建议我们将所有内容都整合到这个问题中，以避免进一步讨论。这是不完整的清单：

提案

正如我之前规定的那样（＃6131），我感兴趣的挑战是主题和插件开发人员如何根据各种因素控制网站前端的sizes属性，包括但不限于限于不同的布局（无论是否有侧边栏，其他因素），而不必像本例中那样为每个条件手动重写整个sizes属性。

考虑以下情形，从a到i：

从历史上看，关于显示的任何图像，我们都知道两件事：图像文件的物理宽度以及主题定义的$content_width 。然后，我们使用这两个参数来找出sizes属性。

古腾堡不仅介绍了alignwide和alignfull宽度，还介绍了制作各种元素wide或full包括但不限于列等。结果，除了响应式网页设计带来的常规挑战之外，任何一个主题内都有无数的显示宽度。

这些示例显示了_two常量_，可以由主题开发人员（和扩展插件开发人员）轻松定义：

$content_width -内容未显示为alignwide或alignfull时的最大宽度。
$max_display_area -如果内容设置为alignfull ，则可填充的最大可用空间。

我们还可以做出三分之一的假设：

设置为alignwide的元素将占用完整的$content_width加上$content_width和$max_display_area之间的可用空间的一半，可以计算为

$content_width + ( $max_display_area - $content_width ) / 2

换句话说，如果WordPress知道$content_width和$max_display_area值，则它可以准确计算内容显示的空间，并从中即时确定sizes属性是什么显示图像的显示方式取决于显示方式，包括@azaozz引入的新data-wp-percent-width 。

实际应用

主题开发人员定义了两个值：

$content_width声明任何显示条件的最大_content_宽度（如果未应用alignwide或alignfull则为内容的宽度）。
$max_display_area声明任何显示条件的最大可用宽度。

这两个值都将根据条件而变化，因此不能像今天的$content_width那样成为全局变量（除非我误解了$content_width当前的工作方式）。

对于显示的没有alignwide或alignfull ， $content_width变量（和自定义宽度数据属性，如果可用）足以确定sizes属性：显示的大小绝不会超过$content_width或数据属性所定义的$content-width某个百分比。为主题开发者设置的方法比当前方法要简单得多。

对于在alignwide或alignfull上下文中显示的图像，我们需要使用$max_display_area值。将这个变量定义为某种视口宽度和可用显示区域的数组是有意义的。可以将此数组与数据属性结合起来，转换sizes即时生成的

因此，对于上述示例，主题将声明如下内容：

// In this theme there is a fixed maximum content width of 720px.
$content_width = 720px;

if ( is_active_sidebar( 'sidebar-1' ) {
  $max_display_area = [
    'min-width: 48em' => 'calc( 100vw - 30em), // sidebar is 30em wide.
    'fallback' => '100vw',
  ];
} else {
  $max_display_area = [
    'fallback' => '100vw',
  ];
}

假设对于d，e和f，侧边栏出现的断点位于48em，对于g，h和i， data-wp-percent-width属性为50％，示例所得的sizes属性此评论的顶部如下：

/**
 * a: Image width is equal to $content_width area.
 */
sizes="(min-width: $content_width) $content_width, fallback"
sizes="(min-width: 720px) 720px, 100vw"

/**
 * b: Image width is 50% of the available space between $content_width and $max_display_area.
 */
sizes="(min-width: $content_width) calc(($max_display_area - $content_width) / 2), fallback"
sizes="(min-width: 720px) calc((100vw - 720px) / 2), 100vw"

/**
 * c: Image width is equal to fallback.
 */
sizes="fallback"
sizes="100vw"

/**
 * d: Image widths is equal to $content_width area.
 */
sizes="(min-width: $content_width) $content_width, fallback"
sizes="(min-width: 720px) 720px, 100vw"

/**
 *e: Image width is $content_width plus 50% of the available space between $content_width and $max_display_area.
 */
sizes="(min-width: $content_width) calc(($max_display_area - $content_width) / 2), fallback"
sizes="(min-width: 720px) calc((100vw - 30em) - 720px) / 2, 100vw"

/**
 * f: Image width is equal to $max_display_area.
 */
sizes="$max_display_area, fallback"
sizes="(min-width: 48em) calc(100vw - 30em), 100vw"

/**
 * g: Image width is 50% of $content_width. 
 */
sizes="(min-width: $content_width) calc($max_display_area * (data-wp-percent-width / 100)), calc(fallback * (data-image-width / 100))"
sizes="(min-width: 720px) calc(720px * .5), calc(100vw * .5)"

/**
 * h: Image width is 50% of $content_width plus 50% of the available space between $content_width and $max_display_area.
 */ 
sizes="(min-width: $content_width) calc((($max_display_area - $content_width) / 2) * (data-wp-percent-width / 100)), calc( fallback * (data-image-width / 100))"
sizes="(min-width: 720px) calc(((100vw - 720px) / 2) * .5), calc(100vw * .5)"

/**
 * i: Image width is equal to 50% of fallback.
 */
sizes="calc(fallback * (data-wp-percent-width / 100))"
sizes="calc(100vw * .5)"

mor10 于 2018-06-25

❤4 🎉2 👍2

谢谢@ mor10 ，非常好:)

是的，要在前端正确处理和显示图像，我们需要一些数据：编辑器提供的有关如何正确使用图像的上下文，以及主题提供的有关如何显示图像的数据。

我有几个小建议/说明。

$content_width -内容未显示为alignwide或alignfull时的最大宽度。
$max_display_area -如果将内容设置为alignfull，则可填充的最大可用空间。

我（仍然）认为我们应该让主题（能够）指定所有三个宽度：内容/主列，宽和满。这样，我们就不会在主题上强加任何内容。有些人可能想要更宽或更窄的alignwide图像。如果主题已过时，使用content_width和full的一半差异作为wide可能是一个后备方法，也许吗？

所以这些应该是这样的：

$content_width
$alignwide_width
alignfull_width

（从技术上讲，它们也可以位于关联数组中，因此我们不会过多地“抛弃”全局空间。拥有该数组也将表明主题对此表示支持。）

另一个重要的区别是，我们期望这些新宽度是“上下文的”。也就是说，它们应该在当前模板开始输出HTML之前由当前模板进行设置（并可能在最后进行重置）。这对于为所有图像生成更精确的sizes属性至关重要。

古腾堡不仅介绍了alignwide和alignfull宽度，还介绍了制作各种元素wide或full 。

不要以为我们需要关注re：图片。如果将块设置为full ，则在其中没有alignfull图像是没有意义的。它将与“正常”图像完全相同。对于wide块也是如此。

azaozz 于 2018-06-26

指定所有三个宽度是有意义的，并且关联数组的确可以使它更整洁。唯一的问题是如何根据条件进行修改...我想主题开发人员只会修改数组？

不要以为我们需要关注re：图片。如果将块设置为full ，则在其中没有alignfull图像是没有意义的。它将与“正常”图像完全相同。相同于wide块。

如果您查看我评论中的示例，您将看到我们必须考虑这些。如果某人的屏幕非常大，并且将一个图块设置为alignfull并且其中包含50％的图像，则该图像可能比内容宽度大很多。 sizes属性必须描述图像的实际显示宽度，并且放置在alignwide或alignfull上下文中的任何内容都将具有不同的宽度。

mor10 于 2018-06-26

您好@ mor10在您的示例中，“ b”的大小不应为：

size =“（最小宽度：$ content_width）calc（$ content_width +（$ max_display_area-$ content_width）/ 2），后备广告”

？

alialaa 于 2018-07-20

@alialaa数学可能很

mor10 于 2018-07-23

@azaozz我们在哪里？我只是用官方的Gutenberg Starter Theme测试了Gutenberg 3.3，据我所知，当前的块都使用全部图像大小。激活插件后，这会严重影响性能。

mor10 于 2018-07-23

👍2

@ mor10我正在尝试实现与您提供的代码（ wp_calculate_image_sizes过滤器）非常相似的东西，只是我试图为具有更大布局变化的更大主题实现此目标。到目前为止，最大的问题是为图像可能出现在主题中的每个位置实现sizes属性的强大生成器。最大的问题是：

流体与固定宽度的布局
网格系统（以容器百分比表示）
网格间隙
侧边栏是否存在
多个媒体查询断点

我已经设法实现的是一些PHP逻辑，该逻辑接受一组参数并输出带有宽度描述符和媒体查询的大小数组。我的目标是涵盖最常见的引导程序布局，它们的使用范围非常广泛

对于上下文，这里是用来产生这些数字的断点（略有修改媒体查询）。

事物的有效参数是：

bootstrap_class ：可能很长，接受bootstrap接受的内容，它实际上被解析并用于生成多个媒体查询
gutters ：是| 假。是否将30px装订线放入计算中。该数量是可配置的
fluid ：是| 假。非流体布局最困难，它们的像素max-width

以下是一些通过JSON格式的实际通过的测试用例（每个条目都是一个测试用例，第一个对象是我的逻辑的输入，第二个对象是输出）：

[
    [

        {"bootstrap_class": "col-md-12", "gutters": true, "fluid": true},
        [{"media_query": false, "image_size": "calc(100vw - 30px)"}]
    ],

    [
        {"bootstrap_class": "col-sm-12", "gutters": true, "fluid": true},
        [{"media_query": false, "image_size": "calc(100vw - 30px)"}]
    ],

    [
        {"bootstrap_class": "col-xs-6", "gutters": true, "fluid": true},
        [{"media_query": false, "image_size": "calc(50vw - 30px)"}]
    ],
    [
        {"bootstrap_class": "col-xs-8", "gutters": true, "fluid": true},
        [{"media_query": false, "image_size": "calc(66.6667vw - 30px)"}]
    ],
    [
        {"bootstrap_class": "col-xs-5", "gutters": true, "fluid": true},
        [{"media_query": false, "image_size": "calc(41.6667vw - 30px)"}]
    ],
    [
        {"bootstrap_class": "col-xs-9", "gutters": true, "fluid": true},
        [{"media_query": false, "image_size": "calc(75vw - 30px)"}]
    ],
    [
        {
            "bootstrap_class": "col-xs-10 col-sm-3 col-md-7 col-lg-11 col-xl-5",
            "gutters": true,
            "fluid": true
        },
        [
            {"media_query": "1300px", "image_size": "calc(41.6667vw - 30px)"},
            {"media_query": "1000px", "image_size": "calc(91.6667vw - 30px)"},
            {"media_query": "690px", "image_size": "calc(58.3333vw - 30px)"},
            {"media_query": "480px", "image_size": "calc(25vw - 30px)"},
            {"media_query": false, "image_size": "calc(83.3333vw - 30px)"}
        ]
    ]
]

获得输出后，可以轻松地将其组装为适当的sizes属性，准备将其插入HTML中。

例如，这是非常复杂的col-xs-10 col-sm-3 col-md-7 col-lg-11 col-xl-5图像的输出应为：

[
    {
        "bootstrap_class": "col-xs-10 col-sm-3 col-md-7 col-lg-11 col-xl-5",
        "gutters": true,
        "fluid": true
    },

    [
        {"media_query": "1300px", "image_size": "calc(41.6667vw - 30px)"},
        {"media_query": "1000px", "image_size": "calc(91.6667vw - 30px)"},
        {"media_query": "690px", "image_size": "calc(58.3333vw - 30px)"},
        {"media_query": "480px", "image_size": "calc(25vw - 30px)"},
        {"media_query": false, "image_size": "calc(83.3333vw - 30px)"}
    ]
],

在最终组装的HTML中看起来像这样：

<div class="container-fluid">
  <div class="row">
    <div class="col-xs-10 col-sm-3 col-md-7 col-lg-11 col-xl-5">

      <img
        srcset="..."
        sizes="
          (min-width: 1300px) calc(41.6667vw - 30px),
          (min-width: 1000px) calc(91.6667vw - 30px),
          (min-width: 690px) calc(58.3333vw - 30px),
          (min-width: 480px) calc(25vw - 30px),
          calc(83.3333vw - 30px),
        "
      >

    </div>
  </div>
</div>

现在，非流畅布局的测试用例变得更加复杂并且难以遵循。

另外，有时bootstrap_class是不够的，我们需要能够以原始百分比表示图像宽度。

如果有兴趣，我可以在其他地方就此事进行更详细的聊天，我真的很感兴趣将其正确地推进，但仍然存在很多问题🙂

andreiglingeanu 于 2018-08-02

👍3

8593已将`srcset`和`sizes`属性添加到单个图库图像，但是`sizes`属性仍然充当每个图像占用视图的全部内容宽度的角色，这很少案件。

相关：＃1450

mor10 于 2018-08-08

👍1

我们在哪里呢？

看着它的atm，已经有一段时间了。希望几天后将有一个更新的“可行”分支。

azaozz 于 2018-08-09

🎉2

更新了图像块分支： https :

@joemcgill @getsource @ mor10考虑明天做公关，对该分支机构的评论表示赞赏：）

azaozz 于 2018-10-16

再次更新分支。几乎准备就绪，只需要更多测试即可：)

azaozz 于 2018-10-19

将其添加到WP 5.0里程碑中是因为非常重要的一点是，我们不要在插入到帖子内容中的图像中引入性能下降，并且我不想忘记在此处查看更新。

joemcgill 于 2018-10-25

🎉1

我们应该记住，这些性能问题不仅与通过HTML标签集成的图像（图像和图库块）有关，还与封面图像块有关，在封面图像块中，图像通过css作为背景图像插入。

通过srcset的解决方案不适用于此模块。

derweili 于 2018-10-26

现在，有29个针对此问题提供了具体的测试平台。有关更多详细信息，请参见https://github.com/WordPress/twentynineteen/issues/50#issuecomment -434120505。

mor10 于 2018-10-30

@azaozz使用二十十九运行引用的分支，我插入的图像得到以下标记：

<img 
  src="http://gutenberg.local:8888/wp-content/uploads/2011/07/michelle_049-1024x768.jpg" 
  alt="Big Sur" 
  width="640" 
  height="480" 
  srcset="http://gutenberg.local:8888/wp-content/uploads/2011/07/michelle_049-1024x768.jpg 1024w, http://gutenberg.local:8888/wp-content/uploads/2011/07/michelle_049-300x225.jpg 300w, http://gutenberg.local:8888/wp-content/uploads/2011/07/michelle_049-768x576.jpg 768w, http://gutenberg.local:8888/wp-content/uploads/2011/07/michelle_049.jpg 1600w" 
  sizes="(max-width: 640px) 100vw, 640px">

看起来最大宽度设置为与主题中的content_width全局设置匹配。

我应该在主题中添加什么新标记（如果有）以测试新功能？

mor10 于 2018-10-30

@ mor10对，它正在使用$content_width PHP全局。这是新引入的$block_width全局的后备，它应该包含三个值：default，wide和full，请参见： https : $content_width ）。

要进行测试，也许遵循图像块中来自phpdoc的示例：

/**
 * Get the expected block width from the global $block_width array.
 *
 * The global $block_width array is expectd to be set by the theme for each block container.
 * It should contain three values: default, wide and full, in pixels.
 * - The `default` value should be the expected block width (similarly to $content_width).
 * - The `wide` value is optional and is used when the block alignment is set to `wide`.
 * - Similarly the `full` value is optional and used then the alignment is set to `full`.
 * If `wide` and `full` are not set, the `default` value is used instead.
 *
 * Example:
 *     $GLOBALS['block_width'] = array(
 *         'default' => 640,
 *         'wide'    => 800,
 *         'full'    => 1024,
 *     );
 *
 * In addition the $block_width array should be set contextually for each block container.
 * For example: in the main content column the `default` width will be something like 640(px),
 * but for a sidebar it would be something like 250.

如果您想设置更精确的sizes属性，最好的方法仍然是使用https://developer.wordpress.org/reference/hooks/wp_calculate_image_sizes/过滤器。看起来为主题添加了一些“更轻松”的方法，但是设置适当的sizes高度取决于上下文，并且很大程度上取决于样式（列，断点，边距，填充等）。那里没有“简便方法”，最好是完全控制主题（即使用过滤器）。

azaozz 于 2018-10-30

为什么这个值以像素为单位？许多（可能是大多数）主题不会将像素值用于宽度。二十九只是一个例子。应该可以使用任何宽度值定义宽度。例如，在大多数情况下，全角图片将为100vw 。

mor10 于 2018-10-30

还有为什么将它设置为全局，而不是add_theme_support选项或通过过滤器？

即使将此分支标记为WIP或带有“进行中”标签，将其作为PR打开也会很有帮助。使查看代码，讨论代码等更加容易。

chrisvanpatten 于 2018-10-30

👍1

为什么这个值以像素为单位

因为图像（文件）的大小以像素为单位，并且因为我们需要设置<img>标签的width和height属性（最佳做法）。默认情况下，在sizes属性中使用100vw的值，但是即使对于“对齐完整”图像块，主题也应通过可接受的最大宽度。

只要网站在2560像素的屏幕上看起来不错，可能会有一些主题会决定网站访问者应下载3-4MB的图像。其他人将更加务实，并将其限制为更“理智”的价值。

顺便说一句，为了使其正常工作，我们需要为所有上传的图像默认生成另一个更大的尺寸。

azaozz 于 2018-10-30

为什么将它设置为全局，而不是add_theme_support选项或通过过滤器

该全局的想法是“上下文的”，即对于不同的“模板”具有不同的值。有几种方法可以做到这一点，但是使用PHP全局或触发WP操作似乎最容易使用。

azaozz 于 2018-10-30

@azaozz参见https://github.com/WordPress/twentynineteen/pull/411。我们讨论了一种方法，该方法可从前一段时间的wp_calculate_image_sizes检测当前图像是否显示为常规图像， alignwide或alignfull 。我相信一个想法是在<img>元素内添加一个data属性。没有这些上下文信息，我看不到如何为三个布局选项提供正确的sizes属性。欢迎提出想法。

mor10 于 2018-10-30

没有这些背景信息...

对。此信息在$block_attributes数组中。它正在传递给（新的） render_block_core_image_tag_attributes过滤器（可能需要一个更好的名称...）。一旦将其合并到Gutenberg和core中，我认为我们将能够将block属性传递给wp_calculate_image_srcset和wp_calculate_image_sizes过滤器。

azaozz 于 2018-10-30

👍1

你在哪我现在可以测试吗？

mor10 于 2018-10-30

尚未，因为它修改了核心文件。可以将其添加为“ hack” :)

调用wp_calculate_image_srcset()和wp_calculate_image_sizes()时需要传递$block_attributes wp_calculate_image_sizes() ，请参阅https://github.com/WordPress/gutenberg/blob/update/image-block/packages/block-库/src/image/index.php#L210和https://github.com/WordPress/gutenberg/blob/update/image-block/packages/block-library/src/image/index.php#L213。然后将其传递给/wp-includes/media.php中这些函数中的过滤器。

感谢测试！

azaozz 于 2018-10-30

我可以堆砌一些核心票证以使它步入正轨吗？除非已解决，否则GB和“二十一十九”无法发布。

mor10 于 2018-10-30

❤1

@azaozz我昨天有机会对分支机构进行了一些测试（对不起，抱歉）。我想做更多事情，但想留下以下反馈：

首先，我再次重申，我强烈反对将srcset和sizes属性保存到数据库中的图像标记的想法。数据库中的标记应该是不变的，并应尽可能地用于将来。从纯内容的角度来看，应该保留带有单个src的基本img标签，而srcset和sizes是一个实现细节，最好在前端。每当为附件生成其他图像尺寸时（在切换主题或向现有主题添加新图像尺寸等之后）， srcset属性可以并且应该更改。

古腾堡已经通过前端过滤器以支持我们当前响应图像解决方案的方式格式化图像标记，所以我认为重点应该是改进可用于主题的过滤器，以基于包含以下内容的块的属性来修改sizes属性图像（例如，对齐方式，图库列等）。

补充说明：

我注意到，在编辑器中，Chrome现在正在下载每个图像的两个版本（这在master分支上不会发生）。第二个是由于在componentDidMount期间调用了fetchImageSize()图像组件的src属性的切换。这抵消了将srcset和sizes到组件所带来的任何好处。

在全角图片上，最大宽度上限为1024px，这会破坏预览。这在master中不会发生。

我将继续测试并添加注释，但同时回显@chrisvanpatten ，将其作为PR进行回顾将很有帮助。谢谢！

joemcgill 于 2018-10-31

👍1

@joemcgill感谢您的测试！ :)

我再次重申，我强烈反对将srcset和size属性保存到数据库中的图像标记的想法...每当为附件生成其他图像大小时（切换主题或添加新图像后），srcset属性都可以并且应该更改大小以适应现有主题等）。

这是我们几年前实现srcset和sizes时所看到的。从理论上讲，这听起来有些可能，但是在实践中，这种情况很少发生，以至于应该由插件来处理。当内容从一个WP网站导出并随附件ID更改（但URL不变）而导入到另一个WP网站时，它还会中断srcset和sizes 。

但是，在这种情况下， srcset和sizes属性纯粹是出于编辑的缘故。它们总是在前端重新生成，请参阅https://github.com/WordPress/gutenberg/blob/update/image-block/packages/block-library/src/image/index.php#L244。

仍然认为我们应该为WP 5.1+打开一张核心票证，以研究重用srcset属性，因为它可以修复导入的内容。默认的sizes属性与主题无关，但认为应始终在前端对其进行重新生成和过滤。

古腾堡已经通过前端过滤器以支持我们当前响应式图像解决方案的方式格式化图像标记

不完全是：)目前，古腾堡（Gutenberg）在编辑器和前端都“强制”全尺寸图像。确实，已将srcset属性添加到<img>标签中，但是请看那里的默认sizes属性。这很“闷” ：)

我认为重点应该是改进可用于主题的过滤器，以修改size属性...

完全同意。这会添加一些新的过滤器，以帮助解决问题，但最重要的是，我们应该将block_attributes传递给wp_calculate_image_sizes过滤器（也要传递给wp_calculate_image_srcset进行匹配）。

此外，在最后一次更新之后，在这些块属性中传递了很多与编辑器相关的数据。这样就可以在前端适当缩放图像，重置width和height （并确保它们始终存在，这是最佳实践），并且通常为主题提供更多选择渲染图像块时。

我注意到，在编辑器中，Chrome现在正在为每个图像下载两个版本

这仅适用于新上传的图像。由于图片在上传时被添加为“预览”，因此我们需要更改src ，以在出现附件后将其指向“大”尺寸。另外，在编辑器中使用srcset的好处是加载并显示“视网膜”图像。在页面完成加载后很长时间加载编辑器内容（HTML），因此没有速度优势。

在全角图片上，最大宽度上限为1024px，这会破坏预览。这在master中不会发生。

对。这里的替代方法是始终下载2-4MB或更大的图像。即使仅在编辑器中，这也是无法接受的。要解决此限制，我们需要默认生成另一个图像子尺寸，该尺寸要比“大”大。在Slack中对此进行了多次讨论，并且有一张非常“老”的核心票据。我们绝对应该考虑尽快这样做。

我将继续测试并添加注释

是的，请！ :)
考虑到今晚进行公关，似乎处理图像的大多数情况都考虑在内。

azaozz 于 2018-11-01

但是，在这种情况下，srcset和sizes属性纯粹是出于编辑的缘故。

如果真是这样，那么将这些属性保存到数据库中已保存的标记中绝对是没有意义的。

不完全是：)目前，古腾堡（Gutenberg）在编辑器和前端都“强制”全尺寸图像。确实将srcset属性添加到了标签，但请查看此处的默认尺寸属性。这很“闷” ：)

好的，这是有用的区别，因为我们不再将图像大小限制为content_width ，因此图像的width属性被错误地保存。

这仅适用于新上传的图像。

我不相信这是真的。我可以保存帖子，刷新编辑器，然后仍然看到双重下载。

对。这里的替代方法是始终下载2-4MB或更大的图像。即使仅在编辑器中，这也是无法接受的。

抱歉，我在这里不清楚。我看到的是在CSS中，图像宽度受编辑器中包装的div的内联样式的限制。以下是一些屏幕快照可以帮助您：

编辑器中的完整尺寸图片未覆盖完整宽度– https://cloudup.com/cHob4kcjLrN

在检查器中标记以上内容– https://cloudup.com/cIVWetqpSoF

joemcgill 于 2018-11-01

该票证的范围非常大，但是对于WP 5.0来说，有几点至关重要。我们能否分解一下回归的特定问题？如我所见，这包括：

[]避免将完整尺寸的图像加载到前端。
[]在帖子内容中保存一个更合适的width到img元素（最佳做法，但与计算响应图像的默认sizes属性有关）。

高优先级，增强功能：

[]提供一种根据图像对齐方式在前端过滤sizes的方法（＃6131）。
[x]禁止在编辑器中加载完整尺寸的图像。

增强功能（不错）：

[]提高编辑器中的图像加载性能（例如，通过响应图像）
[]改进了编辑器和前端之间手动调整大小的图像宽度的处理。
[]将生成的图像大小增加2倍（我们需要在此处评估对图像生成的影响。这与https://core.trac.wordpress.org/ticket/37840有关，被https：//阻止） core.trac.wordpress.org/ticket/40439）

我有什么想念的吗？

joemcgill 于 2018-11-01

👍5 ❤1

在“二十十九”回购中提供了一个示例，说明为什么这对主题和古腾堡总体来说是一种阻碍。古腾堡（Gutenberg）当前引起的性能影响是重大的： https :

mor10 于 2018-11-08

👍3

根据我的测试，响应图像在5.0 RC1中仍然无法解析。 wp_calculate_image_sizes没有块属性属性，并且来自＃11973的render_block_core_image_tag_attributes没有被合并。

不要对它说得太清楚，但这意味着所有未在编辑器中手动调整大小并在RC1中对齐的alignnone ， alignwide和alignfull的图像都被破坏了，因为它们sizes属性不正确。

要测试，请激活二十十九，将大图像（1200像素或更宽）上传到帖子中，将其对齐none ， alignwide或alignfull ，然后检查输出sizes属性。您会发现，无论显示的宽度还是图像的固有宽度，该值为：

sizes="(max-width: 1024px) 100vw, 1024px"

这意味着，在任何情况下，如果图像显示的宽度大于1024px（几乎所有使用笔记本电脑/台式机显示器的实例），浏览器都会加载1024px宽的源图像并将其拉伸，从而导致模糊。

合并的计划是什么。我该怎么办？

mor10 于 2018-11-23

👍4

有关：

核心票证45406：为srcset添加其他默认图像大小以适应更大的视口
核心工单45407：将块属性添加到wp_calculate_image_sizes以允许正确处理sizes属性

mor10 于 2018-11-24

已请求进行测试以显示当前行为和更正的行为，因此我同时构建了它们：

下面链接的两个帖子分别显示了核心版本和更正版本的当前输出。请注意有关如何测试的详细说明。响应式图像是浏览器的核心功能，浏览器非常努力地使该功能不可见。强制可见性要求您在测试中花费大量精力。

请特别注意以下几点：响应图像受显示密度的影响。 可以使用浏览器开发工具中的移动预览来完成。

演示1：由核心https://gutenberg.mor10.com/image-test-current/提供的自动生成的尺寸
演示2：具有正确尺寸属性的相同内容https://gutenberg.mor10.com/response-images-demo-corrected-code/

mor10 于 2018-11-29

👍1

谢谢大家为此付出了很多思考和关心。我看到两个纠结的问题应分开处理以向前发展。

避免在5.0中出现明显破损（例如加载大图像）。
重新思考WordPress如何在灵活的观看体验世界中处理媒体空间。

这些选项可由用户，主题和插件进行配置，这只会使情况进一步复杂化，因此，围绕“大”字样可以容纳的内容的假设不能过分。

能够在正确的环境中传递正确的图像至关重要。

理想情况下，用户根本无需干预即可使自己的作品看起来不错并且表现出色。

但是，我们目前的长期建议在技术或用户体验水平上看起来不够灵活，无法满足此要求，同时又增加了相当大的开销和复杂性：

扩展到其他非wp:image块仍未解决。
非正统的服务器实现（可能需要＃10108之类的东西）会增加复杂性。
复制图像标记_ad hoc_（服务器与客户端）的开销，与潜在的扩展和保真度客户端冲突。
围绕百分比大小的预期用户体验不确定。
主题方面的责任过多。
更重要的是，不确定性与第二阶段的条件和要求重叠。

我看到的成为一种更健壮且面向未来的API是将媒体宽度责任附加到每个块容器，其中post_content只是其中之一。它可能看起来像这样：

innerBlocks( 'post-content', sizes: {
    default: 600,
    wide: 1000,
    full: 100vw,
}

这两者都为该根目录下的块指定了默认的最大宽度和宽度对齐的_availability_。一旦创建另一个根（如列），上下文就会更改。

这将使我们也可以：

innerBlocks( 'sidebar', sizes: {
    default: 300,
    wide: false,
    full: false
} )

等等。

这应该与固有的响应图像处理配对，更重要的是，如果有可行的话，还可以更好地分割资产创建或某种动态处理。

mtias 于 2018-11-29

❤11 👍8

谢谢@mtias ，

我完全同意避免在5.0中出现破损，并且需要更深入地关注WordPress中的媒体以解决这些问题。

关于前者，我不确定我们是否已经完全解决了我在https://github.com/WordPress/gutenberg/issues/6177#issuecomment -435091640中概述的必要问题，特别是：

在帖子内容中保存一个更合适的width到img元素（最佳实践，但与计算响应图像的默认sizes属性有关）。

如果我们可以确认已经解决了该问题，那么我将对5.0.x版本及更高版本中处理的所有其他内容感到满意。

在后者上，重新处理媒体一直是我的希望，这也是我们在WCEU 2017刚举行的社区峰会上刚开始就这些高层问题进行初步讨论的原因之一。我期待在WP 5.0发布周期结束后恢复对话。

joemcgill 于 2018-11-29

👍4

完全同意上述@joemcgill ^

我很乐意在您正在谈论的高级工作中共同努力，这是我们一直在谈论并且想要进行一段时间的工作。

getsource 于 2018-11-29

👍1

请相信我。我认为我们（WordPress）不仅可以自己解决问题，而且可以为媒体处理创建新模型，从而对整个网络有所帮助。我们可以吸引浏览器，主机，CDN和标准机构的参与，并使用WP作为新最佳实践的分发渠道。

我们在这里遇到的是RICG响应式图像规范的绝对硬性规定。现在，我们有一个测试案例，用于确定什么有效和什么无效。这使我们处于独特的位置，可以推动工作向前发展。

mor10 于 2018-11-29

@joemcgill您能否澄清一下：

为帖子内容中的img元素保存更合适的宽度（最佳做法，但与计算响应图像的默认大小属性有关）。

是什么使“更合适的”宽度？只是想了解特定项目的参数，因为我不确定现在是否要这样做:)

chrisvanpatten 于 2018-11-29

对于固有大小/垃圾问题，这现在是相关的：

https://www.chromestatus.com/feature/4704436815396864
https://codepen.io/eeeps/pen/qLKwEZ

mor10 于 2019-01-09

令人失望的线程阅读；因为我看不到任何进展。目前的解决方案是按照所需的大小预先上传图像，然后将其放大一倍，或者忽略视网膜-是否有任何进展可以使它进入wordpress？目前，我不想让客户拥有30 mb的页面，因为他们无法有效地调整大小，并且我无法强迫图像与设计和性能相关联

yratof 于 2019-01-22

👍1

@yratof是的，同意这里的进度比预期的要慢。但是，在这里（在古腾堡仓库中）和Slack进行了大量讨论之后，我们认为没有必要添加“某种程度上”改进一件事或另一件事的边际修正。范围已多次缩小。

最好的方法是认真研究WP如何处理媒体，尤其是图像，并修复和改善所有潜在的问题。请参阅上方的Matias评论。如果您（或其他任何人）希望参与该工作，那么我希望WP 5.1准备就绪/发布后，我们可以“正式”启动它。在此之前，请考虑一下您想要得到的固定/改进，以及WP中的图像应如何“起作用”，最好使用一些代码示例：）

azaozz 于 2019-01-22

只是说我有多喜欢这个。...目前，我的博客在首页上为350mb .....

hutber 于 2019-02-21

😄3 👀1

这是否是适当的线程，以询问是否可以在Gutenberg Gallery Block中添加图像尺寸选择器，以便可以将图像按比例缩小到中等尺寸图像，而不是按比例缩小到全尺寸图像？

MarkRH 于 2019-02-23

今天，我发现自己正在这样做：

// onDomReady
document.querySelectorAll('.wp-block-gallery.columns-2 figure img')
  .forEach(x => {
    x.setAttribute('sizes', '(max-width: 781px) 50vw, 344px');
  });

...可以用$content_width和.columns-N来参数化。并推出一个插件。我希望它不会到此为止:) ...而且我会记得一旦它进入核心就禁用它。

编辑：我猜JavaScript代码曾经工作一次。您必须在PHP级别的某个位置（最好是在Gutenberg标记和the_content过滤器之间）注入sizes属性。啊。

EDIT2：所以我用DOMDocument＆Xpath实现了PHP解决方案。似乎可以正常工作，我将在生产中使用它。显然很容易出错，不推荐。

bikubi 于 2019-03-13

👍1

只是说我有多喜欢这个。...目前，我的博客在首页上为350mb .....

作为一种临时措施，我会手动将您的图片缩放到更小的尺寸，将其压缩，然后将您的博客限制为4个帖子或类似内容。因为当别人查看您的博客时，您将杀死他们的数据

yratof 于 2019-03-13

仅供参考intrinsicsize现在是一件事情： https :

mor10 于 2019-03-22

/ update / image-block是“进行中的工作” ：）请进行测试。

始终插入large图片大小，如果不存在大图片，则始终插入full 。

怎么样：总是从get_intermediate_image_sizes（）;中插入所有图像尺寸选项；？
防止访问某些图像尺寸的附加值是什么？

添加一个过滤器以启用某些图像尺寸，或启用键入要使用的自定义图像尺寸。
现在，我的选择是“缩略图，中型，全尺寸”，这是交付给30％的互联网网站（wordpress）的生产功能的荒谬选择。

用户都加载了5mb图片大小而不是500ko。

我什至不确定是否可以过滤块以添加lazysizes？

rsepierre 于 2019-05-16

你好
我不是Wordpress专家，但我认为：
“至少手头有一个简单的画廊功能”。

好...
尺寸下拉菜单（要在页面上显示'small'='thumbnails'图片并链接到较大图像（“ large”）时，是否存在设定时间？
我的意思是，我说的是5.2.2，现在是2019年6月。
除了付费插件，还有哪些替代方案？

我真的很讨厌禁用古腾堡。我尝试的第四个站点，第一个与古腾堡一起举办的站点（到现在为止，但时间不长，它已经消失了，列将是ACF）。我不知道，这是我相对较不熟悉WP（至少是更深入的了解），这并没有使任何人高兴。

ararename 于 2019-06-19

好的，对我来说https://github.com/klihelp/Kli-Gutenberg-Gallery可以正常工作。感谢那！！

ararename 于 2019-06-19

👍2

在gutenberg @ararename之后，不需要添加插件来处理图像:(

yratof 于 2019-06-20

好吧，那为什么这个线程在这里？
这是关于画廊的设置，而不是图像。

ararename 于 2019-06-20

👍1

在gutenberg @ararename之后，不需要添加插件来处理图像:(

是的，但是图像块，图库块，媒体文本块在处理图像大小方面都是不好的。我不知道他们是如何生产的。从零开始完全重建世界上最常用的CMS的最常用功能时，如何在2017-2019年不考虑图像大小的情况下？当经典编辑器准备好处理每种图像大小时，它就可以了。

太棒了我不得不为制作自己的响应式图像/图库/媒体文本块而感到沮丧，而又无法从任何本地wordpress块中受益，以免将来的更新，或者坚持失败，希望古腾堡在客户下载4k图像时会更好在其移动设备上显示或在其4k显示器上显示500px图像

rsepierre 于 2019-06-20

👍5 👀2

那就是我发现它时的想法：为什么这种状态的东西会变成成千上万分发的“生产”版本？
结果是：古腾堡被成千上万的人残废，这是及时完成事情的最后机会（嗯，不是及时）。
如果我没有发现插件'Kli-Gutenberg-Gallery-master'有用且无法正常工作，则我不得不花几天的时间来寻找内核应该提供但不能提供的东西。
这是alpha状态，而不是生产状态。

ararename 于 2019-06-20

👍3

大家好！ 👋

在这方面是否有进展？谈话是否已离开这张票？

如果可以，我希望可以继续前进并参与进来。 😄

keithdevon 于 2019-09-11

👍1

嗨，基思，下周某个时候，我也许可以就此与您联系。信不信由你，我无法接触到wordpress安装的后端，我遇到了麻烦，而且我没有时间从备份中安装完整的本地版本。

从我记得同时使用“最简单的画廊”和“ fancybox-for-wordpress”插件的情况出发，并将相关图像的图像宽度（拇指，我在functions.php中创建了自定义图像大小）设置为100 ％宽度和自动高度（这会覆盖内联html的width / height属性（如果有的话））可以满足我的需求。让我知道这是否对您有所帮助。不过要等到至少星期二。

ararename 于 2019-09-12

任何进展？

andrewio 于 2019-10-15

正在处理吗？或在其他地方追踪？

danielkusper 于 2019-12-03

@mtias @ azaozz-是时候开始向每个使用图像的块添加图像大小选择器了吗？ 5.0或5.1尚未完全解决图像大小，并且图像块已经具有选择器。

也许Cover Block可以在下一个选择器（＃19223）？

我们为杜兰大学的教职员工建立了一个多站点。封面的全尺寸图像是我们最大的资源浪费。

bbertucc 于 2019-12-18

是否有任何更新？
我想将图库图像作为缩略图提供。默认图库块使用完整尺寸的图像，并使用CSS对其进行缩放。

ShareTextures 于 2019-12-27

@ararename>好的，对我来说https://github.com/klihelp/Kli-Gutenberg-Gallery起作用。感谢那！！

您能解释一下如何使用它吗？它如何为您工作？您是否使用其他画廊插件短代码更改了所有旧的发布画廊？或插件本身自动执行？

我实际上安装了插件，但没有管理它

ShareTextures 于 2019-12-27

@ShareTextures
这是一个新安装，我不记得安装插件时保持订单是否重要，但这是我安装的：

适用于WordPress的FancyBox，版本3.2.2，来自Colorlib
Klip-Gutenberg Gallery，版本1.0.0，来自Klipolis
最简单的图库，版本4.4

将图片上传到图库后，它就可以正常工作了。实际上，我已经忘记了Klip-Gutenberg Gallery使用的任何短代码，而我使用_any_却不是。

主题关闭后，我几乎忘了，但是我准备好了这段文字：
我不是这样的话题，但是我说要发布我的“解决方案”，以解决由古腾堡画廊提供的图片库（也就是说，对于前端，后端具有完整的尺寸，但是这并不重要，因为我可以肯定地知道编辑器确实有足够的带宽，并且没有以使我超出必要的调查数量的方式来支付工作-无论如何，我认为Wordpress 5可以像5.0发行时那样工作一段时间。

首先，如果我没记错，从5.1。*升级到5.2。*后，“图库元素中的缩略图图像”问题就消失了。

对于一个工作画廊，我必须安装

克利普-古登堡美术馆
最简单的画廊
WordPress的FancyBox

我不会去测试哪一个丢失了什么地方出了什么问题，感觉还是像在猜测，但是这些丢失的任何东西都坏了。

在我必须做的某事上
.fancyboxforwp img {width：100％！important; 高度：自动！important;}

而且我不得不在注释中加上以下行（$（“。fancybox”）。fancybox初始化的部分）133至157（大约），以使浏览器中没有Js错误。

_是的，听起来很疯狂。
但是我检查了它仍然可以工作（fe，而不是后端，如前所述）。
希望你能以某种方式成功，欢呼
坦率

ararename 于 2019-12-27

还有一个想法：
我已经在我的functions.php中设置了：
add_image_size（'thumbnail'，152，152，true）;
因此，我明确地为缩略图设置了大小，也许这也会影响整体效果。
而且我已经使用Regenerate thumbnails Plugin很多次了，也许这也会影响整体效果。只是疯狂地猜测并检查连接的东西...

ararename 于 2019-12-27

@ararename感谢您的快速回复。我的网站已经有500多个帖子。所以它对我不起作用:(
我将等到Wordpress Gutenberg的下一次更新。

ShareTextures 于 2019-12-27

@azaozz是否有任何更新？我只想知道如何使用图库中图像的缩略图链接而不是完整图像。

ShareTextures 于 2020-01-03

👍2

这是什么状态，尤其是在古腾堡的“响应式保护块”上。这些让我感到有点头痛。

changeling 于 2020-01-07

响应式封面图片

为了为响应式封面图像提供一条路径，我一直在尝试了解CSS图像集的工作方式https://developer.mozilla.org/en-US/docs/Web/CSS/image-set并进行了一些测试。

前两个部分介绍了图像集和src集/大小作为响应图像的机制。最后一部分总结并讨论了响应式封面图像的发展方向。

影像集

图像设置属性似乎与srcset属性有很大不同。图片集不支持设置多个图片尺寸；它支持设置多种图像分辨率（dpi /密度）。看来WordPress自动生成的不同图像大小都有72DPI。
图像设置属性使浏览器根据某些条件下载最佳图像。条件的一些示例是：

屏幕像素每英寸。
连接速度很慢时，选择下载较低的dpi图像。
向打印机发送邮件时下载更好的图像。

视口大小似乎并不影响图像集选择的图像。

套装和尺寸

Srcset允许我们提供不同图像尺寸的列表（虽然很少使用，但也支持分辨率），并且sizes属性提供了媒体查询（例如语法）来选择显示图像的尺寸。当浏览器知道图像的宽度时，它将从srcset下载最接近的尺寸。

WordPress使用以下sizes属性“（max-width：$ width px）100vw，$ width px”，其中$ width是图像文件的宽度，这意味着如果视口小于$ width，则如果视口小于，则使用视口大小作为图像大小。视口大于$ width使用$ width作为图像宽度。

WordPress srcset和sizes属性对确保在宽度为x像素的屏幕上，我们不会下载宽度大于x的图像。

前进的道路

封面将图像添加为CSS背景，因此，起初，image-set属性似乎很适合让浏览器根据设备从一组可用文件中选择一个图像文件。
但是，当我们说“ Responsive Cover Image”时，我想我们的意思是如果设备视口较小，则应下载较小的图像；如果设备视口较大，则应下载较大的图像。

图像集似乎不允许这种行为。如果设备的像素密度较高（例如，视网膜显示），则可以下载具有更高dpi的图像；如果屏幕的像素密度较小，则可以下载具有低dpi的图像。

手机和计算机的屏幕可能具有相同的像素密度，因此似乎在使用图像集时，两个设备都将下载相同的图像（假定网络速度和其他变量相同）。我们不希望这种行为，我认为我们想在手机上下载“较小”的图片。

使用图像集的另一个挑战是，似乎我们在WordPress上生成的所有图像文件都具有相同数量的DPI。

经过探索之后，该图像集似乎不太适合响应式封面图像。前进的道路似乎是使封面图像使用具有WordPress设置的常规src-set和size属性的图像元素，然后使用CSS使该图像看起来像背景（就像我们对视频所做的那样）。在这条路径上也存在一些挑战，主要是视差问题。我不确定是否可以使用正常的图像元素，但是似乎我们应该尝试一下。

如果我错过了一些事情，或者您还有其他有用的信息，请发表评论。

jorgefilipecosta 于 2020-01-15

👍4 🎉1

好主意，@ jorgefilipecosta。我刚刚创建了＃19909，其目的是探索任何块如何接收响应式编辑。您是否可以看看您的响应式封面图像想法是否可以利用该界面？

jasmussen 于 2020-01-27

如果已经可以广泛支持FLIF或JPEG-XR ...🐱
可以通过一些循环将图像集与常规媒体查询结合起来，
这将导致大量CSS。当然，gzip可能会压缩它，但是它也很复杂，就像开发人员工具中堆积的所有重写的媒体查询一样。
现在，我将<img与srcset和sizes并将其绝对定位在内容的后面。
使用这种方法，我不必处理hidpi / retina部件，而只需提供一些尺寸规则。 -但这必须分别针对样式表进行调整。

当前，封面图像以完整，原始大小，没有调整大小，没有服务器端压缩或任何优化的形式放置为CSS背景图像。当必须上载单独的按比例缩小的变体并将其用于封面时，这对于UX的加载时间非常不利。

strarsis 于 2020-03-01

已经有更新了吗？
我刚刚在自己的网站上添加了一个图片库，现在我的页面大小高达25MB，因为该图片库不加载缩略图，而是加载完整图像。

yethibault 于 2020-04-30

👍2

你好@azaozz和其他人。
我们可以获取此问题的状态更新吗？

似乎在这个问题上发生了很多事情。重要的是将其分解为更易于处理的较小问题。

谢谢。

paaljoachim 于 2020-05-28

👍7

有什么方法可以解决盖勒里问题吗？我的意思是链接到媒体文件？目前，我的某些图像具有有效的全角链接，但大多数图像都链接至大幅面（1024x）。

CNK001 于 2020-10-01

嘿@ CNK001

查看您是否能够找到相关的问题。我搜索了媒体标签问题： https :
如果您找不到，请打开新一期。

paaljoachim 于 2020-10-01

我只是对需要更高级图像处理的用户的支持请求。

kspilarski 于 2020-11-10

在最后一次Wordpress自动更新之后，我的解决方案像...
后端和前端完全搞砸了。我必须重新开始。

有没有人找到画廊不显示缩略图而是显示全尺寸图像的解决方案？
我会非常感激，因为这已经使我不安了一年多了-而且我很高兴...必须再次对这个话题进行深入研究。
非常感谢任何帮助，谢谢您：祝您有美好的一天:-)

ararename 于 2020-11-12

嘿@ararename

画廊正在重新设计以使用内部砌块。有关更多信息，请查看此拉取请求。
https://github.com/WordPress/gutenberg/pull/25940

paaljoachim 于 2020-11-12

@paaljoachim谢谢您的快速回复！要检查:-)

ararename 于 2020-11-12

@ararename，您可以在此期间使用PhotoPress插件。它具有核心库转换。

padams 于 2020-11-12

👍1

感谢@padams提供了另一个选择。我以为我今天会讲到，但是要花几天时间才能回到这个话题。将向您汇报情况。

ararename 于 2020-11-13

👍1

此页面是否有帮助？

0 / 5 - 0 等级

Gutenberg: 增强功能：图像处理

最有用的评论

所有91条评论

提案

实际应用

8593已将srcset和sizes属性添加到单个图库图像，但是sizes属性仍然充当每个图像占用视图的全部内容宽度的角色，这很少案件。

响应式封面图片

影像集

套装和尺寸

前进的道路

相关问题

8593已将`srcset`和`sizes`属性添加到单个图库图像，但是`sizes`属性仍然充当每个图像占用视图的全部内容宽度的角色，这很少案件。