TheWatcher2

Rene,

Thanks for your quick replies. Maybe I did something wrong right from the beginning, because bots started crawling the staging site (https://mysite.com/dev2) as soon as it was established. At that time, bots were going to //mysite.com/dev2/wp-login/ before I got a chance to set up the hidden wp-login URL. So from the start, the staging site was discovered as a folder within my main site. Not sure how this may have happened.

Thanks,
Greg

I also just noticed that the WP Staging plugin is incompatible with the WordPress Under Construction plugin. Instead of showing visitors who are not logged in the under construction page, it shows the wp-login page. That’s convenient for any malicious bots! I had to shut that plugin down also. It’s not really a dev site now.

Hi Rene,

I actually activated the post name permalinks before trying to set up the “hide login” URL. Still no reason why the alternate wp-login site could be found by the bot. I’ve inactivated the Defender Security plugin for the WP Staging site, which is not ideal. I’ll have to use another route to setting up a hidden login URL.

Thanks,
Greg

I have noticed that WP Staging does not work with Defender’s 2-factor authentication settings, so that may indicate an incompatibility.

I used the Wordfence Security plugin to monitor live traffic and the BomboraBot has been to the site several times probing the new login page. I used the Defender plugin to mask the usual WordPress login URL and create the new login URL. It happens to be the same hidden URL for logins that I’ve set up on every other website I’ve developed, including two live sites and one other testing site. No bot has ever successfully discovered the new login URL. It is not easily guessed and I don’t believe the new login URL could be reached without it being let out by a security breach. Perhaps WP Staging is incompatible with one of these two security plugins.

Currently, Koko Analytics is not installed. I uninstalled it when I noticed this activity from bots. So if I’m understanding what you are saying, this is a typical probe by bots if you have Koko Analytics installed?

And now I see where this is coming from. I reinstalled it on one of my sites and this src is seen in the head related to “koko-analytics-js”.

That’s all I wanted to know. Thanks for your help!

Greg

• This reply was modified 2 years, 5 months ago by TheWatcher2.

Hi Danny,

Thanks for the quick response. I’ve attached below an activity detail from the live traffic feed seen using the Wordfence Security plugin for WordPress. Every bot probes for the exact same URL within the /wp-content/koko-analytics/ folder. There have been several probes of this URL over the past hour originating from different IP addresses (all bots). Note that I’ve set up a redirection to the homepage for any bots trying to get to this URL, so you can see that they were redirected.

Please let me know what you think.

Thanks!
Greg

Activity Detail
Carrollton, Texas, United States left https://endtimestruth.com/end-times-chronology/ and was redirected when visiting https://endtimestruth.com/wp-content/plugins/koko-analytics/assets/dist/js/script.js?ver=1.0.29
6/2/2022 11:27:58 AM (13 minutes ago)
IP: 47.183.195.117 Hostname: 47.183.195.117
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.5 Safari/605.1.15

Thanks for all the quick responses! I think the real issue is for us with websites containing a lot of images, many of which were created before Google added still another “requirement”, then the image notifications are just constant pain. I can’t go back through literally thousands of images–some of which do not meet the criteria of Google’s latest tyrannical “schema”–to spend countless hours finding or making images that meet the 1200×1200 px demand. Sometimes, Google just needs to get out of the way! That’s why I want to make these nagging notifications go away! It was a great plugin, but now the notification banners just get in the way of my work. Please make an off switch for the pull-down notifications. You could still highlight the plugin logo in the upper Admin toolbar to alert us of when a notification occurs.

I completed a more extensive analysis of the plugins I have running and the results are very interesting. I found two problems with these plugins if Beaver Builder, SiteOrigin Widgets Bundle, Koko Analytics, and Bible Verse of the Day are activated. It gets complicated, however:

1) If all of these plugins are on simultaneously, then Beaver Builder will throw the error message I mentioned in my first post.
2) If Beaver Builder, SiteOrigin Widgets Bundle, and Koko Analytics are activated, then Beaver Builder will also show the error message.
3) However, if Beaver Builder, SiteOrigin Widgets Bundle, and Bible Verse of the Day are activated (without Koko Analytics), then Beaver Builder does not function. It opens up an existing page, but clicking on any inserted block or module does not bring up an editing window. In this case, the error message is not displayed.
4) If Beaver Builder, Koko Analytics, and Bible Verse of the Day are activated (without the SiteOrigin Widgets Bundle), then everything works fine. This reproduces my previous finding.

This shows that there are incompatibilities between these four plugins. It is of note that this only began to happen after the recent update of Beaver Builder, SiteOrigin Widgets Bundle, and Koko Analytics. The problem did not occur before these updates. Note that the Bible Verse of the Day plugin has not been updated in many months, so I may just keep it deactivated.

It appears that one or more of the 3 incompatible plugins likely caused this problem with the latest modifications of their code after updating. Hopefully, you can figure out what the culprit might be and correct the issue.

Hi Simon,

Thanks for your response. I wasn’t using any particular widget in the SiteOrigin Widgets Bundle at the time that Beaver Builder was indicating an error message. Just having the Widgets Bundle plugin activated caused the issues. Now that I’ve deactivated it, Beaver Builder works fine.

I’ll also contact BB support to get it into your main site’s system.

Thanks!
Greg

I have now determined that the problem plugin was the SiteOrigin Widgets Bundle that goes along with the PageBuilder by SiteOrigin plugin. When the Widgets Bundle is deactivated, Beaver Builder works well. I recall that many months ago a previous update to the Widgets Bundle also caused Beaver Builder to have errors, so it has a history of incompatibility.

I will just keep the SiteOrigin plugins deactivated for now, but seeing that they are very popular, I encourage Beaver Builder developers to reach out to them for a solution.

Thanks!

I can mark this as resolved. Thanks again!

Thank you for your quick response!! It looks like it was a cache issue. Weird that previous updates didn’t have that problem. Everything back to normal. Thanks!

I can verify that I’m having the same issue. Live traffic is in error, as it sees no human traffic and only a tiny fraction of all traffic to my site after updating to Wordfence 7.0.4.

I believe this was an issue with compatibility with the SiteOrigin Widgets Bundle, which was resolved in another support topic. Therefore, I’m marking this as solved. Thanks!