Gutenberg: Предварительный просмотр не отображает правки опубликованных сообщений, когда метабоксы видны в Гутенберге

Я провел быстрый тест с WordPress 5.0-RC3-43967 и не обнаружил такой же проблемы.

Не могли бы вы рассказать мне немного больше о своем тестировании?

Вы тестируете предварительный просмотр черновика или опубликованного сообщения?

Вы нажимали «Предварительный просмотр» каждый раз или сохраняли и пытались перезагрузить ранее открытый предварительный просмотр?

Вы вносите изменения в содержание публикации или вносите изменения в такие вещи, как настройки публикации и метаданные?

Не могли бы вы предоставить краткий список точных шагов тестирования?

Я тестировал оба.

Первоначальный тест проводился на клиентском сайте, где я выполнял пробную установку WordPress 5, в которой я пытался отредактировать существующую страницу. Изменения на этой странице не отображались в предварительном просмотре. Единственный способ увидеть тогда - сохранить страницу.

Затем в качестве более объективного теста я создал и сохранил новую страницу, затем вернулся и отредактировал страницу. Редактирование не отображалось в предварительном просмотре. (Этот тест был на странице, а не в сообщении - я не пробовал тест для сообщения. Не уверен, что это изменит ситуацию)

Из того, что я вижу в вашей записи, вы делаете предварительный просмотр начальной страницы перед сохранением, что отличается от того, что я обнаружил.

Надеюсь, что это поможет прояснить ситуацию.

5 декабря 2018 года в 16:30 Шери Бигелоу [email protected] написала:

Я провел быстрый тест с WordPress 5.0-RC3-43967 и не обнаружил такой же проблемы.

Не могли бы вы рассказать мне немного больше о своем тестировании?

Вы тестируете предварительный просмотр черновика или опубликованного сообщения?

Вы нажимали «Предварительный просмотр» каждый раз или сохраняли и пытались перезагрузить ранее открытый предварительный просмотр?

Вы вносите изменения в содержание публикации или вносите изменения в такие вещи, как настройки публикации и метаданные?

Не могли бы вы предоставить краткий список точных шагов тестирования?

-
Вы получаете это, потому что вы являетесь автором темы.
Ответьте на это письмо напрямую, просмотрите его на GitHub или отключите чат.

Спасибо за разъяснения! На самом деле существует больше сценариев, чем вы думаете, если рассматривать автосохранение в сравнении с «Сохранить черновик», черновик и опубликованный, и публикацию против страницы, и все их комбинации. В моем тесте было 3 случая: новое сообщение -> предварительный просмотр, редактирование черновика -> предварительный просмотр, сохранение и публикация, затем редактирование, затем предварительный просмотр.

Похоже, ваши этапы тестирования:

1. Создать страницу.
2. Сохранить.
3. Перейти к списку страниц.
4. Открыть страницу повторно.
5. Внесите правку в текст.
6. Щелкните Предварительный просмотр.

Примечание к тестированию: поскольку публикация не упоминалась, попробуйте использовать как черновик, так и опубликованную страницу.

Я уверен, что существует множество сценариев.

Это мое.

У меня есть ранее опубликованная страница (которая была создана до обновления сайта до Wordpress 5), которая теперь требует обновления.

После внесения изменений, если я нажму «Предварительный просмотр», обновление не отобразится. Следовательно, невозможно проверить ход обновления настроек на странице без публикации страницы.

Это небезопасный способ редактирования содержимого, поэтому новый редактор становится непригодным для использования в этом реальном сценарии.

Я провел еще один тест после обновления другого сайта до WordPress 5.0, и я все еще вижу, что предварительный просмотр работает нормально. Я тестировал Firefox 63.0.3 на macOS 10.13.6 и пробовал использовать черновик, а также ранее опубликованный пост. Пожалуйста, посмотрите и дайте мне знать, если я все еще что-то упускаю на этапах тестирования!

5.0 только что был выпущен, поэтому я предлагаю обновить и удалить плагин Gutenberg, если он у вас есть (он вам больше не нужен с 5.0). Если после этого у вас все еще возникают проблемы, я бы предложил проверить наличие конфликта плагинов или тем, временно отключив все плагины и переключившись на тему по умолчанию в качестве теста, чтобы увидеть, возникает ли проблема по-прежнему в этих условиях. Если ваша тестовая установка уже была такой, нам нужно подумать, что еще может быть источником проблемы в вашем случае.

Иногда в подобных случаях имеет значение версия ОС или браузера. Я тестировал Mac, и если вы дадите мне знать, что у вас версия ОС и браузера, я могу протестировать еще раз с более похожей на вас настройкой.

У меня также довольно часто возникала эта проблема в wp 5.0, не могу сказать точный сценарий, но она кажется случайной, и у меня никогда не было ее при использовании плагина Gutenberg за последние 5 месяцев. Постараюсь завтра сделать репродукцию.

С помощью
MacOS
Хром

Спасибо @slimmilkduds!

Я также только что закрыл # 12717 как дубликат и хотел отметить, что он также включает видео.

Re:

5.0 только что был выпущен, поэтому я предлагаю обновить и удалить плагин Gutenberg, если он у вас есть (он вам больше не нужен с 5.0). Если после этого у вас все еще возникают проблемы, я бы предложил проверить наличие конфликта плагинов или тем, временно отключив все плагины и переключившись на тему по умолчанию в качестве теста, чтобы увидеть, возникает ли проблема по-прежнему в этих условиях. Если ваша тестовая установка уже была такой, нам нужно подумать, что еще может быть источником проблемы в вашем случае.

Повторение теста с 5.0 без плагинов и с использованием темы по умолчанию не повлияло на результат. Когда я нажимаю кнопку предварительного просмотра, я все еще не вижу изменений.

Для информации я использую Chrome 70.0.3538.110 и MacOS 10.13.6.

Замечу, что вы закрыли тикет №12717

Фактически, это проливает дополнительный свет на это, и я могу подтвердить выводы в этом билете. Изначально кнопка предварительного просмотра не отображает отредактированное содержимое, как я сообщал. Но если вы подождете 5-10 секунд, а затем перезагрузите страницу предварительного просмотра, она отобразит отредактированный контент.

Итак, как сообщается в # 127171 супница, она не полностью разбита. Но, на мой взгляд, сломано достаточно, чтобы сделать его непригодным для использования.

У меня такое же поведение, как и у @davidAIS. Не думаю, что это началось сразу после 5, может быть, обновление 5.0.1 сделало это. Обновление предварительного просмотра через несколько секунд действительно работает.

У меня точно такая же проблема. Я использую Chrome и Windows 10. Я настроил промежуточный сайт, отключил все плагины и активировал тему по умолчанию. Я редактирую страницу, которая опубликована. Затем я нажимаю предварительный просмотр, и мои правки не отображаются. Если я подожду и обновлю, он покажет мои правки, или, если я опубликую пост, он также отобразит мои правки.

Я снова протестировал с WordPress 5.0.1 и Gutenberg 4.7.0 master @ ddac4f3cf и с WordPress 5.0.1, а также с Gutenberg 4.7.0 сегодня, и предварительный просмотр изменений опубликованных сообщений всегда работает в мои тесты. (1 мин. 14 сек. )

Поскольку более чем один из вас упомянул, что вы пробовали тестирование со всеми деактивированными плагинами и с использованием темы по умолчанию, должен быть еще один фактор, о котором мы еще не думали! Если вы заметили что-то, что я пропустил в последнем тестовом видео (ссылка выше), сообщите мне.

Может ли вам случайно мешать локальное правило брандмауэра или кэширующий сервер?

А как насчет расширений или надстроек браузера, у вас какие-то установлены?

Такая же проблема здесь, на большинстве моих сайтов. Все сайты находятся на одном сервере, но по крайней мере один сайт не показывает проблему. Так что это не связано с проблемой сервера. Кроме того, использование Chrome в Windows 10 для всего тестирования - опять же, похоже, что это не проблема браузера, потому что на сайте нет проблем. (И это последовательно - один сайт, который работает, всегда работает; другие, которые я тестировал, всегда терпят неудачу.)

Я попытался отключить все плагины и вернуться к теме TwentyNineteen на одном сайте, но это НЕ решило проблему. Кроме того, сайты с проблемой имеют несколько разных тем, поэтому похоже, что они не привязаны к определенной теме.

Прочитав здесь комментарии, я попытался выполнить жесткое обновление (сдвиг + обновление) во время тестирования, и изменения в предварительном просмотре отображаются именно так ... так что, возможно, проблема с кешированием браузера?

Отредактировано для добавления: теперь я тестировал в Firefox и в гостевом окне в Chrome (с отключенными надстройками). Проблема остается - так что, похоже, она не связана с плагином или надстройкой браузера.

Очень интересно, что проблема непоследовательна в зависимости от среды. По умолчанию .htaccess не работал. Также не отключил брандмауэр моего компьютера и файл hosts. Я также тестировал окно Chrome по умолчанию без расширений.

Я не вижу ошибок консоли или предупреждений. Я не знаком с тем, как WP создает превью, но может ли это быть какая-то временная задержка или задержка БД? Используются ли скрипты? И может ли на это повлиять произвольный порядок скриптов?

Вы можете найти что-то там с комментарием о переходном процессе или задержке БД. У меня около 10 сайтов на общем VPS-сервере - и я нашел только 2 сайта, у которых нет этой проблемы. Эти 2 сайта с очень низким трафиком по сравнению с другими, так что это определенно может быть что-то, что связано с содержимым базы данных и временем загрузки. Это также объясняет, почему он может не отображаться в новых, чистых тестовых установках.

