regexaurus

Thank you, Darin! That works well for us.

Thank you much. Very helpful! ??

• This reply was modified 1 year, 9 months ago by regexaurus.

The production site has a .git directory in site root. The staging site has a .git file in site root which contains a single line:

gitdir: /path/to/subdirectory/of/.git/on/production/site

Sorry for my even slower response.
Yes, there is a .git directory in site root. It appears to be created and used by DreamPress one-click staging, which I enabled for the site some time ago.
There are no .git, .svn, .hg, or .bzr directories in wp-content, wp-content/plugins, or wp-content/themes.

@anthoniusalfred I did a Force updates as requested, and saw a message, “Force update checks have been initialized”, but as I had before I tried forcing updates, I still have 4 plugins that all indicate, “There is a new version of plugin name available.”

I installed WP Crontrol to see if it would show anything possibly useful/helpful. All appears normal as best as I can tell, and a web search seems to suggest MPSUM_Disable_Updates->maybe_auto_update() is specific to Easy Updates Manager.

Yes, I had added this job in crontab:

*/20 * * * * cd /home/username/siteroot; wp cron event run –due-now > /dev/null 2>&1

But automatic updates haven’t been working. I took your suggestion and switched to calling wp-cron.php instead (using curl instead of wget):

*/20 * * * * curl https://www.example.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1

The website is hosted on DreamPress. I was reviewing access.log and happened to notice entries like this:

[02/Feb/2023:07:00:02 -0800] "GET /wp-cron.php?doing_wp_cron HTTP/1.1" 200 242 "-" "DreamPress wp-cron/1.0"

These entries appear every 15 minutes. Looking into this, I found this DreamHost/DreamPress Knowledgebase article: Disabling WP-CRON to Improve Overall Site Performance And from that article:

I’m also seeing access.log entries corresponding to my crontab job for curl / wp-cron.php. But automatic updates are still not working…

• This reply was modified 1 year, 9 months ago by regexaurus.

Right, so I had already followed that down to the success message, but the trouble is with removing the A (host) record for website/domain and creating a CNAME record for that domain, that points to the Cloudfront distribution domain. When a website is created on DreamHost shared hosting, the A record is automatically created and it can’t be deleted directly (only by removing hosting for the website/domain). DreamHost prevents creation of a CNAME with the same hostname as an existing A record…and I doubt that would work well or as desired, if I could create a CNAME record with the same hostname as an existing A record. I can create an ALIAS record, but that doesn’t work as desired. Then there is the trouble of creating an alternative hostname (as described in the FAQ) and pointing it at the same IP address as the main/original A record for the website/domain. Since this is for a DreamHost shared hosting environment, where is traffic to that IP going to be routed? I don’t think DreamHost shared hosting uses a dedicated IP per website/domain…? ?????♂? If that’s correct, they’re probably using name hints to determine how to route web traffic and the alternative hostname A record simply wouldn’t work…?

Hi Marko,

I’m a little confused by point 1, where you indicate the CDN needs to be purged after converting images, so that webp images can replace the existing images. After purging the CDN, will the CDN also pull jpg/jpeg/png images as needed, for browsers that don’t support webp?

Thank you!

According to DreamHost support, the problem appears to be with Wordfence. DreamHost support responded with, “…it seems as if our servers cannot reach WordFence’s cloud host as the connection dies at the boarder. A traceroute to noc4.wordfence.com dies at their boarder and a trace back to us dies as well. From what we have determined, the issue seems to be with WordFence and not us…”
Presumably, boarder == router ??

I cleaned up / fixed a bug in my first script above and posted to Pastebin (more legible there).

One approach to keeping your Google Drive backups (more) secure in the event your web site is hacked:

1. Share the UpdraftPlus folder with a second Google account. View access is fine. If you want to remove the source files after copying to the second account, grant edit access.
2. On your second Google account, create an unshared folder (e.g. UpdraftPlusCopy).
3. On your second Google account, go to script.google.com. Copy/paste the following (I renamed myFunction to CopyNewFiles) and replace the [bogus] folder IDs with the folder IDs for your source/destination folders:
   function CopyNewFiles() {
   var SourceFolder = DriveApp.getFolderById(‘JMtgsgM9sY9Fe5Z7wCbb4YVVqfeZiZ’);
   var SourceFiles = DriveApp.getFolderById(‘JMtgsgM9sY9Fe5Z7wCbb4YVVqfeZiZ’).getFiles();
   var DestFolder = DriveApp.getFolderById(‘SFGXwgvX6DmkAvPrrnWC2KY3imy7s2’);
   var DestFiles = DriveApp.getFolderById(‘SFGXwgvX6DmkAvPrrnWC2KY3imy7s2’).getFiles();
   var NotInDest = true;
   while (SourceFiles.hasNext()) {
   SourceFile = SourceFiles.next();
   while (DestFiles.hasNext()) {
   DestFile = DestFiles.next();
   if (SourceFile.getName() === DestFile.getName()) {
   NotInDest = false;
   }
   }
   if (NotInDest) {
   SourceFile.makeCopy(SourceFile.getName(), DestFolder);
   NotInDest = true;
   }
   DestFiles = DriveApp.getFolderById(‘SFGXwgvX6DmkAvPrrnWC2KY3imy7s2’).getFiles();
   }
   }
4. Optionally, rename the project. Save it (Ctrl+S) works and click the Run button.
   The first time you run it, you should be prompted to grant the script access to manage your (second Google account) Drive.

The script above will copy all files from SourceFolder to DestFolder that don’t already exist (identically-named file) exist in the DestFolder. If you are concerned about storage limits/cost, you could update the script to remove the original file after copying (example below). With that approach, you can remove/comment the code that checks for identically-named files in DestFolder, since that should never be the case if you remove the original file in SourceFolder. To do a restore from the UpdraftPlus plugin, you would need to copy/move the backup files back to the UpdraftPlus folder on the first Google account.

function CopyNewFiles() {
var SourceFolder = DriveApp.getFolderById(‘JMtgsgM9sY9Fe5Z7wCbb4YVVqfeZiZ’);
var SourceFiles = DriveApp.getFolderById(‘JMtgsgM9sY9Fe5Z7wCbb4YVVqfeZiZ’).getFiles();
var DestFolder = DriveApp.getFolderById(‘SFGXwgvX6DmkAvPrrnWC2KY3imy7s2’);
while (SourceFiles.hasNext()) {
SourceFile = SourceFiles.next();
SourceFile.makeCopy(SourceFile.getName(), DestFolder);
SourceFolder.removeFile(SourceFile);
}
}

For Google Drive, if you’re a G Suite customer, consider using Vault (if available for your account) for additional protection in the event your web site is hacked and your Google Drive backups deleted.
I think another possibility is to share the UpdraftPlus folder with another Google user, and in the second account’s Drive, regularly copy the contents of the shared folder to a different folder only accessible to the second account/user. You could probably automate the copying with a Google Script and trigger (e.g. daily). I will test this and try to come up with a simple script.

@dnutbourne, I joined the Group as suggested (and left the Group shortly thereafter, as recommended). When I went to UpdraftPlus settings to redo authentication/authorization for the web app to access my Drive, I noticed the “Google Drive: Account is not authorized” message had disappeared. Out of curiosity, I checked my UpdraftPlus folder, and it contained backup files from last evening (6/4/2017)! UpdraftPlus is configured for daily backup…
I will keep an eye on this to see if backup files continue to transfer to my Drive. I guess this is tentatively resolved. Seems like the experience could be smoother, but maybe this is related to Google tightening the OAuth screws, since the recent phishing scam targeting OAuth authorization…?

Thank you!