sffandom

I’ve BEEN looking. I maintain over 70 installations and have to make themes available for my users. Taking time away from theme research to try and figure out how to make this new version usable is not a really good choice for me.

The more I use 3.9 the more I want to revert.

ON EDIT: And what makes this search for themes even more annoying is that the search function doesn’t even return about 1/3 of the themes I look for when I search by name. I have a window open for a ww.wp.xz.cn search to find the themes but when I want to install them from the dashboard installer it can’t find some of them.

I am guessing these are newer themes are not yet indexed or something but this is REALLY annoying.

Multiple installations of multisite networks configured for subdomains on several different hosting services. 3 of the installations are on a dedicated server.

I use Jetpack but I only need it to activate the statistics (so far). Jetpack seems to be able to get along without it after that but you raise a good point.

Clearly the script is included in the distribution because it is useful.

If you use iptables then you can/should DROP requests coming from the compromised servers. That gets rid of the 403 errors.

But no matter what you do you’ll have to constantly update your list of moderated IP addresses and the problem when only get worse when all servers are configured to only work with IPv6 addresses.

They’ll probe for different things on different Websites. There is no rhyme or reason in the probing. On my server I have several WordPress installations next to static HTML Websites. Some of the static sites are hit with probes for “index.php”, “wp-login.php”, and “xmlrpc.php”. Nearly all of the sites have been probed for “phpMyAdmin” at one time or another.

They do tend to congregate on some sites more than others so I believe there is a reporting mechanism built in to these scripts so that they tell one or more command servers which sites have which files. I have noticed they may come in with 1 or 2 probes on one day and then about two weeks later I see thousands of hits from the previously used IP addresses.

The sites that are hit the most are my most popular sites. They have the most content, the most inbound links, and the most real visitor traffic.

The FILES directive only tells your server to issue a 403 “Forbidden” response to any attempt to connect to that specific file. And I believe you need to put quote marks around the file name (although that may be optional if you’re not getting an Error 500).

You need to block the IP addresses of the Web servers that are trying to reach out to your XMLRPC.PHP file. But blocking individual IP addresses is inefficient.

You want to block groups of IP addresses as they are assigned to Web hosts. You can use this tool (Cf. http://bgp.he.net/) to do the lookups. Your deny list will look like:

Deny from aaa.bbb.ccc.ddd/nn
Deny from eee.fff.ggg.hhh/nn

WordPress fixed the vulnerability so that XMLRPC.PHP cannot be used in post 3.5.1 installations. But the compromised Websites and scripts don’t know in advance if any given Website is still vulnerable so they will continue to probe.

By denying access to the script you prevent other sites from activating it. That means you won’t get any trackbacks or pings. But they will still try to get to it.

If you look at your error log reports every day you’ll be able to cull the IP addresses that are looking for XMLRPC.PHP and you can decide whether to block them (or their AS records, which look like aaa.bbb.ccc.ddd/nn).

You can also use the RENAME WP-LOGIN plugin to stop the brute force dictionary attacks from trying to figure out your admin credentials. By culling IP addresses from your error log files you’ll be able to block more compromised Web servers.

Of course, as you block more servers some people will no longer be able to send email directly from their servers to you. But I have seen significant improvements in Website performance as my block lists have grown.

Interesting. But the plugin page says you haven’t updated it in 2 years. Is it still compatible with the 3.8.1 dashboard?

ON EDIT: I installed the plugin on a test site. I think I’ll play with it.

I am happy with the sidebar widget. The problem is that I get better conversions if the form is in a table at the bottom of each post, but I don’t want to use a “Footer” widget area as those are too far down the page.

I don’t like editing theme files, either. 🙂

My solution is not exactly elegant but by plugging the form code into an advertising tool I can position it where I want and feel relatively safe (and I don’t know enough about WordPress code to know if I am just FEELINg safe).

What would be idea would be if the WordPress developers created an “End-of-Post/Page Copy” widget area that really is appended at the end of the main copy. But that’s not your problem.