Отредактируйте, чтобы добавить: я посмотрел на размер базы данных для каждого из моих сайтов. Два сайта, которые хорошо работают с превью, имеют размер базы данных 3M или меньше. Среди сайтов, которые вызывают у меня проблемы, самая маленькая БД - 4,1 МБ, но большинство из них больше. Я бы не ожидал, что мои конкретные значения останутся верными для других сайтов, поскольку это будет проблема на стороне сервера, которая также будет связана с нагрузкой на сервер и ресурсами. Но, по крайней мере, это придает вес теории задержки БД.

Я столкнулся с этой проблемой сегодня. Проблема в том, что вы не нажимаете вне редактируемого блока до нажатия кнопки предварительного просмотра.

Нажатие кнопки «Предварительный просмотр» должно автоматически сохранить блок, в котором в данный момент находится курсор, _ затем_ сгенерировать предварительный просмотр.

@designsimply Пожалуйста, дайте мне знать, сможете ли вы воспроизвести эту новую информацию ^

Я столкнулся с этой проблемой сегодня. Проблема в том, что вы не нажимаете вне редактируемого блока до нажатия кнопки предварительного просмотра.

Нажатие кнопки «Предварительный просмотр» должно автоматически сохранить блок, в котором в данный момент находится курсор, _ затем_ сгенерировать предварительный просмотр.

Это не новая информация. Суть этого отчета об ошибке заключается в том, что нажатие кнопки «Предварительный просмотр» НЕ сохраняет изменения блока (под которыми, я полагаю, вы имеете в виду временное сохранение) перед созданием предварительного просмотра.

Кажется, вы предлагаете в своем первом абзаце, что щелчок где-нибудь за пределами блока временно сохранит блок и является необходимым шагом перед нажатием кнопки предварительного просмотра. Конечно, этого не может быть!

@davidAIS Мы на одной странице. Я добавил пояснение, потому что это все еще помечено как «требуется дополнительная информация». На этом этапе он должен быть обновлен как готовый к установке исправлений ...

@scottbuscemi - отслеживание вашего процесса - щелчок за пределами блока - НЕ решает для меня проблему. Независимо от того, что я делаю, страница предварительного просмотра не показывает изменения, пока страница предварительного просмотра не будет обновлена.

Так что нет, хотя это может быть отдельная проблема, это не основная проблема, с которой я сталкиваюсь.

Единственное, что мне подходит, - это либо вернуться в черновой режим (при котором активная страница на действующем сайте будет отключена), либо нажать кнопку «обновить», что сделает функцию предварительного просмотра неактуальной. Или, как уже отмечалось, выполните либо жесткое обновление страницы предварительного просмотра, либо мягкое обновление через интервал в несколько секунд.

У меня такой же опыт, как и у @Armarsh. Мы запускаем wp 5.0.2 на локальном сервере apache, который находится в автономном режиме (в интрасети). Тема - Generatepress. Никогда не было этой проблемы до WP 5 (использовал Gutenberg с июня или что-то в этом роде).

Здравствуйте,

