pplong
Forum Replies Created
-
thank you @webtoffee
The precise application of the rules around consent is obviously a bit of a grey area, and I still think that having the option pre-set to ‘enabled’ is a bit marginal, even if the scripts aren’t set until the Accept button is clicked.
But, that said, I think what you’ve done by allowing admin to make their own decision about the default state is absolutely ideal – now site owners can make that call themselves.
Thank you for addressing it so quickly
Thanks @webtoffee for the information
Couple of things:
1) I think that really does mean that the free version of the plugin absolutely cannot be GDPR compliant then, however you configure it – because ‘pre-checked’ consent boxes are explicitly not permitted;
2) In testing, I am seeing that the ‘cookielawinfo-checkbox-non-necessary’ cookie is immediately being given a value of ‘yes’ before I even have a chance to give or withhold consent – so are you saying that non-necessary cookies will not be set, even if that cookie value is ‘yes’?It’s a shame, because the plugin seems to do so much of what’s required, so i’m really surprised that the free version has (what appears to me, at least) a glaring compliance issue.
Using a VPS is definitely going to be worthwhile in the end, it’s just the learning curve that’s the problem.
Assuming that you’ve got SSH/console access to the VPS, I find that a tool like ‘htop’ is really useful because you can see a live view of the processes and which ones are hitting the CPU. You’ll just find yourself sitting there staring at it though.
Aside from all that, I’m assuming that you don’t see spikes from ‘unwanted’ traffic at these times? e.g. if you look at the access logs, you’re not getting loads of hits to /wp-login.php or some other attempt to compromise the site? For sites that don’t require customer logins, I’ll always set the WF option for ‘immediately block invalid usernames’ because at least then each IP can only guess one username before it gets blocked. And set some sensible rate limiting rules too.
Hi @trademark2k6, no problem
Well, these are only my observations, having used WF on a number of sites, so it is just my opinion, but:
– I guess there’s no harm in staggering when you do the de/reactivation, although I’m not actually convinced that there’s a link between when you reactivate, and what the scheduled scan start time is – i.e. if you did two sites at once, I don’t think that will necessarily result in the same schedule time being selected by WF for both;
– On an otherwise ‘quiet’ VPS, I’ve never noticed WF drawing attention to itself (resources-wise) for any other reason than scanning
– I guess it could any number of things causing the CPU spikes, not necessarily related to WF. If it always happened at the same time of day, that’s gotta tell you something (e.g. backups all running at the same time?)
– It depends on the rest of your server setup – I’ve certainly hit problems before with things like ‘sub-optimal’ configuration of php-fpm pools, resulting in more nginx/php services being spawned than necessary. But of course you might have a completely different setup.My first response is always to try to understand the pattern of behaviour (time-wise) and then drill into the logs for those times for clues.
All of that said, I’m no expert by any means – but I do share your frustration.
You might not need to actually delete the plugin – I seem to remember that if you select ‘Delete Wordfence Tables and Data on deactivation’ – and then deactivate and reactivate the plugin, this will cause the scheduled scan time to regenerate.
If you check the timing of the ‘wordfence_start_scheduled_scan’ cron job (within Tools – Diagnostics – Cron Jobs) before and after de/reactivation, you should see that the time has changed.
Do that on 4 of your 5 sites, and the scheduled scan times should all be different.
And on your other question, I always see two ‘wordfence_start_scheduled_scan’ cron jobs, as if two are always scheduled, usually 3 days apart. Normal, as far as I know.
Hope that helps – just bear in mind that using this method will mean that you’ll need to reconfigure your WF settings if you were using anything customised.
thanks @wfyann – I’ve sent you diagnostics reports from 3 sites via email.
thanks @wfyann
Yes the cron job times in Diagnostics do correspond to the times when it grinds to a halt.But that gave me another thought (this might well be what you’re getting at) – as a test, I’ve just checked ‘Delete Wordfence tables and data on deactivation’ and then gone ahead and deactivated/reactivated Wordfence – and that cron job is now scheduled for a different (albeit apparently random) time/day.
So I guess it’s possible to effectively force wordfence to choose a different scan schedule – it’s a bit nasty, but it might help to get round the problem…
thanks for looking, any further thoughts appreciated
hey Caleb – no, they’re not all mine, they’re all quite different in terms of functionality, plugins etc, and I need the ability to move/migrate sites easily. I’m (definitely) no multisite expert, but I’ve made the decision in the past that it’s not the right solution in my case.
Using separate WP instances has been fine in the past (with centralised plugin/theme management etc), but this recent WF update appears to have generated a new problem.Thanks for your reply though
it’s certainly possible it’s related to nginx – I’ve just tested on apache and you don’t get the same problem.
I’ll see if I can drill down on a config problem
thanks for your help
PaulThanks Cais, but no joy I’m afraid – I did the following:
– Saved the permalinks back to Default, and then re-saved them as /%postname%/
– Reset the gallery options;
– Cleared the image cache.But I still get exactly the same behaviour (and I’m still using a default theme, twentythirteen, with all plugins deactivated for testing)…
Hi tizz,
Sorry, I should have said – yes it does, I’ve just swapped it over to twentythirteen now, same problem.
thanks for your quick reply
good, glad it helped – it’s obviously not ideal to have to disable useful functionality though; I don’t know what mail transfer agent you’re using, but there might be some mileage in changing to another one – I found some decent documentation on the Digital Ocean knowledgebase on setting up exim, and now the performance of the checkout process is good, and all emails work.
Hi laurabfont
The issue for me appeared to be email-related. When I did a fresh, test install, the checkout process worked fine until the sendmail package was installed. Then, immediately, the checkout started timing out.
So my personal fix was to remove sendmail and configure exim4 instead, and the checkout process worked fine. For the record, that’s on a Digital Ocean droplet too, albeit lower spec than yours.
It’s a shot in the dark, but I wonder whether disabling your new order notification/customer email temporarily might be worth trying – in case it’s the email trigger that’s causing the problem.
All the best
Pauloops, that link was meant to be this one
I can’t write html either 😉
Nope, your list is longer than mine to be honest. And 15 didn’t work for me either…
I was prepared to pay for support too – I did consider buying the cheapest possible extension from WooCommerce just to get access to the support.Actually, there was something else I tried – there are a number of threads about
admin-ajax.phpbeing slow generally (not just on checkout) and its relationship to the Heartbeat API (where it appears to repeatedly postadmin-ajax.php, thereby slowing everything else down).I did deregister the heartbeat API using information from .
Otherwise, I think I’m out of ideas, sorry :-/