UKC How to disable the FireFox popup blocker
You can add an exception for any site in FireFox when you get the yellow bar that says a popup has been blocked.
Alternatively, to completely disable the popup blocker:
This will completely disable the pop up blocker in FireFox.
How to disable Popup Blocker in Internex Explorer
Lets first try resetting all the security to default level for Internet explorer and check if that resolves the issue.
To do this follow the steps below:
If the steps above do not work, you may have to reset the Internet explorer, to do this follow the steps below:
http://support.microsoft.com/kb/936213
We hope this helps.
Messages in error_log: Please use the date.timezone setting, PHP Strict Standards: strtotime() [<a href=’function.strtotime’>function.strtotime</a>]: It is not safe to rely on the system’s timezone settings. Please use the date.timezone setting
The default timezone setting in your PHP.INI is not set.
Edit you PHP.INI using your favourite editor eg.
# vi /etc/php.ini
Change this:
[Date] ; Defines the default timezone used by the date functions ; date.timezone =
To this:
[Date] ; Defines the default timezone used by the date functions date.timezone = "Europe/London"
This will resolve the problem.
Control unwanted crawler traffic safely
Use the least disruptive control that solves the problem. A robots.txt rule is easy to reverse and preserves normal visitor access. A server or Cloudflare block is stronger but must be tested carefully because user-agent matching can be spoofed.
Logs show sustained requests that consume bandwidth, PHP workers, database time or crawl capacity and the site does not need visibility in Baidu search.
The business serves Chinese-speaking customers, depends on Baidu discovery or has no measurable resource problem from the crawler.
Confirm the user-agent, requested paths, response codes, request rate and time window in access logs. Do not act on an isolated visit.
A crawler may expose slow searches, broken links, endless calendar URLs or uncached dynamic pages that should be corrected regardless of the bot.
Add this group to the site’s root robots.txt file:
User-agent: Baiduspider
Disallow: /In Plesk File Manager, open the document root for the domain, normally the directory containing the live site’s index file.
Download or copy it before editing. Existing search-engine, sitemap and plugin rules must be preserved.
Place the two lines in a separate user-agent group. Do not add the disallow rule beneath a wildcard group unless every crawler should be blocked.
Visit https://yourdomain.example/robots.txt and confirm it returns plain text with the new rule.
WordPress can generate a virtual robots.txt when no physical file exists. If an SEO or security plugin manages it, use that plugin’s supported editor or create a carefully reviewed root file. Avoid having several tools compete to generate different versions.
A compliant crawler that identifies as Baiduspider should stop requesting paths covered by the slash rule after it refreshes the file.
The website remains available if that user-agent requests it. robots.txt is instruction, not enforcement.
The crawler may cache robots.txt and already queued URLs may still appear in logs for a while.
Blocking crawling is different from removing known URLs from a search index. Search engines may retain a URL reference without revisiting the content.
If requests continue and resource use justifies enforcement, back up the live .htaccess file and place this block before the normal application rewrite rules:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} Baiduspider [NC]
RewriteRule ^ - [F,L]
</IfModule>The F flag returns HTTP 403 Forbidden and L stops later rewrite processing for that request. The old 2010 advice used BrowserMatchNoCase with Deny from env, an Apache 2.2-era access-control pattern that should not be copied into a current Apache 2.4 configuration.
Yes. When the domain is proxied through Cloudflare, a custom security rule can match requests whose user-agent contains Baiduspider and block or challenge them at the edge. This can reduce origin traffic more effectively than .htaccess.
Match the intended user-agent text case-insensitively and apply it only to the relevant hostname or site.
Use rule preview, security events or log data where available. Check that normal browsers and monitoring services do not match.
A block is predictable for an unwanted crawler. A challenge is less absolute but can still consume requests and may not suit an automated bot.
Record why it exists, when it was added and how to disable it if the business later wants Baidu search visibility.
| Test | Command or action | Expected result |
|---|---|---|
| robots.txt | Open /robots.txt in a normal browser | HTTP 200 and the Baiduspider group appears once |
| Normal visitor | Open several public pages normally | The same successful pages and assets as before |
| Spoofed crawler header | curl -A "Baiduspider" -I https://example.com/ | HTTP 403 only when the hard block is enabled |
| Logs | Compare request counts and status codes after the change | Requests fall after robots.txt or receive 403 at the chosen layer |
| Other search engines | Review Google and Bing crawling or test their user-agents | They remain unaffected by the specific rule |
Deny from may rely on compatibility modules and can behave differently in modern hosting. Use a current, tested method.
Crawler networks change. Third-party lists become stale and can block unrelated visitors or miss new addresses.
A wildcard ban can remove useful search, monitoring and service traffic. Match only the crawler or paths causing the problem.
A syntax error in .htaccess can make the whole site return HTTP 500. Keep a copy and know how to restore it through Plesk.
Not necessarily. The crawler may use a cached copy and have requests already queued. Monitor logs over time before deciding the request was ignored.
Not when the rule specifically targets Baiduspider and is implemented correctly. Test normal pages and review the complete robots.txt so a wildcard rule has not been changed accidentally.
Yes. In robots.txt replace the slash with the path prefix, or narrow the server or edge rule. This can preserve general discovery while protecting searches, calendars or other costly sections.
A server block stops application access but does not force the remote client to stop sending requests. An edge block can protect the origin, while rate limiting or provider assistance may be needed for persistent abusive traffic.
It is possible, but static lists age quickly and require careful verification. Prefer crawler instructions or an edge security rule unless you have current, authoritative network data.
Yes if you are not comfortable restoring the file after a syntax problem. Include the domain, sample log lines and the observed resource effect, but remove passwords and unrelated personal data.
Need help checking the logs?
Send support the affected domain, time window, example requests and resource symptom. Do not send account passwords.
The domains are grouped under email primary address.
Did you use a different email address for the transferred in domain than you use under your regular account?
If so, the system cannot link the domains together under one account. If you require, we can simply merge the accounts by changing the email to the one you wish to use.
If you can advise to the Helpdesk the email address you would like applied and the domain name you wish us to modify we can do this right away for you.