Я просто хотел добавить, что эта проблема существует на wp.org. При добавлении нового абзаца в Canadian Style Guide (https://en-ca.wordpress.org/style-guide/) и нажатии на предварительный просмотр новый блок абзаца не отображается в интерфейсе пользователя.

В #meta упоминалось, что это чаще встречается с существующим контентом, который был преобразован в блоки. Также .org имеет несколько баз данных и интенсивное кэширование, поэтому между сохранением контента и его возвращением может быть задержка.

Slack convo с @ Otto42 - https://wordpress.slack.com/archives/C02QB8GMM/p1545413856002200

Сообщите мне, требуется ли какая-либо информация об архитектуре, и я смогу получить дополнительную информацию о настройке wp.org.

благодаря

Проблема в том, что вы не нажимаете вне блока, который редактируете, до нажатия кнопки предварительного просмотра.
кнопка.

@scottbuscemi Я тестировал это с WordPress 5.0.2 и без активных плагинов, используя Firefox 63.0.3 на macOS 10.13.6, и обнаружил, что всегда могу видеть, что предварительный просмотр работает. ( 38 с )

Я не знаком с тем, как WP создает превью, но может ли это быть какая-то временная задержка или задержка БД? Используются ли скрипты? И может ли на это повлиять произвольный порядок скриптов?

@ xy0 в беседе на https://wordpress.slack.com/messages/C02QB8GMM/ также упоминаются базы данных и тяжелое кеширование:

Я не удивлюсь, если это произойдет больше на .org из-за того, что мы используем несколько баз данных и тяжелое кеширование, поэтому может быть задержка между сохранением контента и его возвращением при чтении этого контента, но эта задержка стремится к очень маленькому. Я думаю, что окно предварительного просмотра пытается загружаться слишком быстро. Это может быть проблема, новая для 5.0

@Armarsh , ваш опыт того, что это происходит с некоторыми сайтами, а не с другими, на одном сервере, протестированном в разных браузерах, интересен. Есть ли что-нибудь, о чем вы можете подумать, что отличается от конфигурации сайта или настроек того, который работает должным образом, по сравнению с другими? А как насчет типа контента - постоянно ли он короче на хорошо работающем сайте или что-то в этом роде?

Я помечаю это как ошибку и добавляю как высокий приоритет, поскольку несколько человек уже сообщили об этом в нескольких проблемах. Я также оставляю метку «требуется дополнительная информация» на тот случай, если кто-то может придумать какие-либо дополнительные сходства между вашими случаями, которые помогут сузить источник проблемы. Спасибо, что уделили внимание деталям этого фильма !!

Как я уже писал выше, разница просто в размерах баз данных, привязанных к каждому сайту. Те, которые работают, имеют общие базы данных менее 3 мегабайт, те, у которых нет баз данных как минимум 4+ мегабайта, и многие из них намного больше. Я не могу найти ничего другого, что могло бы отличать сайты, учитывая, что я уже исключил конфликты тем или плагинов при тестировании на проблемных сайтах.

Из двух сайтов, которые хорошо работают, один очень маленький - всего лишь один из тех простых 5-страничных страниц, на которых приводится основная информация и который редко обновляется. Но другой - довольно сложный и обширный сайт вики-типа, но он предназначен для частного использования, поэтому не индексируется поисковыми системами, что сводит посещаемость сайта к минимуму. Также он в основном текстовый - очень мало изображений. Но когда я создал новые тестовые страницы с несколькими строками текста на проблемных сайтах - проблема не исчезла - поэтому я действительно не думаю, что это связано с содержимым страницы.

Этого не происходит с сообщениями в режиме черновика - вчера я провел много работы над новой, еще неопубликованной страницей с несколькими шорткодами, взятыми из базы данных на одном из проблемных сайтов с базой данных 22+ мегабайт, без проблем. вообще. Но как только страница публикуется, возникает проблема.

Так что я думаю, что это связано с разницей в процессе редактирования опубликованной страницы и черновиком, а также с временем отклика базы данных. Где-то по ходу дела есть дополнительный шаг, который не завершается до первоначального рендеринга страницы предварительного просмотра.

У меня была эта проблема с черновиком на большом (гигабайтовом) сайте базы данных.

Я могу подтвердить на wp.org, что черновики кажутся хорошими. Проблема с предварительным просмотром возникает при редактировании опубликованного поста / страницы.

Если это вообще поможет - вот некоторая системная информация для моих сайтов:

MySQL 5.7
2 из проблемных сайтов работают под управлением PHP 7.1; все остальные сайты (с проблемами и без проблем) работают под управлением PHP 7.2.

У меня такая же проблема, но в моем случае, похоже, ее вызывает Yoast SEO. Когда я деактивирую плагин, предварительный просмотр работает нормально. Если я использую классический редактор с yoast, предварительный просмотр работает нормально. С активным редактором блоков и активным yoast вы можете предварительно просмотреть новую страницу, но как только вы ее опубликуете, предварительный просмотр не покажет ваши изменения. Однако, если вы подождете несколько секунд и обновите страницу предварительного просмотра, изменения отобразятся.

Кто-нибудь уведомил Йоаста?

Я сделал. У них также есть страница на github: https://github.com/Yoast/wordpress-seo/issues/11923

Спасибо, я написал им в Твиттере, что могло бы привлечь больше внимания.

-

Скотт Бушеми
27 декабря 2018 г., 10:43 -0800, Адам Дж. Новак [email protected] написал:

Я сделал. У них также есть страница на github: Yoast / wordpress-seo # 11923
-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub или отключите чат.

Я просто хочу отметить, что я не использую Yoast, и эта проблема все еще возникает

Некоторые из вас, кажется, довольно быстро делают поспешные выводы, что не способствует правильной оценке ситуации. Пожалуйста, делайте заявления о причинах или решениях только тогда, когда они определены путем тщательного технического изучения и тестирования, и, пожалуйста, не обращайтесь к сторонним разработчикам, если нет уверенности в их необходимом участии. Yoast не имеет отношения к этой проблеме.

Я тоже заметил, что предварительный просмотр в редакторе Гутенберга в Wordpress 5.0.2 работает некорректно. Я провел небольшое тестирование и заметил, что после публикации сообщения рядом с кнопкой «Предварительный просмотр» появляется ссылка «Перейти к черновику»:

Пока есть эта ссылка, любые изменения, которые я внес в содержание публикации, не отображаются в предварительном просмотре.

Однако как только я щелкнул эту ссылку, предварительный просмотр снова заработал.

В качестве примечания: я отключил визуальный редактор (из-за плагина, который я использую). Возможно, это как-то связано с поведением.

После отключения Yoast эта проблема не исчезла.

Это странная ошибка, на другом моем сайте отключение yoast не решает проблему. Вам нужно обновить предварительный просмотр примерно через 6-7 секунд, чтобы он отобразился. Так работать очень тяжело.

Я протестировал и подтвердил с помощью WordPress 5.0.2 и Yoast SEO 9.3, что я не могу предварительно просмотреть изменения, внесенные в опубликованные сообщения, только когда активен плагин Yoast.

Я закрываю эту проблему как конфликт плагинов на основе моего собственного тестирования и комментариев @hyptx здесь и сообщаю на https://github.com/Yoast/wordpress-seo/issues/11923.

Для тех из вас, кто испытывает проблему без установленного Yoast, интересно, есть ли у другого плагина аналогичный конфликт. Пожалуйста, проверьте, отключив все плагины, и обязательно очистите кеш перед повторным тестированием. Если после этого проблема не исчезнет, ​​ответьте здесь с соответствующими подробностями, и я буду рад открыть ее снова.

В этом нет никакого смысла.

Тот факт, что Yoast может быть одним из обстоятельств, вызывающих эту ошибку, не означает, что это не ошибка / чувствительность Гутенберга. Билеты не должны закрываться при таком излишнем тестировании, по крайней мере, в первую очередь должна быть определена внутренняя причина, а не просто существование Yoast.

Если Yoast решит изменить что-то в своем плагине, что заставит Gutenberg снова работать, мы все равно ничего не знаем о других сценариях, отличных от Yoast, и процесс придется повторять снова и снова. При этом, вероятно, существует одно обстоятельство для всех заявленных сред. Нонсенс утверждать, что Гутенберг требуется только для правильной работы на полностью ванильных веб-сайтах, его основные функции должны оставаться максимально стабильными при любых обстоятельствах.

Я протестировал и подтвердил с помощью WordPress 5.0.2 и Yoast SEO 9.3, что я не могу предварительно просмотреть изменения, внесенные в существующие сообщения, только когда активен плагин Yoast.

Я закрываю эту проблему как конфликт плагинов на основе моего собственного тестирования и комментариев @hyptx здесь и сообщаю на Yoast / wordpress-seo # 11923 .

Для тех из вас, кто испытывает проблему без установленного Yoast, интересно, есть ли у другого плагина аналогичный конфликт. Пожалуйста, проверьте, отключив все плагины, и обязательно очистите кеш перед повторным тестированием. Если после этого проблема не исчезнет, ​​ответьте здесь с соответствующими подробностями, и я буду рад открыть ее снова.

Это НЕ проблема с плагином и НЕ проблема с Yoast. Это проблема Wordpress 5.0 / Gutenberg.

Я не запускаю Yoast ни на одном из своих сайтов, и перед тем, как сообщить здесь, я тестировал все плагины с отключенными плагинами, используя тему по умолчанию.

Я предоставил очень подробную информацию выше, как и другие, и я разочарован тем, что этот отчет закрывается, поскольку это постоянная проблема с Гутенбергом, которую необходимо решить.

Изменение НАЗВАНИЯ этого отчета, чтобы отразить плагин, который я не использую, не решает проблему.

Открываю новый отчет. Я очень разочарован тем, что он был закрыт, учитывая тот факт, что большинство отчетов в этой ветке НЕ привязаны к Yoast или любому другому конкретному плагину.

Я открыл это как выпуск №13232.

@litemotiv , решение случаев, когда возникают конфликты плагинов, может быть непросто. Обычно сначала просматривают редактор (или текущий плагин) без влияния стороннего кода. Вопрос о том, закрывать ли проблему или продолжать спрашивать подробности, иногда может быть тонким балансом, однако я обнаружил, что часто бывает полезно закрыть и разрешить проблему повторно всплыть без _комментариев, включающих предположения_. Я внимательно наблюдаю за этими проблемами, когда работаю над сортировкой. В этом случае я протестировал несколько раз и не смог воспроизвести проблему, и когда я тестировал с помощью Yoast SEO, я сразу увидел, что проблема возникла, и поэтому я решил отложить открытую проблему в репозитории Yoast в качестве следующего шага. Если это окажется неверным, мы можем снова посетить! В этом случае желательно посмотреть, что получилось из отчета Yoast SEO, а также посмотреть дополнительные отчеты о проблемах с превью здесь. Я ценю вашу заботу и слушаю. Мне жаль, что вы считаете, что тестирование было излишним, и я хотел бы вежливо и уважительно спросить, испытываете ли вы эту проблему и можете ли вы опубликовать список своих активных плагинов. Основываясь на информации, которую я до сих пор видел по этой проблеме, конфликты плагинов кажутся вероятными, и было бы хорошо их сузить, а также возможно, что есть что-то еще, вызывающее проблему, или более одной ошибки, и чем больше о проблеме сообщается непредвзято, тем лучше я чувствую, что смогу помочь с ней.

@Armarsh, пожалуйста, не разочаровывайся. Это может быть тот случай, когда это проблема плагина, а также что-то еще. В вашем случае открытие нового выпуска - хороший путь, и я посмотрю на созданный вами новый выпуск.

@designsimply - означает ли это, что я должен скопировать все мои подробные сообщения здесь, в новый выпуск?

Когда я начал писать здесь, о Йоасте не упоминалось. Вы добавили «Yoast» к названию, когда закрыли его, хотя я и другие авторы здесь указали, что мы тестировали с отключенными плагинами, используя тему по умолчанию.

Я считаю, что наш вклад был полностью проигнорирован.

В моем случае, похоже, существует корреляция с размером базы данных сайта - поэтому проблема, как я описал, не будет реплицирована на новой чистой установке, но будет иметь тенденцию проявляться на более крупном, более развитом или высоком трафике. места. Конечно, это только предположение относительно причины, но я могу заверить вас, что я ИСКЛЮЧИЛ любые конфликты плагинов до того, как разместил здесь - как и несколько других.

Однако я подтвердил конфликт плагинов в собственном тестировании на меньшем сайте. Похоже, что проблему непросто решить, и может быть более одного триггера проблемы. Вам не нужно копировать все отсюда в новый пост, но включение части о размере базы данных определенно является уместной деталью, и я уже добавил ее в комментарии. Я действительно думаю, что разделение вашего отчета на новый, как вы это сделали, - хороший вариант для этого случая!

Несколько минут назад я тестировал на двух разных сайтах, оба не показывали превью:

[сайт 1]
Активные плагины: ACF Pro
После отключения ACF Pro превью начали работать

[сайт 2]
Активные плагины: ACF Pro, Contact Form 7, Редактор меню администратора, Imsanity
После отключения ACF Pro превью все еще не работает (другие плагины не отключены)

Таким образом, похоже, что дело не в отключении определенного плагина, такого как Yoast или ACF Pro, которые, очевидно, являются одними из наиболее часто используемых плагинов на планете.

Спасибо @litemotiv. Это очень полезно. Я посмотрю, что я могу узнать от этих авторов плагинов и разработчиков здесь, и я могу повторно открыть эту проблему (или я могу создать новую), как только узнаю больше.

@litemotiv После отключения остальных плагинов он снова начинает работать?

@scottbuscemi Да, похоже.

На данный момент это просто предположение - что, очевидно, опасно - но возможно, что может возникнуть какое-то состояние гонки, когда несколько источников пытаются вызвать или перехватить таймер / перехватчик автосохранения.

Спекулировать - это нормально! Однако иногда бывает полезно отделить известные проблемы (в данном случае конфликты плагинов) от других предположений (состояние гонки из-за большой базы данных или слишком большого количества вызовов разных плагинов на одном и том же ресурсе). Большое спасибо за тестирование и продолжение добавления деталей!

Повторное открытие этой проблемы с примечанием, чтобы выяснить, являются ли плагины, использующие метабоксы, общим фактором, и оставить # 13232 открытым для изучения угла размера базы данных.

Учитывая, что несколько человек, включая меня, уже установили, что проблема сохраняется даже при отключенных всех плагинах и с темами по умолчанию, дальнейшее изучение проблем, связанных с плагинами, вряд ли будет продуктивным.

У меня никогда не было этой проблемы с превью при использовании классического редактора с WordPress 5 или с предыдущими версиями WordPress.

Поэтому кажется уместным спросить, чем отличается функция предварительного просмотра в редакторе блоков от классической ошибки, с которой, безусловно, следует начинать с этой проблемы.

Если редактор блоков должен выполнить дополнительную обработку для создания предварительного просмотра, которого нет в классическом редакторе, то, возможно, было бы полезно посмотреть, почему редактор блоков не может завершить эту обработку, прежде чем пытаться отобразить предварительный просмотр.

Здесь широко сообщалось, что если предварительный просмотр обновляется через 5-10 секунд, он снова отображается правильно.

Возможно, редактор блоков не ждет достаточно долго, прежде чем отобразит предварительный просмотр, или он неправильно уведомляется о том, что обработка завершена, предварительный просмотр готов к просмотру и преждевременно отображает предварительный просмотр.

Если это так, хотя это может привести к исправлению, это также может вызвать дополнительные проблемы с удобством использования, поскольку процесс предварительного просмотра уже довольно медленный, и добавление дополнительных 5-10 секунд сделает его еще более медленным.

Меня беспокоит та же проблема.
Я сообщаю о своей ситуации в надежде, что это поможет решить проблему.

Предварительный просмотр Гутенберга не работает при определенных условиях.

Если вы вносите изменения в опубликованные статьи и просматриваете их,
Изменения не будут отражены на экране предварительного просмотра и будут отображаться в состоянии до редактирования.
Когда вы нажимаете кнопку «Опубликовать», изменения отражаются как в предварительном просмотре, так и в статье.

Предыстория проблемы такова.

1. Я установил плагин Gutenberg в Wordpress 4.9.8 и протестировал Gutenberg
2. Обновлено до Wordpress 5.0.2.
3. Деактивирован плагин Gutenberg и подтвержден, что с редактором Gutenberg нет проблем.
4. Удален плагин Gutenberg
5. Эта проблема возникла

До удаления плагина Гутенберга Гутенберг также работал с предварительным просмотром без каких-либо проблем.
Также это не означает, что предварительный просмотр вообще не работает даже после возникновения проблем.

В черновиках сообщений с новыми сообщениями превью работает без проблем.
Кроме того, предварительный просмотр работает, если вы измените опубликованное на черновое.
Если вы сделаете его опубликованным, изменения не будут отражены в предварительном просмотре.

Используя классический редактор, предварительный просмотр работает независимо от того, опубликованы они или черновики.

Я не пользуюсь Yoast.
Попробуйте отключить все плагины, переключитесь на другую тему,
Я попытался переустановить "плагин Gutenberg", который вызвал проблему,
Не было улучшено.
Я попробовал описанную выше процедуру в другой среде, но не смог воспроизвести проблему.

Хотя может быть много способов возникновения такого поведения, я заметил, что это происходит с этой комбинацией, включающей метабоксы PHP:

1. Опубликованный пост просматривается с автоматическим сохранением.
2. Запрос POST на сохранение мета-блоков PHP отправляется на post.php . Опубликованный пост обновляется, а время его последнего изменения увеличивается.
3. POST запрос перенаправляется в GET запроса на post.php снова. Выполняется эта логика, которая сравнивает измененные даты автосохранения и публикации: https://github.com/WordPress/wordpress-develop/blob/e5b5db9e2349dfe8a43ac42bea5738146f53994d/src/wp-admin/edit-form-blocks.php#L294 - L303
4. Дата изменения сообщения теперь более поздняя, ​​чем дата автосохранения, поэтому автосохранение удаляется.
5. Предварительный просмотр загружается, но больше нет автосохранения для предварительного просмотра.

Функциональность предварительного просмотра работает с помощью компонента post-preview-button имеющего вызов componentDidUpdate() который в основном пытается загрузить URL-адрес предварительного просмотра в окно предварительного просмотра каждый раз, когда компонент повторно отображается. Он останавливается, если нет доступной ссылки предварительного просмотра или окна предварительного просмотра.

Итак, когда вы нажимаете кнопку предварительного просмотра, по сути происходит следующее:

1) Он проверяет, существует ли уже окно предварительного просмотра, если нет (или было закрыто), он открывает новую вкладку / окно для предварительного просмотра
2) Он фокусируется на окне предварительного просмотра (что означает, что остальная часть этого происходит в фоновом режиме, поскольку в вашем браузере теперь сфокусировано окно предварительного просмотра)
3) Он проверяет, можно ли сохранить сообщение автоматически с помощью isEditedPostAutoSaveable() и если его нельзя автоматически сохранить, он просто открывает URL-адрес в атрибуте href кнопки предварительного просмотра и останавливается.
4) Если мы дошли до этой точки, автосохранение возможно, скорее всего, потому, что есть правки. Но сначала он смотрит, есть ли это draft , и если да, то просто выполняет обычное сохранение.
5) Если это не черновик, то запускается автосохранение, потому что мы пока не хотим обновлять живой контент.
6) Как автосохранение, так и обычное сохранение имеют одинаковый эффект, вызывая повторный рендеринг компонента , что вызывает componentDidUpdate() и заставляет окно предварительного просмотра перезагружаться.

