Another “This block has encountered an error and cannot be previewed.”

This may be a plugin or theme conflict. Please attempt to disable all plugins, and switch to the default Twenty Nineteen theme. If the problem goes away, enable them one by one to identify the source of the problem.

If you can install plugins, install Health Check. On the troubleshooting tab, you can click the button to disable all plugins and change the theme for you, while you’re still logged in, without affecting normal visitors to your site.

Thanks James. But no joy. I installed the Health Check plugin and then went into troubleshooting mode. No change in symptoms while in troubleshooting mode. Trying to edit any classic block still shows the same error. Other blocks work just fine.

Another difference between the problem site and the working one. The problem site is a network WordPress installation while the working one is just one single website.

In Health Check’s main health readout, on the plugin’s main page in your Dashboard, what does it say about the REST API?

I’m missing something. I see the normal list of plugins. When I click “Troubleshoot” on the Health Check plugin, I see this text at the top of the window:

*************
Health Check — Troubleshooting Mode
Your site is currently in Troubleshooting Mode. This has no effect on your site visitors, they will continue to view your site as usual, but for you it will look as if you had just installed WordPress for the first time.

Here you can enable individual plugins or themes, helping you to find out what might be causing strange behaviors on your site. Do note that any changes you make to settings will be kept when you disable Troubleshooting Mode.

Notices
Plugin actions, such as activating and deactivating, are not available while in Troubleshooting Mode.
****************

And then there’s a button that says “Disable Troubleshooting Mode.” And that’s it.

Did I install the wrong plugin? Its full title is “Health Check and Troubleshooting” but the WordPress community. When I view details, I see it’s at version 1.26.

Not in Troubleshooting Mode, just at Dashboard > Health Check in your site’s Dashboard, /wp-admin/index.php?page=health-check

One of the items there is “REST API availability.” What does it say for your site?

Oh – sorry – there it is. Thanks. Pasting in the REST API availability line:

REST API availability The REST API is available.

Is this significant? I’m running a current version of Red Hat Fedora, and so I update WordPress via Red Hat updates instead of direct from WordPress.

PHP Extensions
The optional module, bcmath, is not installer, or has been disabled.
The optional module, libsodium, is not installer, or has been disabled.
The optional module, imagick, is not installer, or has been disabled.

Hmmm…

I just installed the healthcheck plugin on my known good website. The last line of the Dashboard…Healthckeck report looks like:

Loopback request The loopback request to your site completed successfully.

But on the problem website, the last line looks like:

Loopback request The loopback request returned an unexpected status code, 403, this may affect tools such as WP_Cron, or theme and plugin editors.

This feels like it might be important.

Yep, that’s a problem. If you have any security plugins, see if deactivating them makes a difference.

If not, check for differences in server-side security between both environments.

Something is bit too secure. ??

Well this is ugly. Digging deeper into that Healthcheck plugin, when I look at the troubleshooting tab and check file integrity, I see a boatload of files missing or changed.

I’m using the Red Hat WordPress RPM that goes with Fedora instead of the download direct from WordPress. I wonder if the Red Hat WordPress updates have a problem.

On my good website, the file integrity check works without error.

