brt

thanks alot for your quick support!

the databasestructure was correct, i noticed that the deleted contacts were not in the database at all, so it has to be a cache issue, we use redis. after flushing redis the deleted entries disappeared.

+1 Version 4.3.0.8

Dec 20 12:12:26 someserver wordpress(somesite.com/)[10370]: Accepted password for someuser from x.y.z.123
Dec 20 12:20:16 someserver wordpress(somesite.com/)[20548]: Blocked authors enumeration from x.y.z.123
Dec 20 12:29:17 someserver wordpress(somesite.com/)[28994]: Blocked authors enumeration from x.y.z.123
Dec 20 12:31:26 someserver wordpress(somesite.com/)[31002]: Blocked authors enumeration from x.y.z.123
Dec 20 12:31:46 someserver wordpress(somesite.com/)[30989]: Blocked authors enumeration from x.y.z.123
Dec 20 12:32:06 someserver wordpress(somesite.com/)[30989]: Blocked authors enumeration from x.y.z.123
Dec 20 12:37:42 someserver wordpress(somesite.com/)[5353]: Blocked user enumeration attempt from x.y.z.123
Dec 20 12:37:45 someserver wordpress(somesite.com/)[5353]: Blocked user enumeration attempt from x.y.z.123
Dec 20 12:37:46 someserver wordpress(somesite.com/)[5904]: Blocked user enumeration attempt from x.y.z.123
Dec 20 12:38:01 someserver wordpress(somesite.com/)[5904]: Blocked user enumeration attempt from x.y.z.123
Dec 20 12:38:01 someserver wordpress(somesite.com/)[5353]: Blocked user enumeration attempt from x.y.z.123
Dec 20 12:38:02 someserver wordpress(somesite.com/)[6945]: Blocked user enumeration attempt from x.y.z.123
Dec 20 14:52:11 someserver wordpress(somesite.com/)[18549]: Blocked authors enumeration from x.y.z.123
Dec 20 16:04:21 someserver wordpress(somesite.com/)[28387]: Blocked authors enumeration from x.y.z.123
Dec 20 16:04:53 someserver wordpress(somesite.com/)[29442]: Blocked user enumeration attempt from x.y.z.123
Dec 20 16:04:59 someserver wordpress(somesite.com/)[29680]: Blocked user enumeration attempt from x.y.z.123
Dec 20 16:04:59 someserver wordpress(somesite.com/)[29523]: Blocked user enumeration attempt from x.y.z.123
Dec 20 16:05:00 someserver wordpress(somesite.com/)[29442]: Blocked user enumeration attempt from x.y.z.123

users get locked out after succesful login and starting editing posts.

thank you very much, i will keep you updated!

thank you very much for the quick fix, works like a charm!

+1

also noticed that all the icons in the sitesmenu are gone, is there any workaround/quickfix for this?

Luckily i found the documentation on how to correctly Implement “Advanced noCaptcha & invisible Captcha” in Contact Form 7

it seems there is an incompatibility with another addon we use to add a recaptcha to comment forms, after deactivating the plugin “Advanced noCaptcha & invisible Captcha” it is working again.

too bad, having recaptcha exclusively for form OR comments is … @:-/

+1 same here, after saving the keys, and reopening the integrations-form the two fields are empty again. no recaptcha in the form.

i also added german translations:

https://translate.www.ads-software.com/locale/de-at/default/wp-plugins/map-block-gutenberg/

if you want you could also post a PTE request at polyglots
so i can approve all german translations for your plugin.

If you have a minute, please leave a review.

fairly earned:
https://www.ads-software.com/support/topic/nice-and-easy-integrates-perfectly-to-the-editor/#new-post

i like the idea, that would be awesome, e.g. as a constant within wp-config.php, so that it could be configured for all sites in a multisite installation.

the plugin works great, but if you ever need to change the key, you will have to search for alle map-blocks and change the key. therefore a central place to change the key would save a lot of work.

also, after adding my own key, the message keeps telling me that i need to create my own key, this can be quite confusing, especially for users who are not that familiar with that kind of things.

WP Security -> Scanner
-> File Change Detection Settings
uncheck “Enable Automated File Change Detection Scan:”

Im getting the same message from my host that the row in the Database is to big to backup.

How do we fix it?

you could delete the row, but you will also have to ensure, that it will not be recreated that big by the next filescan. you could try to limit the number of scanned files by adding appropriate patterns to the exclude list, but that could end up in endless trial and error.

IMHO filescan as it is implemented now is dangerous therefore i recommend to delete the row and disable this feature completely. when filescan is activated, sooner or later you will get into the situation were database backups will (silently) fail. this happens when the number of scanned files is to big as the information for all files will be stored in a column of one single row. there will be no warning within wordpress, and you will have no database backup.

The plugin has a code which will periodically check the tables created by aiowps and it will cleanup any table which has more than 5000 rows,…

5000 rows would be no problem, the problem is: all the file information (thousands-of files!) is stored in one single row. and this single row is getting so big, that database backups start silently failing.

i do not see how mentioned cleanup process could help in this case.

• This reply was modified 4 years, 12 months ago by brt.

this is the mentioned thread:
Database backup problems because of file change detection functionality

is there a notification when the database backup fails?

i am using automysqlbackup and get notifications by email in case of a failing backup, maybe users just do not notice when their database backup fails? i never got a warning of failing db backups within aiowps/wordpress. the dangerous thing is, that at the beginning, when you set it up, everything may work nicely all the time until you reach the limit, and then backups will silently fail.