Похоже, здесь есть несколько возможностей для состояний гонки из-за различных движущихся частей, необходимых для определения, когда загружать предварительный просмотр и какой URL-адрес загружать. Мне нужно провести еще несколько тестов, чтобы увидеть, где я могу это сделать.

Я сталкивался с этой проблемой на каждой странице сайтов, обновленных до 5.0. На любой странице, созданной до обновления, не отображаются изменения в предварительном просмотре или после публикации. Преобразование страницы в блоки, похоже, не решает проблему.

У меня есть эта проблема на 10 разных сайтах с 8 разными темами - и единственное, что разделяет каждый сайт, это то, что это началось с обновления WP 5.0 / Gutenberg. Так или иначе, я думаю, что в этом суть проблемы. И снова, отключение плагинов и возврат к Twentynineteen не помогли решить проблему на сайтах, которые я тестировал.

Я провел дополнительное тестирование, но все еще ищу надежные шаги для воспроизведения проблемы, не связанной с плагинами.

Основываясь на информации в https://github.com/WordPress/gutenberg/issues/12617#issuecomment -449520938, я провел следующий тест:

1. Перейдите на https://jurassic.ninja/ и создайте новый тестовый сайт.
2. Перейдите в Плагины> Добавить новый, найдите FakerPress, установите и активируйте.
3. Перейдите в FakerPress> Сообщения и создайте 200 сообщений и 80 страниц.
4. Проверьте размер базы данных с помощью wp db size --size_format=kb через wp-cli (учетные данные ssh для сайтов jurassic.ninja указаны в уведомлении администратора).
5. Перейдите в «Сообщения» и откройте любой опубликованный пост.
6. Внесите какие-либо изменения в сообщение.
7. Нажмите кнопку «Предварительный просмотр» и проверьте, отображается ли изменение в предварительном просмотре.

Результат: база данных, включающая образцы контента, была 5,8 МБ, и все предварительные версии по-прежнему работали нормально в моем собственном тестировании. (1 мин. 38 сек. )

Продолжая, я решил еще раз протестировать Yoast SEO, поскольку они недавно обновились до версии 9.4.

1. Перейдите в Плагины и установите или обновите Yoast SEO 9.4.
2. Перейдите в «Сообщения» и откройте любой опубликованный пост.
3. Внесите какие-либо изменения в сообщение.
4. Нажмите кнопку «Предварительный просмотр» и проверьте, отображается ли изменение в предварительном просмотре.

Результат: предварительный просмотр изменений, внесенных в опубликованные сообщения, не отображается, если Yoast SEO 9.4 установлен и активирован. ( 53 с )

Наконец, я протестировал расширенные настраиваемые поля, поскольку в предыдущих комментариях это упоминалось как проблемное.

1. Перейдите в Plugins и установите или обновите Advanced Custom Fields 5.7.9.
2. Перейдите в «Сообщения» и откройте любой опубликованный пост.
3. Внесите какие-либо изменения в сообщение.
4. Нажмите кнопку «Предварительный просмотр» и проверьте, отображается ли изменение в предварительном просмотре.

Результат: предварительный просмотр изменений, внесенных в опубликованные сообщения, не отображается при использовании расширенных настраиваемых полей 5.7.9. (1 мин. 23 сек. )

Что я вижу в тестировании, так это то, что я могу определенно соотнести некоторые плагины, особенно плагины, использующие мета-блоки, с проблемой, но я не уверен, являются ли они причиной. Также могу сказать, что лично не вижу проблемы для сайта с базой данных 5,8 МБ. Для тех из вас, у кого возникают проблемы даже после деактивации всех плагинов и переключения на тему по умолчанию, я еще не уверен, что вызывает проблемы в вашем случае. @earnjam , если у вас есть идеи, что еще протестировать, дайте мне знать, и я смогу помочь!

@KristaSnapdragon Я заметил, что вы упомянули, что проблема возникает на страницах, созданных до обновления до WP 5.0. Могу я спросить, возникает ли у вас такая же проблема с сообщениями, которые вы создаете _после_ обновления до WP 5.0?

Я тестирую сайт, который был создан до WP 5.0 и редактора блоков, но теперь со всеми плагинами, кроме Classic Editor, отключенными и использующими тему 2019.

В этой конфигурации я постоянно вижу сообщаемую проблему с редактированием существующих страниц при редактировании с помощью редактора блоков. То же самое, если я отключу плагин Classic Editor.

Другими словами, здесь нет взаимодействия с Yoast или любым другим плагином в случае контента, созданного до WP5.0 и редактора блоков.

Если классический редактор отключен, я могу создавать новый контент и редактировать контент, созданный с помощью редактора блоков, и предварительный просмотр работает правильно.

Но если плагин Classic Editor включен, проблема возникает при редактировании нового контента, который был создан после включения Classic Editor - даже если он был создан с помощью редактора блоков.

Может возникнуть соблазн сделать вывод, что проблема заключается в конфликте с самим классическим плагином. Однако тот факт, что проблема возникает для контента, созданного до WP5 и редактора блоков, когда он впоследствии редактируется с помощью редактора блоков и когда нет активированных плагинов, свидетельствует об обратном. Происходит нечто более фундаментальное!

Хотя может быть много способов возникновения такого поведения, я заметил, что это происходит с этой комбинацией, включающей метабоксы PHP:

1. Опубликованный пост просматривается с автоматическим сохранением.
2. Запрос POST для сохранения мета-блоков PHP отправляется на post.php. Опубликованный пост обновлен, а время последнего изменения помечено.
3. Запрос POST снова перенаправляется как запрос GET на post.php. Выполняется эта логика, которая сравнивает измененные даты автосохранения и публикации: https://github.com/WordPress/wordpress-develop/blob/e5b5db9e2349dfe8a43ac42bea5738146f53994d/src/wp-admin/edit-form-blocks.php#L294 - L303
4. Дата изменения сообщения теперь более поздняя, ​​чем дата автосохранения, поэтому автосохранение удаляется.
5. Предварительный просмотр загружается, но больше нет автосохранения для предварительного просмотра.

@ dlh01 Спасибо за отладку. Я думаю, это самое ясное объяснение того, что здесь происходит. 👍

@talldan Есть также люди, сообщающие об этом без каких-либо мета-блоков, поэтому я не думаю, что это единственный виновник.

