File change showing whole file path

That’s pretty curious. What error message or error code are you seeing when attempting to exclude the path?

What are the most recent changes?

In addition to atxmatt’s questions:

But recently, I’ve been getting file change notifications showing a long file path.

Are those long-filepath-file-changes limited to backupbuddy temp files, or is the same happening for any file changes (from any location)?

Based on the info provided so far it looks like the exclusion is not working properly due to some path issue.

I know there are path issues when running a File Change scan on a Windows platform. But those are generic and not specific for an excluded path. The symptom there is that file changes are reported twice in the email. If I recall correctly it reports the correct wp-content/…(relative path) entry as well as one with an absolute path. Let me check whether that is still the case on a Windows platform and I’ll get back to you.

• This reply was modified 2 years, 8 months ago by nlpro.

It’s only happening with the backupbuddy temp files.

The error I received when adding the path is:
A validation function for file-change received data that has an entry for notify_admin when no such entry exists.

However, I found that it adds it anyway. But it doesn’t stop the file change notifications, it’s still reporting file changes from that path.

No major changes other than plugin (8) and theme (3) updates in the past month. This site doesn’t get touched much other than keeping things updated.

It’s hosted on Siteground using Linux.

The error indicates an old and deprecated file change (boolean) setting (notify_admin) still exists. Something must have gone wrong when updating the plugin in the past (perhaps even an upgrade bug).

If not already add the line below to the wp-config.php file:

define('ITSEC_DEBUG', true);

This should add an extra Debug menu item under the Security menu option.

Then navigate to Security > Debug.

Under the Settings section select file-change and then click on the Load button.

There should be 5 entries displayed which more or less look like below (Data types: 2 arrays, 1 object, 1 integer and a boolean):

{
"file_list": [],
"types": [],
"expected_hashes": {},
"last_scan": 0,
"compare_file_hashes": true
}

For visual aid I’ve intentionally left out (full) values for the first 3 entries.

If, by any chance there is a “notify_admin” entry (or any other unmatching) entries, try and remove those “entry”: value, combinations. Once removed click on the Save button.

Do the above at your own risk (preferably after making sure there is a recent database backup available).

• This reply was modified 2 years, 8 months ago by nlpro.

It’s showing these between “last scan” and “compare_file_hashes”

“notify_admin”: false,
“show_warning”: false,
“email”: true,
“split”: false,
“last_run”: 1522286373,
“last_chunk”: false,
“method”: “exclude”,

Should I delete all of these?

Yes, none of those (deprecated) settings are valid in the current plugin release (8.0.2). Since these are no longer used they are save to remove/delete.

Okay thanks. Is there a way to force it to do the check so I can see if it’s working now or do I have to wait until next time it runs?

Since the 8.0.x release a button to manually start a new File Change scan no longer exists.

However you can manually force the currently scheduled File Change scan to start by clicking on the Run button behind the file-change cron task as displayed in the Scheduler section of the Debug page.

You can check whether there is currently a File Change scan running by clicking on the Data header column. This will display some extra info only for the file-change cron task.

Usually when the file-change cron task is waiting to run the Data column shows the info as seen below:

Array
    step         => get-files
    chunk        => admin
    loop_start   => [integer] 1646850849
    loop_item    => [integer] 1

The file-change cron task scheduled time also gives you an indication.

One last thing about the excluded path. There is no point in specifying an absolute path. Simply use:

/wp-content/uploads/pb_backupbuddy

That should normally work fine ??

Thanks for the detailed info!

As for the path – that’s how this all started. I was using the path you posted and it worked fine, but suddenly I was getting notifications showing changed files in the long path.

I sent through the steps you provided and removed the stuff that didn’t belong. But I’m still receiving notifications that files have changed at the absolute path.

That is pretty much as expected.

My previous instructions only targeted the error you were getting when attempting to save the File Change settings. A sub issue that IMHO is unrelated to the main issue as reported in this topic. Correct me if I’m wrong, but that sub issue has now been resolved.

Also I think the main problem is not the fact that there is an absolute path reported in the File Change email. The main issue is that there are file changes reported from an excluded path. So it appears the File Change scan is not skipping the excluded path from scanning as it should. The fact that it also reports an absolute path in the email (where it should normally show a relative path) may be a clue as to what’s going wrong.