/usr/share/wordpress/readme.html File not found
/usr/share/wordpress/license.txt File not found
/usr/share/wordpress/wp-includes/SimplePie/Parser.php File not found
/usr/share/wordpress/wp-includes/SimplePie/Sanitize.php File not found
/usr/share/wordpress/wp-includes/SimplePie/Core.php File not found
/usr/share/wordpress/wp-includes/SimplePie/Decode/HTML/Entities.php File not found
/usr/share/wordpress/wp-includes/SimplePie/Category.php File not found
/usr/share/wordpress/wp-includes/SimplePie/gzdecode.php File not found
/usr/share/wordpress/wp-includes/SimplePie/Locator.php File not found
/usr/share/wordpress/wp-includes/SimplePie/Parse/Date.php File not found
/usr/share/wordpress/wp-includes/SimplePie/Author.php File not found
/usr/share/wordpress/wp-includes/SimplePie/Cache.php File not found
/usr/share/wordpress/wp-includes/SimplePie/IRI.php File not found
/usr/share/wordpress/wp-includes/SimplePie/Credit.php File not found
/usr/share/wordpress/wp-includes/SimplePie/Content/Type/Sniffer.php File not found
/usr/share/wordpress/wp-includes/SimplePie/Restriction.php File not found
/usr/share/wordpress/wp-includes/SimplePie/Item.php File not found
/usr/share/wordpress/wp-includes/SimplePie/XML/Declaration/Parser.php File not found
/usr/share/wordpress/wp-includes/SimplePie/Cache/Base.php File not found
/usr/share/wordpress/wp-includes/SimplePie/Cache/MySQL.php File not found
/usr/share/wordpress/wp-includes/SimplePie/Cache/Memcache.php File not found
/usr/share/wordpress/wp-includes/SimplePie/Cache/DB.php File not found
/usr/share/wordpress/wp-includes/SimplePie/Cache/File.php File not found
/usr/share/wordpress/wp-includes/SimplePie/Source.php File not found
/usr/share/wordpress/wp-includes/SimplePie/Registry.php File not found
/usr/share/wordpress/wp-includes/SimplePie/Rating.php File not found
/usr/share/wordpress/wp-includes/SimplePie/Copyright.php File not found
/usr/share/wordpress/wp-includes/SimplePie/Exception.php File not found
/usr/share/wordpress/wp-includes/SimplePie/Misc.php File not found
/usr/share/wordpress/wp-includes/SimplePie/Caption.php File not found
/usr/share/wordpress/wp-includes/SimplePie/Net/IPv6.php File not found
/usr/share/wordpress/wp-includes/SimplePie/File.php File not found
/usr/share/wordpress/wp-includes/SimplePie/HTTP/Parser.php File not found
/usr/share/wordpress/wp-includes/SimplePie/Enclosure.php File not found
/usr/share/wordpress/wp-includes/class-smtp.php Content changed (View Diff)
/usr/share/wordpress/wp-includes/class-simplepie.php Content changed (View Diff)
/usr/share/wordpress/wp-includes/script-loader.php Content changed (View Diff)
/usr/share/wordpress/wp-includes/certificates/ca-bundle.crt Content changed (View Diff)
/usr/share/wordpress/wp-includes/ID3/module.tag.lyrics3.php File not found
/usr/share/wordpress/wp-includes/ID3/module.audio.dts.php File not found
/usr/share/wordpress/wp-includes/ID3/module.tag.id3v1.php File not found
/usr/share/wordpress/wp-includes/ID3/module.audio.flac.php File not found
/usr/share/wordpress/wp-includes/ID3/module.audio.mp3.php File not found
/usr/share/wordpress/wp-includes/ID3/module.audio-video.matroska.php File not found
/usr/share/wordpress/wp-includes/ID3/module.audio-video.quicktime.php File not found
/usr/share/wordpress/wp-includes/ID3/module.tag.apetag.php File not found
/usr/share/wordpress/wp-includes/ID3/getid3.lib.php File not found
/usr/share/wordpress/wp-includes/ID3/license.commercial.txt File not found
/usr/share/wordpress/wp-includes/ID3/module.audio.ac3.php File not found
/usr/share/wordpress/wp-includes/ID3/getid3.php File not found
/usr/share/wordpress/wp-includes/ID3/license.txt File not found
/usr/share/wordpress/wp-includes/ID3/module.audio-video.flv.php File not found
/usr/share/wordpress/wp-includes/ID3/readme.txt File not found
/usr/share/wordpress/wp-includes/ID3/module.tag.id3v2.php File not found
/usr/share/wordpress/wp-includes/ID3/module.audio.ogg.php File not found
/usr/share/wordpress/wp-includes/ID3/module.audio-video.riff.php File not found
/usr/share/wordpress/wp-includes/ID3/module.audio-video.asf.php File not found
/usr/share/wordpress/wp-includes/update.php Content changed (View Diff)
/usr/share/wordpress/wp-includes/load.php Content changed (View Diff)
/usr/share/wordpress/wp-includes/js/tinymce/wp-tinymce.js File not found
/usr/share/wordpress/wp-includes/js/tinymce/plugins/media/plugin.min.js Content changed (View Diff)
/usr/share/wordpress/wp-includes/js/tinymce/plugins/media/plugin.js Content changed (View Diff)
/usr/share/wordpress/wp-includes/js/mediaelement/mediaelement-and-player.js Content changed (View Diff)
/usr/share/wordpress/wp-includes/js/mediaelement/mediaelement.min.js Content changed (View Diff)
/usr/share/wordpress/wp-includes/js/mediaelement/mediaelement.js Content changed (View Diff)
/usr/share/wordpress/wp-includes/js/mediaelement/mediaelement-and-player.min.js Content changed (View Diff)
/usr/share/wordpress/wp-includes/js/swfupload/handlers.js File not found
/usr/share/wordpress/wp-includes/js/swfupload/handlers.min.js File not found
/usr/share/wordpress/wp-includes/js/swfupload/license.txt File not found
/usr/share/wordpress/wp-includes/js/swfupload/swfupload.js File not found
/usr/share/wordpress/wp-includes/class-phpmailer.php Content changed (View Diff)
/usr/share/wordpress/wp-admin/includes/admin-filters.php Content changed (View Diff)
/usr/share/wordpress/wp-admin/includes/media.php Content changed (View Diff)
/usr/share/wordpress/wp-admin/includes/update.php Content changed (View Diff)
/usr/share/wordpress/wp-admin/includes/class-core-upgrader.php Content changed (View Diff)
/usr/share/wordpress/wp-admin/includes/class-wp-automatic-updater.php Content changed (View Diff)

Since this looks like it might be a Fedora packaging problem, I filed a bug with Red Hat. Here is a link:

https://bugzilla.redhat.com/show_bug.cgi?id=1693902

Oh – yes – I figured out what was going on with that loopback behavior. It was a configuration thing, not a plugin, and a dead-end for the block problem. This was the root cause, in /etc/httpd/conf.d/dgregscott.conf