@earnjam Ага, но я не хочу, чтобы в этой ветке хоронили очень хорошее объяснение одной из причин.

Нечего добавить, за исключением того, что у меня такая же проблема с Yoast и ACF на ванильном WP с использованием Twenty-Nineteen.

• Предварительный просмотр работает должным образом, когда страница не опубликована.
• Если страница опубликована, то дальнейшие изменения, внесенные через блоки Гутенберга, не отображаются при предварительном просмотре. Мне нужно отменить публикацию страницы, чтобы предварительный просмотр снова начал работать.
• Отключение Yoast / ACF решает проблему.

Отключение Гутенберга / установка классического редактора позволяет предварительному просмотру работать должным образом.

Использование PHP 7.2.9 и MySQL 5.7

У меня тоже есть проблема.

1. Сообщение создано в классическом редакторе и опубликовано
2. Попытка редактировать с Гутенбергом
3. Предварительный просмотр не отображает изменения

У меня тоже есть проблема, но в отличие от других, которые разместили здесь, моя версия wordpress еще не обновлена ​​до 5. Даже обновление страницы предварительного просмотра не работает для меня.

@ nicosabio2016 спасибо за заметку! Не могли бы вы отметить более подробную информацию о вашей установке для справки? Например, точная версия WordPress, версия плагина Gutenberg, пробовали ли вы тестирование со всеми временно отключенными плагинами, и как долго проблема возникла с вами (если вы помните!).

@bhagwad, было бы здорово, если бы вы могли включить некоторые дополнительные сведения, такие как ваша версия WP и тестировались ли вы без активных плагинов. Спасибо!

@ jweston491 благодарим вас за подтверждение того, что проблема возникает только при предварительном просмотре правок опубликованных сообщений и только в том случае, если у вас активированы плагины ACF или Yoast.

У меня такая же проблема с 5.0.3, размещенным на IIS, предварительный просмотр не отражает изменения, сделанные на странице. Проблема возникла при обновлении с 4.9.4 на 5.0.3. Есть ли решение для этого?

Хотя может быть много способов возникновения такого поведения, я заметил, что это происходит с этой комбинацией, включающей метабоксы PHP:

1. Опубликованный пост просматривается с автоматическим сохранением.
2. Запрос POST на сохранение мета-блоков PHP отправляется на post.php . Опубликованный пост обновлен, а время последнего изменения помечено.
3. POST запрос перенаправляется в GET запроса на post.php снова. Выполняется эта логика, которая сравнивает измененные даты автосохранения и публикации: https://github.com/WordPress/wordpress-develop/blob/e5b5db9e2349dfe8a43ac42bea5738146f53994d/src/wp-admin/edit-form-blocks.php#L294 - L303
4. Дата изменения сообщения теперь более поздняя, ​​чем дата автосохранения, поэтому автосохранение удаляется.
5. Предварительный просмотр загружается, но больше нет автосохранения для предварительного просмотра.

Мы проверили эту гипотезу с помощью плагина Yoast SEO, и похоже, что @ dlh01 верен .

При нажатии кнопки предварительного просмотра запускаются два автосохранения: одно из самого сообщения и одно из метабокса Yoast. У автосохранения поста есть отметка времени за одну секунду до автосохранения метабокса. Это означает, что после вышеупомянутого сравнения дат автосохранение сообщения удаляется, а автосохранение метабокса используется для предварительного просмотра.

Поскольку автосохранение метабокса не содержит содержимого сообщения (наша гипотеза), оно использует содержимое исходного сохранения, что означает, что последние изменения (которые были в удаленном автосохранении) не отображаются в предварительном просмотре.

В целях тестирования мы изменили > на < в https://github.com/WordPress/wordpress-develop/blob/e5b5db9e2349dfe8a43ac42bea5738146f53994d/src/wp-admin/edit-form-blocks. php # L296. В этом сценарии он сохраняет автосохранение из содержимого, что означает, что предварительный просмотр актуален.

Когда мы отключаем yoast metabox (но оставляем плагин активным), проблемы исчезают, и предварительный просмотр также обновляется.

Спасибо за тестирование и оставив комментарий с результатами @IreneStr!

Сегодня я потратил немного времени, чтобы повторно протестировать последние версии разработки WordPress 5.0.4-alpha-44523 и Gutenberg 4.9.0-rc.1 и Yoast SEO 9.5 (и без Yoast SEO) с использованием https://jurassic.ninja / test site и обнаружил, что я все еще не могу предварительно просмотреть изменения опубликованных сообщений.

@IreneStr & @ dlh01 Отлично , спасибо за подтверждение этой причины.

Дата изменения сообщения теперь более поздняя, ​​чем дата автосохранения, поэтому автосохранение удаляется.

У меня есть идея довольно простого исправления для этого, а именно: не удалять автосохранение, если запрашивается обновление meta_box. Измените его с:

    } else {
            wp_delete_post_revision( $autosave->ID );
    }

кому:

    } elseif ( ! isset( $_REQUEST['meta_box'] ) ) {
        wp_delete_post_revision( $autosave->ID );
    }

Казалось, что проблема решена, когда я ее тестировал, но я не совсем знаком с кодом для обновления метабоксов. Может, есть лучшее решение.

@talldan Я думаю, поскольку мы запускаем два запроса на сохранение (post api и metabox), когда у нас есть метабоксы, я думаю, что идея заключалась в явном удалении ревизий. Так что, вероятно, вместо того, чтобы удалять автосохранение метабокса, мы должны перезаписать предыдущее. Что вы думаете?

@talldan Я не уверен, что достаточно хорошо знаком со всеми намерениями edit-form-blocks.php чтобы высказать действительно обоснованное мнение о добавлении $_REQUEST чека в этом месте. Однако я полагаю, что это решило бы насущную проблему.

Но текущая логика удаления ревизии сама по себе тоже кажется здравой. Запрос на сохранение мета-боксов PHP приводит к «истинному» обновлению сообщения через wp_update_post() , а не к другому автосохранению. Во всех других случаях ядро ​​будет (я думаю?) Ожидать, что существующее старое автосохранение будет удалено при следующей возможности. См. Аналогичную логику в edit-form-advanced.php : https://github.com/WordPress/wordpress-develop/blob/e5b5db9e2349dfe8a43ac42bea5738146f53994d/src/wp-admin/edit-form-advanced.php#L226 -L239.

Поэтому создание сценария, в котором автосохранение существует, когда ядро ​​не ожидает его существования, может иметь побочные эффекты.

Опять же, я могу ошибаться в фактах, и риск, связанный с добавлением исключения, в любом случае может быть минимальным.

Так что, вероятно, вместо того, чтобы удалять автосохранение метабокса, мы должны перезаписать предыдущее. Что вы думаете?

@youknowriad Значит, вы имеете в виду перезапись / обновление любого существующего автосохранения во время обновления вторичного мета-блока? Это улучшило бы ситуацию, поскольку у вас больше не было бы автосохранения, которое старше, чем пост, чего, похоже, пытается избежать этот код.

Но текущая логика удаления ревизии сама по себе тоже кажется здравой. Запрос на сохранение мета-боксов PHP приводит к «истинному» обновлению сообщения через wp_update_post (), а не к другому автосохранению. Во всех других случаях ядро ​​будет (я думаю?) Ожидать, что существующее старое автосохранение будет удалено при следующей возможности.

@ dlh01 Ага. Я думаю, что то, как Гутенберг обрабатывает обновления метабокса, определенно является крайним случаем. Вы правы в том, что, вероятно, будет хорошей идеей придерживаться этого основного правила: не сохранять автосохранения старше публикации.

Еще одно решение, которое пришло в голову, - изменить порядок обновлений при предварительном просмотре:

1. Обновить мета поста
2. Автосохранение сообщения
3. Показать превью

Скорее всего, это будет связано с каким-то не идеальным кодом в Gutenberg, поскольку мета-сохранение записи в настоящее время запускается как побочный эффект с использованием подписки:
https://github.com/WordPress/gutenberg/blob/0259f7b2aec9ab66f3a040d08a5aeeb5c65e5756/packages/edit-post/src/store/effects.js#L50 -L72

У меня очень похожая проблема, однако изменения появляются, если я жду 5 секунд после загрузки предварительного просмотра, а затем нажимаю перезагрузку.

Также есть отчет от @dariaknl, который, возможно, потребует некоторых действий:

@gziolo Я изучил эту проблему (№13038) с помощью плагина wordpress-seo (с тестами e2e). Ваш тест не проходит:

    Expected: "Hello World! And more."
    Received: "Hello World!"

      107 |       // Title in preview should match updated input.
      108 |       previewTitle = await previewPage.$eval( '.entry-title', ( node ) => node.textContent );
    > 109 |       expect( previewTitle ).toBe( 'Hello World! And more.' );

• после публикации поста не обновляется заголовок в предварительном просмотре, если вы измените заголовок.
  Действительно, тест проходит успешно с отключенным wordpress-seo.

Но я попробовал тот же тест со встроенными расширенными панелями «Настраиваемые поля» и отключенным wordpress-seo. Получаю тот же результат - тест не проходит, обновленный заголовок не отображается в превью. Так что, похоже, проблема больше связана с проблемой метабокса в целом.

Я тестировал: WP 5.0.3 и Gutenberg 4.8.0 и 4.9.0.

Покопался в этом. В моем тестировании удаление автосохранения в любом случае не имело значения.

Проблема возникает из-за нескольких критериев:
1) В опубликованных сообщениях мы просто хотим запустить автосохранение, а не обычное сохранение при предварительном просмотре, потому что мы пока не хотим обновлять фактический опубликованный контент.
2) Мета публикации не поддерживает редакции, поэтому она должна выполнить стандартное сохранение и немедленно обновить.