As we speak, I’m having a closer look at the File Change scanner code for the uploads chunk.

In the meantime if you could try and log into the database using a tool like phpMyAdmin (or something similar) and then check the value stored for the _site_transient_itsec_wp_upload_dir option in the wp_options table, that would be great.

It’s an array value containing multiple paths, the one relevant for the File Change scanner is basedir. The array value is basically the result of the WordPress Core wp_upload_dir() function.

Ah okay, I forgot about that error. I think that is resolved.

Here’s what I found in the db –
a:6:{s:4:”path”;s:89:”/home/u423-d32u2skuq3kn/www/impactaccountingmn.com/public_html/wp-content/uploads/2022/03″;s:3:”url”;s:61:”https://www.impactaccountingmn.com/wp-content/uploads/2022/03″;s:6:”subdir”;s:8:”/2022/03″;s:7:”basedir”;s:81:”/home/u423-d32u2skuq3kn/www/impactaccountingmn.com/public_html/wp-content/uploads”;s:7:”baseurl”;s:53:”https://www.impactaccountingmn.com/wp-content/uploads”;s:5:”error”;b:0;}

Ok, the content of your _site_transient_itsec_wp_upload_dir option (actually it’s a transient) looks good.

I’ve been quiet for a while, because I’ve been thinking ??
And my thinking eventually resulted in an idea. So I’ve been analyzing the file change code and I’ve studied the current (Process) File Change log entries. Unfortunately these existing log entries do not help, because there is nothing being logged about excludes.

So my idea is, wouldn’t it be great when the Process log entry for the File Change uploads chunk includes info about what (absolute path) folders are (or are not) excluded during the uploads folder scan ? This would help enormously figuring out why certain folders don’t get excluded when they should.

Unfortunately my idea presented me with a problem from the start. I noticed in the code that the log entry is added before the actual processing of the uploads folder takes place. So the log entry cannot include information obtained during processing.

But despite this fundamental problem I did manage to find a way to add extra exclude info to the Process log entry for the File Change uploads chunk!

I’ve tested some custom code I’ve written for this purpose and guess what? It works!

Before sharing the custom code, we really need to have a look at the plugin Logs page. So navigate to the plugin Logs page and click on the Screen Options link in the upper right corner of the screen. Then make sure the “Show Process entries.” checkbox (under Advanced Entries for Support and Developers) is ticked and if needed to be ticked proceed with clicking on the Apply button. Otherwise you are already good to go.

At the top of the Logs page you’ll see a bunch of links for log entry event types like:

Important Events
All Events
Warnings
Notices
(Debug if enabled)
Process (We just enabled this one)

Click on the Process link.

And then select File Change in the module selector and click on the Filter button.

At this point we have all the File Change “Process” type log entries displayed.

Now a single File Change scan will produce 17 Process log entries (Pro). The possible values in the Type column are only three and in the order as displayed below:

Process Stop (1x)
…
Process Update (15x)
…
Process (1x)

The Process type entry is the start of the File Change scan. It’s also the only entry with a value of “Scan Performance” in the Description column.

A File Change scan will always start with browsing through all folders/files getting the file/folder name and calculating a hash for them. It does this in chunks. There are 7 chunks:

admin (the wp-admin folder)
includes (the wp-includes folder)
content (the wp-content folder)
uploads (the wp-content/uploads folder)
themes (the wp-content/themes folder)
plugins (the wp-content/plugins folder)
others (the rest)

As we are interested in the uploads chunk, we should look at the 4th Process Update log entry (counted upwards from the first Process type log entry) as can be been below:

…
4 Process Update <—- uploads
3 Process Update
2 Process Update
1 Process Update
Process

Click on the View Details link of the 4th Process Update log entry. If not already displayed click on the “Show Raw Details” link. In the raw details you’ll find (amongst other things):

chunk => uploads

which confirms we have the right log entry.

It’s vital that you are able to single out this particular Process Update log entry for any file change scan and look at its raw data. You’ll need this further down the road.

Try it and let me know if there are any problems finding the Process Update uploads log entry.