psamathe

Sorry, I hadn’t done one (didn’t even realise that was how it worked). Just done one

Report number: XNEFKTGP

Report date: 08/21/2019 12:11:25

Many thanks. I also noted that your web site actually also provides the answer that’ll teach me to seek out sources of help in future before starting a thread.

Ended-up doing some custom css to remove the theme masthead and a few other bits at the same moment/size as the mobile menu appears.

I’m looking to go to Pro and am sort of hoping that there is a better method than my crude bodge (want to double check it does what I want before purchasing (Pro is not cheap).

Not completely correct but removd the 2nd (upper) menu icon following your residuals remvals instructions (theme Vislap by https://wptheming.com/2013/03/visual-theme/)

But the menu bar from Mega Menu is appearing bleow the main bar at the top (taking up more space on an already small screen). I’d appreciate any ideas to put it back over the top bar as it is for desktop.

Thanks

Sorted out a temporary bodge by editing all the links from e.g. mypic.png to be mypic%2epng

I’ve only seen this issue on links ending in .jpg or .png and links to .svg are not affected and work properly.

It does. Many thanks.

My directory structure and block-all-options-controls.php seems somewhat different.

/wp-content/plugins/wordfence/views/ does not have any .pho scripts but a load of sub-directories. The block-all-options-controls.php file seems to be in an “options” sub-directory. But in that file, line 89 says “width: (WFAD.isSmallScreen ? ‘300px’ : ‘500px’),”

https://psamathe.eu/Temp%20Images/Nov%202018/ac1.png

• This reply was modified 6 years ago by psamathe.
• This reply was modified 6 years ago by psamathe.

Many thanks. Somewhat confusing that the lock-out timers in the Brute Force section are not applied to some of the Brute Force settings but timers from a different section used.

I will try but I’m afraid it might not be for a bit of time. I’m now in the middle of moving the site between hosting providers so even the hackers are not getting anywhere at the moment.

It’s the standard login page, latest public release of WordPress.

I am happy to identify the other plug-in if it is useful but didn’t want to start implying plug-in <xxx> is ….. I only mentioned it to lower the priority as the login attempts are being blocked so I feel “unthreatened”.

I suspect the hack attempts will drop to more routine levels in a week once US politics ends campaign-time (I assumed they were related to that as they started at the same time as the campaigning). I actually went overkill whilst moving sites and completely blocked all countries the login attempts were coming from (in case DNS propagation delays give them access before I get access!).

If I’m the only person raising it and my config is complicated by a 2nd security/blocking plug-in then I’ll mark it as resolved and post additional info when it’s available.

Thanks for your response.

Reason for my suspicion is I’ve seen loads of login attempts with bad passwords on configured “immediate lockout usernames” but with strange capitalisation that are not locked-out. I’ve configured the usernames in as all lower case but hack attempts are using some capitalisation.

As I say it’s not a panic as I have another security plug-in that is blocking them out.

But I don’t have time at the moment to carry out tests, etc. I’ll experiment more once I get a bit more time.

• This reply was modified 6 years ago by psamathe.

Any idea when this is likely to be fixed as I’m seeing brute force login attacks at the moment with “unusual” capitalisation in the usernames being submitted and I couldn’t see anything here so started another question

The attacks are being caught by 2nd security plug-in so I’m not panicking but assuming it has not been fixed (I’ve seen nothing in the release notes) it does seem a loophole that attackers are aware of.

That will be why I’m seeing strange capitalisation patterns in the username being submitted by the brute force attack. And I suspect that it is the other security plug-in that is blocking the access.

No way am I going to bother to configure in all case combinations for the 14 character usernames they are currently “exploring”.

Is there any schedule when this is likely to be fixed?

• This reply was modified 6 years ago by psamathe.

I do (have a site set-up using WP SuperCache and it’s a fairly quiet site (my worry is if you get visitors coming in during a test then it can mess things-up.

But I pre-load the cache though the number of pages that get pre-loaded seems variable. i.e. every hour a con job runs that often re-generates the cache (or checks the state of the cache – I don’t understand the details of WP SuperCache preload methods).

I’m a bit tied up this evening but if we can arrange some mutually convenient time I’d be happy to help using the site for testing. As it’s a quiet site, the WordPress cron system is run from the server cron rather than on page visits – so I’ll check what time it runs (as that could mess things up (and it was a bit of a fiddle getting it working to I’d prefer to avoid that time rather than stop the cron).

Are you Mac or Windows based? (trying to think of a real-time communications method; I’m Mac which would make iMessage on option, Jabber?).

And with the issues of privacy and the risks of posting any e-mail address, I’ll make some checks and maybe we can switch to exchanging contact details initially through the Contact page on my website?

I am looking to block all Tor users, but I’m not bothered about them viewing pages that are already cached.

What I’m finding is a lot of hack attempts and these are not for “normal” pages but things like xmlrpc or “fishing” for .php scripts e.g. …..com/wp-content/plugins/poor_plugin/upload.php (which does not exist).

So only wanting to avoid them getting “past” already cached pages.

But if they went to e.g. …..com/my-trip and it was not already cached and they got a block message I’d not want everybody else (non-Tor visitors) to get the blocked page as that had been loaded into the cache by the previous blocked Tor visitor.

Hope that makes some sense (explaining stuff is not my strong point!).

New release 2.3.4 has sorted the issue.

Many thanks