Сохранения в Metabox обрабатываются от POST до /wp-admin/post.php . Это вызывает вызов edit_post() и, в конечном итоге, wp_update_post() , который всегда будет обновлять дату post_modified опубликованного сообщения. Поскольку запрос на сохранение метабокса приходит после запроса автосохранения, дата post_modified в опубликованном посте на 1 секунду новее, чем в созданном автосохранении. Предварительный просмотр видит это и просто загружает опубликованный пост, поскольку он новее.

Нам нужна дата автосохранения post_modified до >= опубликованного сообщения. Изменение порядка, в котором выполняются два отдельных вызова, кажется логичным решением, если это возможно.

Я еще раз посетил это сегодня, чтобы проверить переупорядочение двух запросов в предварительном просмотре, и теперь я вижу, как он удаляет автосохранение. (Я думаю, что смотрел на вызов wp_delete_post_revision() в ядре, но у меня был активен плагин Gutenberg, который переопределяет экран редактора и имеет собственный вызов этой функции)

Для предварительного просмотра также не имеет значения, является ли автосохранение post_modified старше или новее, чем фактическое сообщение (я тестировал, изменяя его напрямую). Предварительный просмотр показывает автосохранение post_content если оно вообще существует. Так что проблема действительно связана с удалением автосохранения.

Так что игнорируйте весь мой пост над этим ¯ \ _ (ツ) _ / ¯ 😀

Я попытался удалить подписку на сохранение метабокса при предварительном просмотре, а затем напрямую вызвать ее из кнопки предварительного просмотра перед запросом автосохранения, чтобы увидеть, будет ли этого достаточно, но это все еще ситуация состояния гонки, которая часто заканчивается удалением автосохранения, потому что обычно это немного быстрее выполняется, чем сохранение метабокса.

Похоже, что мы должны либо дождаться ответа от сохранения метабокса, прежде чем запускать автосохранение, что сделает их еще медленнее, чем они есть, либо сделать какое-то исключение для удаления автосохранения, например @talldan, упомянутого выше. Оба кажутся ... не очень хорошими.

@earnjam Спасибо, что

Есть мысли о том, какой вариант лучше?

Также следует упомянуть, что есть пара тикетов trac, в которых также есть обсуждения:
https://core.trac.wordpress.org/ticket/45768
https://core.trac.wordpress.org/ticket/45532

Интересно. Я впервые испытал это сегодня, редактируя старый пост 2011 года, который он поместил в полный классический блок. Я добавил блок абзаца над ним и удалил ссылку из классического блока. Щелкнул «Предварительный просмотр», и он показал то, что у меня было до каких-либо правок без изменений. Я пробовал щелкать по разным разделам, но без разницы. Итак, я просто нажал «Обновить», а затем предварительный просмотр показал правильный контент.

В любом случае, я использую WP 5.0.3, дочернюю тему Twenty Twelve и использую Firefox 65.

Просто протестируйте снова, и, как некоторые другие, я подожду несколько секунд и обновлю вкладку с предварительным просмотром, затем я увижу изменения. Итак, некоторые странные проблемы с синхронизацией.

Прошло довольно много времени с тех пор, как я редактировал старую публикацию, поэтому я не уверен, как давно это могло начаться.

Приносим извинения за задержку с исправлением этой проблемы - это сложная проблема. Теперь у меня есть предлагаемое исправление на # 13718.

Не знаю, поможет ли, но заметил следующее:

• это происходит только на определенных существующих страницах (созданы новые, а ошибки не было)
• для страниц, на которых обнаруживается ошибка, браузер загружает страницу только один раз
• для страниц, на которых НЕ присутствует ошибка, браузер дважды загружает содержимое страницы. (На самом деле это не очень чистый дизайн, даже в тех случаях, когда он «работает». Вы можете видеть, что текущий опубликованный контент отображается на долю секунды ... затем страница становится пустой, браузер инициирует вторую загрузку и, наконец, появятся текущие несохраненные черновики правок).

Итак, можем ли мы предположить, что это связано с некоторыми состояниями, связанными с заданной публикацией страницы в базе данных SQL, которые используются в логике кнопки предварительного просмотра? Эти состояния, также связанные с логикой автосохранения, действительно кажутся беспроигрышными.

Возможно, всю логику предварительного просмотра следует переписать с нуля ... Я отслеживал проблемы, связанные с этим, еще с 2013 года или около того, на довольно старых выпусках WordPress. Кажется, это была серьезная ошибка уже довольно давно.

Если возможно, трюк с двойной загрузкой следует заменить более чистой логикой, которая загружается только один раз, даже если это неопубликованная версия контента.

С уважением.

Я тоже только что заметил, как это происходит; ни одно из правок из окна администратора (код / ​​CSS) не отображается в экземпляре предварительного просмотра.

Небольшое примечание: эта проблема, похоже, усугубилась с обновлением WP 5.1.

Раньше: предварительный просмотр не отображался изначально, но был доступен для просмотра через несколько секунд после обновления страницы предварительного просмотра.

Сейчас: предварительный просмотр вообще не отображается. Возможны следующие варианты: обновить опубликованную страницу, чтобы увидеть изменения, или вернуть опубликованной странице статус черновика при завершении редактирования.

Да, я могу подтвердить. В версии 5.1 при редактировании существующей публикации предварительный просмотр не будет отображать никаких изменений. У меня тоже больше не работает обновление страницы предварительного просмотра. Так что да, стало еще хуже . (Firefox 65.0.1 в Windows 7)

Я также не работаю, если редактирую только что созданный пост в 5.1.

Предварительный просмотр работал отлично, поскольку я делаю сообщение, но еще не опубликовал его.

Та же проблема, но работает с черновиками, а с опубликованными нет.

Я изменил заголовок, чтобы отразить конкретные детали, указанные в этой проблеме как виновника. Это поможет нам отличить его от # 13232, если есть другая ситуация, когда метабоксы не являются причиной.

У меня была КНОПКА ПРОСМОТРА _ ничего не делать_ на нескольких веб-сайтах, даже с WP5.1, и это болезненно.

Привет всем - Давний слушатель, впервые звоню! Мне нравится новый редактор блоков, и я очень ценю вашу работу.

Я немного изучил это, потому что у нас есть много клиентских сайтов, которые мы обновили, и мы широко используем мета-блоки. Я не разработчик реагирования, поэтому мне очень жаль, если этот комментарий бесполезен. Тем не менее, мне бы очень хотелось, чтобы предварительный просмотр работал, поэтому я подумал, может быть, эти идеи могут быть полезны. Кроме того, я работаю только над файлами сборки, которые в настоящее время включены в 5.1, поэтому я не знаю, обязательно ли сработают мои предложения.

Для меня это похоже на проблему порядка операций. Я вижу, что при срабатывании автосохранения в компоненте редактирования-публикации есть слушатель, который похож на «эй, мы только что сделали автосохранение? У нас есть мета-блоки? (Я вижу, что это происходит в строках 46-72 файла edit-post / src / store / effects.js ), а затем обновление, запрошенное компонентом edit-post, переопределяет состояние, и, таким образом, сгенерированный предварительный просмотр не для последнего автосохранения . Если я закомментирую подписчика в этих строках в моем файле сборки, предварительный просмотр будет работать нормально (однако я понятия не имею о последствиях, которые приводят к предварительному просмотру изменений в метабоксах).

Мне кажется, что это должен быть компонент редактора, который сначала передает компоненту редактирования-публикации, что он собирается обработать автосохранение, таким образом компонент редактирования-публикации может запрашивать его обновления, затем компонент редактора может обрабатывать автосохранение и таким образом превью будет последним автосохранением. Хотя я не знаю, как это сделать, поэтому я не уверен, как это может выглядеть.

Однако мне также удалось заставить его работать, отправив новое автосохранение внутри связанного обратного вызова в строке 117 файла, указанного выше, effect.js . Непосредственно вызывая новое автосохранение, например: dispatch('core/editor').autosave() . Возможно, это очередное хакерское решение. Итак, мое редактирование выглядит так:

// starting on line 111
apiFetch( {
            url: window._wpMetaBoxUrl,
            method: 'POST',
            body: formData,
            parse: false,
        } )
            .then( () =>{ 
                              // invoke new autosave - maybe add some more conditional logic here to figure out
                             // what triggered this request so that if it's a full save, we request a save, or if it's an
                             // autosave we do an autosave like so.
                              dipatch('core/editor').autosave();
                              store.dispatch( metaBoxUpdatesSuccess() ) 
                        });

Предварительный просмотр у меня не работает в 5.1. Я ждал 5.1, чтобы попробовать Гутенберга, предполагая, что к этому моменту он будет работать правильно ... как я могу отредактировать свои (предварительно опубликованные) сообщения и просмотреть предварительный просмотр? Это самое простое, что я могу придумать. Я должен каждый раз нажимать обновление.

Фактический предварительный просмотр внутри Gutenberg не отражает того, как он отображается в опубликованном посте, форматирование текста по отношению к изображениям отличается.

Мне бы действительно очень понравился Гутенберг, если бы он работал :)

Предварительный просмотр у меня не работает в 5.1. Я ждал 5.1, чтобы попробовать Гутенберга, предполагая, что к этому моменту он будет работать правильно ... как я могу отредактировать свои (предварительно опубликованные) сообщения и просмотреть предварительный просмотр? Это самое простое, что я могу придумать. Я должен каждый раз нажимать обновление.

Фактический предварительный просмотр внутри Gutenberg не отражает того, как он отображается в опубликованном посте, форматирование текста по отношению к изображениям отличается.

Мне бы действительно очень понравился Гутенберг, если бы он работал :)

