Gone Fishin

Okay, thank you for that link.

Just FYI, I still think the standard tags should be protected from deletion.

And again, sorry for wasting your time.

Well, what do you know? I installed the plugin on a multi-site setup I have locally. And, adding tags works.

So, I went back to the single WP install, removed the plugin, dropped the gh tables, and purged 66 records like ‘%gh_%’ from wp_options. Then, reinstalled the plugin, and, yep, I can add tags. I must have hammered the install somehow. Sorry for the noise.

BTW, you said, “Please note that you cannot add/remove preference tags (Marketable, Unconfirmed, Confirmed, Unsubscribed, etc…) as they are synced to the current opt-in status of the contact.” But, I was able to delete them from the “Tags” page. (Maybe that’s how I mucked things up before.) If they are synced, shouldn’t deleting them be prevented?

Once last thing: You mentioned adding tags via automation. I don’t find anything in the documentation regarding automation. Could you provide a link to get me started?

Thank you for your time, and your patience & persistence.

P.S. Why is line 14 in tracking.js.php not commented out [require_once( “C:\Users\adria\Local Sites\groundhogg\app\public” . ‘/wp-load.php’ );] ? For that matter, why is that file even in the package? I can find no file that calls it.

PHP7 logs errors to the Apache2 error_log file. There are no entries added to the error_log when this occurs. There are entries added to the access_log that are consistent with the requests show by the browser developer console.

A MariaDB general log shows no UPDATE query:
https://www.dropbox.com/s/2yhiwuhn5byqzva/mariadb.log?dl=0

I don’t know how that will help you diagnose the issue. Seems to me all that will do is confirm that I am not lying about it. Nevertheless, here is a screen recording.
https://www.dropbox.com/s/vkwwodo18jifzra/groundhogg-screen.mkv?dl=0

The browser developer console shows that the tags are being sent by data.min.js in the PATCH request to https://localhost/wordpress/wp-json/gh/v4/contacts/1.
https://www.dropbox.com/s/eakcadd5vl0exoi/Groundhogg-request.png?dl=0

But, the tags are not in the response.
https://www.dropbox.com/s/j2xguw6agr3b1j9/Groundhogg-response.png?dl=0

These are tags that I created.

And if it matters any, this is with PHP 7.4.33.

Bingo.

That is found on the Basic Policies tab. I did not realize that applied to the Administrator user as well.

Thank you!

All I see in the log regarding me is my log in event as an INFO.

To be clear, I did try to access update-core.php by typing it in to the location bar since there was no Update link (even though updates were needed). Would Ninja Firewall consider that a “direct access”?

Even if so, Tools > Site Health shows 1 critical issue: “Background updates are not working as expected” due to wp_version_check() being disabled. Deactivating the plugin causes that critical error to go away. And, there is no Delete link on themes.

I can’t even manage themes when the Firewall plugin is active. It’s as if I have been stripped of my Admin privileges.

Just FYI for anyone wishing to utilize the my_honeypot_html_override function to modify the entire outputted HTML for the honeypot field, you can get a listing of the array elements supplied to the $args parameter by inserting the following line just prior to the “return $html;” line in the function (only for testing of course):

echo "<script>console.log( '" . json_encode($args) . "' );</script>";

If you wish to modify the HTML and also opt to “Move inline CSS”, do not modify the span element’s id attribute as that will cause the field to be displayed and visible.

@ryan:
The honeypot might be made more effective by eliminating the “/hp[a-zA-Z0-9]{13}/” signature of the span element’s id attribute. Please allow me to suggest:

$atts[‘span-id-prefix’] = $tag->get_option( ‘span-id-prefix’, ‘id’, true );
$unique_id = uniqid($atts[‘span-id-prefix’]);

Also, the class of the label element, “hp-message”, does not seem to be defined anywhere. I wonder if that honeypot signature also be eliminated. Or, perhaps it could simply be replaced with the same user-custom class that is used for the input element.

And finally, thank you very much for your time.

It’s all handled in the PHP functions, nothing is placed in the honeypot tag.

Okay. So, the filter is triggered simply by including the PHP code of the relevant override function in the theme’s functions.php file. That’s the part I wasn’t getting.

One, then, needs to include only the code that performs the desired override. And, utilizing the wpcf7_honeypot_accessibility_message function and/or the wpcf7_honeypot_container_css function in conjunction with the wpcf7_honeypot_html_output function would be redundant.

Thank you for the clarification.

Thank you for such a fast response, Ryan.

By “filter text”, I mean the text of the filters themselves:
wpcf7_honeypot_accessibility_message ,
wpcf7_honeypot_container_css , and
wpcf7_honeypot_html_output .

Where are they used? Are they manually placed into the honeypot tag?

After doing a compatibility scan myself, I was wondering the same thing. And, since I see this question is a month old without an answer, I did some research.

The issue is that, in PHP 7, hexadecimal strings are no longer considered to be numeric. That means that trying to manipulate such a string, as given in the error report, as a number would cause problems.

However, that particular string is used in the request uri (URL) when attempting to compromise a site. As such, it is a string, and, from a review of the PHP code in the named file, BB uses it as a string only and not a number.

Therefore, I am highly confident it is not an issue and BB can be safely whitelisted.

Wow, what a blazingly fast response!

I can understand taking time to develop a safe method to edit serialized data, but the “Doesn’t delete site transients” issue is over three months old and the OP even provided the solution. It doesn’t seem like it should take three months to add 10 characters.

But, I am glad the plugin is still maintained. I do like being able to see a list of transients and choose which to delete, edit, or leave alone.

Thanks.

Notice to all thinking you have to recreate all your jobs:
It is not necessary to delete the old job, and create a brand new one. I found this out because doing that did not resolve the issue for me.

The cause of the issue is in the formatting of the Archive name; which is, essentially, tokens separated by underscores.

In my case, I had “backwpup_database_%Y-%m-%d_%hash%” defining the Archive name. The first token would be “backwpup” and the second token, “database”, etc.

This is a problem due to the manner in which the function ‘owns_backup_archive’ in class.job.php (@ line 609) handles the tokens.

It assumes that if the Archive name starts with “backwpup”, then the old-style hash is being used, and it expects the hash to be the second token. If the hash is not the second token, then the function returns false (ie. the file is not owned by BackWPup) and the file is ignored.

* Simply removing “backwpup” from the beginning of the Archive name solved the problem.

So, as I see it, either the code needs to be changed, or further information needs to be added to “Note: In order for backup file tracking to work, %hash% must be included anywhere in the archive name” on the ‘backwpupeditjob’ page informing that:

If the Archive name starts with “backwpup”, then the “%hash%” token must immediately follow it, ie. “backwpup_%hash%[_ …]”.

The max File Deletion value for both “To: Folder” and “To: Dropbox”:

For the Current Uploads job on Site1, is 3.
For the Full Backup Weekly job on Site2, is 2.

On Site1, where file deletion is not working correctly, I also have:
File Deletion for a daily Database backup set to 7, and
File Deletion for a monthly Files & Plugins backup set to 2.

None of the File Deletion params on Site1 work correctly.

As an aside, Site2 (where it works correctly) is a multi-site install. Site1 is a single-site install.