<Directory /usr/share/wordpress/wp-admin>
##  AllowOverride Options
  AllowOverride All
  <IfModule mod_authz_core.c>
    # Apache 2.4
    ##Require local
    Require ip 10.10.10
    ##Require all granted
  </IfModule>
  <IfModule !mod_authz_core.c>
    # Apache 2.2
    Order Deny,Allow
    Deny from All
    Allow from 127.0.0.1
    Allow from ::1
    Allow from 10.10.10
  </IfModule>
  <Files "admin-ajax.php">
    <IfModule mod_authz_core.c>
      # Apache 2.4
      Require all granted
    </IfModule>
    <IfModule !mod_authz_core.c>
      # Apache 2.2
      Order Deny,Allow
      Allow from All
    </IfModule>
  </Files>
</Directory>

I don’t want anyone from the outside world touching my wp-admin directory. When I temporarily changed it to:

    ##Require ip 10.10.10
    Require all granted

The loopback worked just fine, but the original problem didn’t change.

More on the loopback thing, which is a distraction from the original problem, but might be useful if anyone else sees the behavior.

The VM hosting my website has a private IP Address and it’s NATed behind my firewall. I’ll bet that loopback test tries to touch https://www.dgregscott.com, which translates to a public IP Address. And so the loopback goes out to the firewall and right back in again. But my config file doesn’t have anything granting the public IP Address. As I write this up, it occurs to me, this should be easy to fix.

Yup – now that loopback test works just fine. Here’s what the wp-admin section of my conf file looks like now.

<Directory /usr/share/wordpress/wp-admin>
##  AllowOverride Options
  AllowOverride All
  <IfModule mod_authz_core.c>
    # Apache 2.4
    ##Require local
    Require ip 10.10.10
    Require ip 216.160.2.133
    ##Require all granted
  </IfModule>
  <IfModule !mod_authz_core.c>
    # Apache 2.2
    Order Deny,Allow
    Deny from All
    Allow from 127.0.0.1
    Allow from ::1
    Allow from 10.10.10
    Allow from 216.160.2.133
  </IfModule>
  <Files "admin-ajax.php">
    <IfModule mod_authz_core.c>
      # Apache 2.4
      Require all granted
    </IfModule>
    <IfModule !mod_authz_core.c>
      # Apache 2.2
      Order Deny,Allow
      Allow from All
    </IfModule>
  </Files>
</Directory>

Resolved the original problem. That health check plugin is a nice tool. It led to the solution. Thanks James!

But first, a little more on the loopback thing. I don’t like hard-coding my public IP Address in my config file. One more thing to remember if I ever change IP Addresses. Right now, the key line is

require ip [public IP address]

I have a hunch there’s a way to use a Require line with a DNS name instead of IP Address. I’ll need to look in the apache documentation and find it.

And on the original problem, it was a Fedora RPM packaging issue. The cure was to upgrade from the wordpress-5.1.1-1.fc29.noarch RPM to wordpress-5.1.1-4.fc29.noarch.

Those files were missing or modified in the health check because they don’t comply with Fedora packaging guidelines.

I’ll paste in the overnight bugzilla commments with more detail.

*******************

> The file integrity report should run cleanly.

No, the file are patched or removed to comply to Fedora Packaging Guildelines

> Whenever I try to edit a Classic block with my problem website, the block displays an error message, “This block has encountered an error and cannot be previewed.”

See a duplicate of bug #1691524

Please try 5.1.1-4 from updates-testing

Private Comment 2 Greg Scott 2019-03-29 06:22:46 UTC
Wow.

Before upgrading:

[root@dgregscott2019 ~]# rpm -qa | grep wordpress
wordpress-5.1.1-1.fc29.noarch

After upgrading:

[root@dgregscott2019 ~]# rpm -qa | grep wordpress
wordpress-5.1.1-4.fc29.noarch
[root@dgregscott2019 ~]#

And now I can edit a classic block!

Private Comment 3 Remi Collet 2019-03-29 06:46:07 UTC
Feel free to give karma on
https://bodhi.fedoraproject.org/updates/FEDORA-2019-4825f7896c

Status: NEW → CLOSED
Resolution: — → ERRATA
Last Closed: 2019-03-29 06:46:07
Private Comment 4 Greg Scott 2019-03-29 11:28:03 UTC
May I ask one more question?
> No, the file are patched or removed to comply to Fedora Packaging Guildelines

How did they not comply? Is there a way to feed that info back to the WordPress community so they can make appropriate changes?

*******************

Here’s a link to the Red Hat bugzilla entry with the fix:
https://bugzilla.redhat.com/show_bug.cgi?id=1691524

And a link to the errata with how to install the update, at least until it makes its way into the normal Fedora update stream:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-4825f7896c

And how to apply the update:
sudo dnf upgrade –enablerepo=updates-testing –advisory=FEDORA-2019-4825f7896c

thanks

– Greg

• This reply was modified 5 years, 11 months ago by gregscott.