Forum Replies Created

Viewing 15 replies - 1 through 15 (of 61 total)
  • Forum: Fixing WordPress
    In reply to: Updates time out
    Thread Starter gregscott

    (@gregscott)

    …or there could be some ugly browser cache things going on. I just looked at it from a different device. A few hours ago, the installed X theme was 10.6.3, with 10.6.4 ready to install. No matter what I tried, I could never get it to tell me that it updated to 10.6.4. But now, from this different device, I see the installed X theme is 10.6.4.

    Maybe it performs updates as expected but never gets back to the browser client, making me think it never applied the update. Maybe that’s what’s going on. Maybe the timeout is between the site and the browser after the update finishes.

    I’m on Chrome as I compose this comment with that website open in another tab. I was on Firefox earlier.

    I’ll wait for the next plugin update and see what happens.

    Forum: Fixing WordPress
    In reply to: Updates time out
    Thread Starter gregscott

    (@gregscott)

    Thanks – but it’s not just X theme updates. It’s all plugin and theme updates. All updates to everything from the WordPress dashboard act badly. An X theme update was waiting this morning, but others act the same way.

    Thread Starter gregscott

    (@gregscott)

    @steven – thanks – looks like “mysql_upgrade” did the trick.

    • Greg
    Thread Starter gregscott

    (@gregscott)

    Thanks @samuel. I am pretty much the hosting team. Looking at the error messages, it seems that the database is set up differently than WordPress expects. The only database work on any of these sites came from initial setup years ago and automated WordPress upgrades. The log files exploded after the latest upgrade to 6.6.1. Surely we can find better guidance than just “repair the database.” Repair it how?

    Thread Starter gregscott

    (@gregscott)

    Thanks – that will work around my disk space issue, but how do we attack the error at the root of the problem?

    Thread Starter gregscott

    (@gregscott)

    Long story short – the problem was a Divi theme bug with Divi 4.14.3. Other people had similar problems. The 4.14.4 update fixed it.

    I checked my backups and found I updated to Divi 4.14.3 on Dec. 16 2021 at 8:49 PM. My website logs show the problem started at 20:54:02, or roughly 5 minutes later. After I learned how to reproduce the problem at will, the problem stopped immediately after I updated to Divi 4.14.4. For an attacker to introduce something malicious, they would need to do it within 5 minutes of my update, and dated the offending file the exact same as all the other files in the themes/Divi directory tree.

    I posted this in a Facebook group named “Divi Theme Users” and before the admins of that group deleted my post, several people commented they had similar problems with Divi 4.14.3.

    So this one turned out to be a theme thing.

    Thread Starter gregscott

    (@gregscott)

    Maybe I fixed it. Details below.

    I found a way to reproduce the problem at will – in a browser window, go to blog –> Phishy emnails. In another terminal window, do tail -f /etc/httpd/logs/access_log

    Every time I clicked on “Phishy emails”, my tail -f went nuts with zillions of

    fe80::65dc:5d0e:b7eb:47ae%ens3 - - [18/Dec/2021:18:18:28 -0600] "GET /category/phishy-emails/ HTTP/1.1" 200 27106 "https://www.dgregscott.com/category/phishy-emails/" "WordPress/5.8.2; https://www.dgregscott.com"
    fe80::65dc:5d0e:b7eb:47ae%ens3 - - [18/Dec/2021:18:18:34 -0600] "GET /wp-content/uploads/2021/11/KamalaBackdoorSpam-1024x924.png HTTP/1.1" 200 269366 "https://www.dgregscott.com/wp-content/uploads/2021/11/KamalaBackdoorSpam-1024x924.png" "WordPress/5.8.2; https://www.dgregscott.com"
    

    In a third window, I did
    systemctl restart httpd.service
    and the machine-gunned log entries stopped.

    With more testing, I found I could reproduce the problem by clicking on **any** blog post in the “Phishy emails” category.

    Clicking other posts and pages did not trigger the behavior; just “Phishy email” posts or the category.

    Maybe somebody injected a malicious .htaccess or other config file? I didn’t see any.

    And then I noticed a brand new pending update. It was the Divi theme, updating from 4.14.3 to 4.14.4. I applied the update and the problem stopped.

    So…

    looks like it was either a Divi theme bug or somebody inserted something hostile into the theme directory. I also updated Divi a few days ago, so it could be either. I’ll keep an eye on it for a while.

    Thread Starter gregscott

    (@gregscott)

    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 7 years, 2 months ago by gregscott.
    Thread Starter gregscott

    (@gregscott)

    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 http://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>
    
    Thread Starter gregscott

    (@gregscott)

    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.

    Thread Starter gregscott

    (@gregscott)

    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

    Thread Starter gregscott

    (@gregscott)

    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)

    Thread Starter gregscott

    (@gregscott)

    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.

    Thread Starter gregscott

    (@gregscott)

    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.

    Thread Starter gregscott

    (@gregscott)

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

    REST API availability The REST API is available.

Viewing 15 replies - 1 through 15 (of 61 total)