Я здесь в той же лодке. Я думал, что сейчас он будет стабильным, но мой предварительный просмотр в 5.1 буквально никогда не работает. :(

Запуск WP 5.1 на Google Cloud Compute Engine (нажмите, чтобы развернуть)

В 5.0.3 предварительный просмотр не работает. Попытка обновить или очистить кеши на странице предварительного просмотра ничего не меняет.

Как упоминалось по другой проблеме (https://github.com/WordPress/gutenberg/issues/13232), теперь, похоже, она решена. Я не уверен, какое именно изменение привело к исправлению.

Нет. Не исправлено в 5.1.1. При редактировании существующей публикации и нажатии на предварительный просмотр изменения не отображаются.

@talldan После тестирования нескольких тем я заметил, что эта проблема возникает в тех темах, которые имеют настраиваемые мета-поля для страницы. В той теме, в которой нет настраиваемого мета-блока, предварительный просмотр работает должным образом.

Большинство сайтов WP, управляемых данными, используют некоторую форму настраиваемых полей, наш сайт как
пример использует ACF.

Пятница, 15 марта 2019 г., в 2:23 Nilambar Sharma [email protected]
написал:

@talldan https://github.com/talldan После тестирования нескольких тем я заметил
что эта проблема возникает в той теме, которая имеет настраиваемые мета-поля для
страница. В той теме, в которой нет настраиваемого мета-блока, предварительный просмотр работает как
ожидается.

-
Вы получили это, потому что оставили комментарий.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/WordPress/gutenberg/issues/12617#issuecomment-473172823 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/ADUrkUAGtSmWGiDRvdyUbSVPhCymk6s_ks5vWzxKgaJpZM4ZC_rC
.

На моих сайтах с WP 5.1.1 отсутствует предварительный просмотр.

@ernilambar Я тестировал с использованием настраиваемого поля, которое имеет тот же эффект.

@Armarsh , @MarkRH - Я тестировал против master и не смог воспроизвести. Если это исправлено, есть вероятность, что исправление еще не выпущено.

Большинство сайтов WP, управляемых данными, используют те или иные формы настраиваемых полей, наш сайт в качестве примера использует ACF.
…
В пятницу, 15 марта 2019 г., в 2:23 Nilambar Sharma @ . * > писал: @talldan https://github.com/talldan После тестирования нескольких тем я заметил, что эта проблема возникает в тех темах, которые имеют настраиваемые мета-поля для страницы. В той теме, в которой нет настраиваемого мета-блока, предварительный просмотр работает должным образом. - Вы получили это, потому что прокомментировали. Ответьте на это письмо напрямую, просмотрите его на GitHub < # 12617 (comment) > или отключите поток https://github.com/notifications/unsubscribe-auth/ADUrkUAGtSmWGiDRvdyUbSVPhCymk6s_ks5vWzxKgaJpZM4ZC_rC .

После некоторого тестирования я могу подтвердить, что это была проблема моего сайта. Любые темы / плагины, которые добавляют мета-поле к редактору страницы, приведут к тому, что кнопка предварительного просмотра не будет работать. Я удалил все, что добавляло мета-поле из 5 различных установок WordPress, и теперь кнопка предварительного просмотра снова работает.

Надеюсь, эта проблема будет исправлена ​​в будущем, но быстрое решение - установка классического плагина редактора.

На моих сайтах с WP 5.1.1 отсутствует предварительный просмотр.

То же самое, используя Opera v. 60.0.3254.0 в Windows 10 и v. 58.0.3135.107 в Mac OS X 10.14.3

После повторного тестирования похоже, что проблема все еще существует 😞

Извините за все надежды.

+1, Моя комбинация Windows 10 + chrome Версия 72.0.3626.121

+1, могу подтвердить, что у нас одинаковые проблемы с Windows 10 и Chrome 72.0.3626.121

Такая же проблема с 5.1. Я обнаружил, что дело не в том, что предварительный просмотр не заполняет пространство, а в том, что шрифт по умолчанию белый, то есть белый по белому. (Также Arial 50, чего я не хочу.) Я могу изменить цвет шрифта в своей форме, но не размер или стиль. В моем случае это можно исправить в нашей теме, но я всего лишь конечный пользователь WordPress, а не разработчик (который находится на расстоянии 8 часовых поясов, поэтому сейчас я не могу это исправить).

+1, так как почти все профессиональные сайты WordPress используют какую-то систему настраиваемых метаполей - это влияет почти на каждый сайт, на котором работает Gutenberg в настоящее время.

Все еще происходит на 5.1.1. Я сегодня обновился с 4.x до 5.1.1. После адаптации к новому редактору я столкнулся с этой проблемой. Надеюсь, в ближайшем будущем будет исправление.

Сейчас Гутенберг совершенно не работает. Раньше я обходил проблему отсутствия предварительного просмотра, дублируя страницу и переключая ее на черновик. Теперь любое новое сообщение, созданное с помощью нового редактора блоков, переименовывает заголовок в «Авто-черновик» и не будет сохраняться. Создание сообщений нормально работает с плагином Classic Editor, но когда я пытаюсь редактировать их с помощью Gutenberg, они вообще не сохраняются или не просматриваются.

Эта проблема стала настолько серьезной, что я полностью отключил Гутенберга - очевидно, потому что он ничего не может сохранить.

У меня нет проблем с созданием новых страниц с помощью Gutenburg - только выпуск предварительного просмотра с уже опубликованными страницами. Как вы дублируете страницу? Мне кажется, что вы можете использовать плагин для создания дубликата, и это то, что дает вам название "авто-черновик" --- и, возможно, проблема с сохранением связана с плагином ??? Вы пробовали просто создать новую страницу с нуля?

Я все еще могу воспроизвести эту проблему с WordPress 5.1.1 и плагином Gutenberg версии 5.4.

Тестовая процедура:

1. отключить все плагины
2. проверьте, что _Custom Fields_ отключены в параметрах редактора блоков
3. внесите некоторые изменения в сообщение, нажмите _Preview_ и убедитесь, что ваши изменения отображаются
4. включить _Custom Fields_ в параметрах редактора блоков
5. внесите некоторые изменения в сообщение, нажмите _Preview_ и убедитесь, что ваши изменения не отображаются

Эта ошибка проявляется каждый раз, когда я редактирую и хочу просмотреть уже опубликованный пост. Изменения никогда не просматриваются. (Windows 7, Opera, последняя версия WordPress со «встроенным» Gutenberg, т.е. не установленным как плагин)

Я считаю, что это довольно критическая ошибка.

Я исправил свой сайт следующим образом.

1. не изменять post_modified_gmt, если действие REQUEST_META_BOX_UPDATES

add_filter( 'wp_insert_post_data', function ( $data ) {
    if ( isset( $_GET['meta-box-loader'] ) ) {
        unset( $data["post_modified"] );
        unset( $data["post_modified_gmt"] );
    }

    return $data;
} );

или же

1. установить post_modified_gmt автосохранения = post_modified_gmt исходного сообщения +1 сек

add_action( 'save_post', function ( $post_id, $post ) {
    if ( isset( $_GET['meta-box-loader'] ) ) {
        $autosave = wp_get_post_autosave( $post_id, get_current_user_id() );
        if ( $autosave ) {
            $filter = function ( $data ) use ( &$filter, $post ) {
                remove_filter( 'wp_insert_post_data', $filter );
                $data["post_modified"]     = gmdate( 'Y-m-d H:i:s', strtotime( $post->post_modified ) + 1 );
                $data["post_modified_gmt"] = gmdate( 'Y-m-d H:i:s', strtotime( $post->post_modified_gmt ) + 1 );

                return $data;
            };
            add_filter( 'wp_insert_post_data', $filter );
            wp_update_post( $autosave );
        }
    }
}, 10, 2 );

Спасибо, что поделились своим решением, @ technote-space! Тем не менее, я не думаю, что это должно зависеть от нас, отдельных веб-хостов (подавляющее большинство из которых не являются программистами и просто хотят использовать работающий пользовательский интерфейс), чтобы исправлять известные ошибки в системе.

@ technote-space - спасибо за эти предложения. Я опробую их на некоторых своих сайтах и ​​посмотрю, работают ли они для меня.

@vesaraiskila - Я согласен с вами, что нам не нужно использовать изменения функций для устранения ошибок, но иногда может пройти много времени, прежде чем ошибки будут устранены. Так что для многих из нас полезно иметь временное решение. Если он работает, фильтр, который можно добавить в файл functions.php, представляет собой простое и легкое в реализации исправление, а также может предоставить полезную информацию для отладки, чтобы исправить базовый код.

@ technote-space - Я протестировал каждую из ваших функций на разных сайтах, на которых запущен Generate Press, и могу подтвердить, что это помогает решить проблему предварительного просмотра.

Один возможный сбой - на одном из моих сайтов я установил даты последнего изменения, которые будут отображаться в самом сообщении, а также привязан к виджету «Последние обновленные сообщения». Я обнаружил, что вариант №2 имел непреднамеренный побочный эффект добавления новой даты последнего изменения, даже если я не сохранял и не публиковал модификацию. (В этом случае, потому что я только тестировал). Я не обнаружил никаких проблем с использованием варианта №1, поэтому я буду придерживаться этого варианта на своих сайтах.

Я с нетерпением жду, чтобы эта проблема была решена в основном и объединена! Спасибо ребята!

Это «не настоящее превью» сильно отталкивает новых пользователей.

Я подозреваю, что многие отказались от Гутенберга, потому что они не считают эту простую и первую проверку редактирования работающей, и поэтому решили дождаться более поздней версии. Это портит весь проект.

Помните, когда впервые вышел Google Диск? Схожий недостаток был в том, что они автоматически «конвертировали» загруженные документы Word (и т. Д.) В Google Docs, и поэтому очень часто они выглядели ужасно. А если вы попытаетесь отредактировать документ Google вживую во время презентации собрания, даже курсор не останется в нужном месте.

Точно так же это было настоящим отказом для адаптации Google, все они исправлены. Надеюсь, что скоро эта основная проблема предварительного просмотра Gutenberg уйдет в прошлое.

Эта проблема возникает только в том случае, если сообщение опубликовано или на экране редактора страниц есть метабоксы. В моем случае плагин Yoast.
Переключитесь на Черновик на опубликованной странице, чтобы отобразить предварительный просмотр, но это не решение.

@ harmancheema93 вы тестировали это с последней версией плагина Gutenberg или с кандидатом на выпуск WordPress 5.2?

Исправление было объединено, но не будет выпущено в ядре WordPress до выхода 5.2 на следующей неделе.

Если это кому-то будет полезно, обновление до WordPress 5.2.1 устранило эту проблему для нас.

У нас все еще есть проблема, просто собираюсь добавить немного странную функцию переключения, которая включает и выключает контент, но короче говоря, предварительный просмотр не работает для опубликованных страниц с использованием расширенных настраиваемых полей, но работает для черновиков:

С помощью:

• Расширенные настраиваемые поля Pro 5.8.1
• WordPress 5.2.1

Шаги:

1. При нажатии на предварительный просмотр на опубликованной странице контент не отображается (контент находится в ACF, блоки по умолчанию WordPress не используются), верхний и нижний колонтитулы отображаются.
2. Повторное нажатие на предварительный просмотр приведет к переносу содержимого из ACF на этот раз, но без изменений содержимого.
3. Повторное нажатие на предварительный просмотр приведет к отображению страницы без содержания. Как будто он включает и выключает содержимое ACF.

Проверено, что URL такой же (? Preview_id = 27 & preview_nonce = abd991463b & preview = true) и есть.

Он отлично работает для страниц в черновом режиме.

Привет, @altescape , мне не удалось воспроизвести опубликованную страницу с использованием настраиваемого поля. Не могли бы вы создать для этого отдельную проблему, поскольку похоже, что проблема, с которой вы столкнулись, отличается от исходного отчета (и теперь эта проблема закрыта).

контент находится в ACF, блоки по умолчанию WordPress не используются

Я не уверен, что это означает, было бы хорошо, если бы вы могли добавить несколько дополнительных шагов о том, как вы создаете сообщение при создании отдельной проблемы.

Благодарю.

Это все еще происходит со мной, хотя не каждый раз, когда я редактирую опубликованный пост. Однако при выборе «Предварительный просмотр» во второй или третий раз была показана отредактированная версия.

@altescape Точно такая же проблема (тестировал ACF 5.8.1 и Wordpress 5.2.1). Вы нашли решение или где-то создали новую проблему? Я уже связался с разработчиками ACF, но они не смогли воспроизвести проблему (они сказали).

• Предварительный просмотр сохраняет ревизию, которая стирает все поля ACF (!), Поэтому, конечно же, будет отображаться пустая страница. Это видно по ревизиям страницы.
• Использование предварительного просмотра на неопубликованных сообщениях или страницах работает должным образом, просто если вы попытаетесь предварительно просмотреть уже опубликованную страницу, все поля ACF будут удалены.
• Автосохранение также удалит все содержимое полей ACF (!)

Я знаю, что эта проблема закрыта, но вполне может быть, что эти проблемы как-то связаны. Любая помощь приветствуется.

@kaij Привет,

Я открыл еще один выпуск https://github.com/WordPress/gutenberg/issues/16006 см. Мое описание там

Я исправил свой сайт следующим образом.

1. не изменять post_modified_gmt, если действие REQUEST_META_BOX_UPDATES

add_filter( 'wp_insert_post_data', function ( $data ) {
  if ( isset( $_GET['meta-box-loader'] ) ) {
      unset( $data["post_modified"] );
      unset( $data["post_modified_gmt"] );
  }

  return $data;
} );

или же

1. установить post_modified_gmt автосохранения = post_modified_gmt исходного сообщения +1 сек

add_action( 'save_post', function ( $post_id, $post ) {
  if ( isset( $_GET['meta-box-loader'] ) ) {
      $autosave = wp_get_post_autosave( $post_id, get_current_user_id() );
      if ( $autosave ) {
          $filter = function ( $data ) use ( &$filter, $post ) {
              remove_filter( 'wp_insert_post_data', $filter );
              $data["post_modified"]     = gmdate( 'Y-m-d H:i:s', strtotime( $post->post_modified ) + 1 );
              $data["post_modified_gmt"] = gmdate( 'Y-m-d H:i:s', strtotime( $post->post_modified_gmt ) + 1 );

              return $data;
          };
          add_filter( 'wp_insert_post_data', $filter );
          wp_update_post( $autosave );
      }
  }
}, 10, 2 );

Куда вы добавили код? потому что я пытаюсь вставить в свою тему functions.php, но ничего не произошло

@ Bt4ok - код был для более ранней версии Wordpress - проблема с превью постов и метабоксами, описанная в этой ветке, была решена довольно давно с обновлением Wordpress. Если у вас возникла проблема сейчас, вы должны сообщить об открытой новой проблеме. (Если вы заметили, эта тема была помечена как закрытая)

@ Bt4ok - код был для более ранней версии Wordpress - проблема с превью постов и метабоксами, описанная в этой ветке, была решена довольно давно с обновлением Wordpress. Если у вас возникла проблема сейчас, вы должны сообщить об открытой новой проблеме. (Если вы заметили, эта тема была помечена как закрытая)

Да еще есть проблема
Очистить установку wp 5.3.2
Встроенный Гутенберг
ACF 5.8.7

Проблема все еще присутствует
Нет предварительных обновлений изменений в расширенных формах настраиваемых полей, если сообщение опубликовано.
Пытался установить gutenberg как плагин - та же проблема.
Также на странице предварительного просмотра времени появляются пустые поля. 1click -preview - поля пустые, 2-й клик - заполненные (сохраненная версия поста без изменений), 3-е пустые, 4-е - заполненные (без изменений).
Проверено на встроенной теме двадцать.

Может потребоваться откат на предыдущую версию wp или acf?

Эта проблема с предварительным просмотром была решена для меня несколько месяцев назад, но недавно я столкнулся с этим:

Автосохранение заставляет окно предварительного просмотра обновляться постоянно и часто, что действительно расстраивает, когда вы читаете текст, чтобы увидеть, все ли в порядке. После каждого обновления страница возвращается наверх, и нужно вернуться к тому месту, которое вы читали.

https://github.com/WordPress/gutenberg/issues/12617#issuecomment -569045110

Спасибо. Проблема была решена откатом на версию wp 5.0 core. Предварительный просмотр работает должным образом для черновиков и опубликованных сообщений (включая изменения в полях ACF), но поля ACF автоматически сохраняются, когда я нажимаю кнопку «Предварительный просмотр».

На всякий случай: постоянная перезагрузка окна предварительного просмотра без каких-либо модификаций "работает должным образом"? Это действительно затрудняет концентрированное чтение.

У меня не очень хороший английский, извините.
Я имею в виду. Откатился на wp 5.0. Зашел на страницу редактирования поста, внес изменения в поля acf или в раздел контента. Нажмите "превью" и посмотрите все внесенные изменения! Неважно опубликован пост или черновик.

Проблема только в том, что если внести какие-то изменения в поля acf и нажать "предварительный просмотр" - после нажатия кнопки я получаю обновленный (сохраненный) пост с моими последними изменениями в формах acf. Изменения в содержании представлены в режиме «предварительного просмотра», но не сохраняются, пока я не нажму «обновить».

Например. Открыть сообщение для редактирования -> внести некоторые изменения в поля ACF и опубликовать контент (или заголовок и т. Д.), Нажмите предварительный просмотр - я вижу все изменения (acf + контент). Закройте страницу редактирования сообщения, не нажимая кнопку обновления, но получите сообщение новой версии со старым содержимым и измененным acf. Если не закрыть страницу редактирования публикации без сохранения и нажать кнопку обновления, получите обновленную запись со всеми изменениями в acf и контенте.

Надеюсь, мой ответ понятен

Я исправил свой сайт следующим образом.

1. не изменять post_modified_gmt, если действие REQUEST_META_BOX_UPDATES

add_filter( 'wp_insert_post_data', function ( $data ) {
    if ( isset( $_GET['meta-box-loader'] ) ) {
        unset( $data["post_modified"] );
        unset( $data["post_modified_gmt"] );
    }

    return $data;
} );

или же

1. установить post_modified_gmt автосохранения = post_modified_gmt исходного сообщения +1 сек

add_action( 'save_post', function ( $post_id, $post ) {
    if ( isset( $_GET['meta-box-loader'] ) ) {
        $autosave = wp_get_post_autosave( $post_id, get_current_user_id() );
        if ( $autosave ) {
            $filter = function ( $data ) use ( &$filter, $post ) {
                remove_filter( 'wp_insert_post_data', $filter );
                $data["post_modified"]     = gmdate( 'Y-m-d H:i:s', strtotime( $post->post_modified ) + 1 );
                $data["post_modified_gmt"] = gmdate( 'Y-m-d H:i:s', strtotime( $post->post_modified_gmt ) + 1 );

                return $data;
            };
            add_filter( 'wp_insert_post_data', $filter );
            wp_update_post( $autosave );
        }
    }
}, 10, 2 );

Куда вы добавили код? потому что я пытаюсь вставить в свою тему functions.php, но ничего не произошло

У меня такой же вопрос