One of clients recently wrote me about some strange formatting appearing on a WordPress site. Example of the strange HTML follows:
<p id="[object]">Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed et nunc vitae nibh semper luctus.</p>
<p id="[object]">Sed et nunc vitae nibh semper luctus. Cras gravida semper magna, sit amet varius purus dictum non. Cras eget dolor est. Vestibulum dui ligula, adipiscing eget vestibulum dignissim, congue sed turpis.</p>
<div id="[object]" class="mceTemp mceIEcenter"><dl id="attachment_1234" class="wp-caption aligncenter" style="width: 510px;"><dt class="wp-caption-dt"><a href="http://example.com/wp-content/uploads/2011/05/example.jpg"><img class="size-full wp-image-1234" title="etc" src="http://example.com/wp-content/uploads/2011/05/example.jpg" alt="Suspendisse erat tortor, auctor sit amet dapibus a, sodales non massa. Integer viverra ornare purus non sodales." width="500" height="281" /></a></dt><dd class="wp-caption-dd">Suspendisse erat tortor, auctor sit amet dapibus a, sodales non massa. Integer viverra ornare purus non sodales.</dd></dl></div>
<p id="[object]">
<p id="[object]"> </p>
<p id="[object]"> </p>
To summarize the oddities:
I suspect this has to do with TinyMCE‘s built-in on-the-fly code re-writing going haywire somehow. Incidentally, the person who was having these issues was running a pretty old version: WordPress 2.6.3
Anyone know what this is all about? Leave a comment and together we’ll fix the world (or at least help others with a very frustrating bug)
OK. If you’re reading this you’re probably pretty frustrated already so let me offer my condolences and say that you’re probably really close to being out of the woods now that you’re here. I just successfully removed this little bugger from an Windows XP machine, and it only took about 15 minutes.
I found several sites explaining how to manually remove this malware by editing the windows registry but I intend to make the instructions a little more clear so you can do this with a little more confidence.
And keep in mind, if you’re not dealing with XP, my instructions might not work exactly. But you can probably apply my clarification to the popular instructions to whatever iteration of those instructions you need to work with.
Here are the popular instructions (in this case from removeit.info), but please keep reading before trying to follow them.
Remove AntiMalware GO files and folders:
%Temp%\[random]\[random].exe
Remove AntiMalware GO registry entries:
HKEY_CURRENT_USER\Software\[random]
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run “[random].exe”
HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\PhishingFilter “Enabled” = “0?
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings “ProxyOverride” = “”
Clarifications and Precautions:
If you’re seeing this and not liking it: Maximum upload file size: 2MB
…the trick is generally to either upload a php.ini file with ammendments to the server’s default php settings, or in the case of some hosting providers, iPage included, you need to find a special settings page where you can edit your php.ini file.
Where is it? I certainly couldn’t find it. But after calling iPage, the secret is revealed. Here’s how you get to iPage’s php.ini editor:
iPage Customer Login (takes you to control panel…)>>Control Panel>>Scripting and Add-Ons>>CGI and Scripted Language Support>>PHP Scripting
You will need to find certain lines and replace their default values.
the values I use are these:
post_max_size = 30M
upload_max_filesize = 100M
max_execution_time = 900
memory_limit = 100M
I thought I was losing my mind. About half the time, when making adjustment to a stylesheet, the site would not update. This was causing development work that should take about ten times as long. Not good.
UPDATE: I got a comment from someone named ‘Whit’ which reads:
I have also had this problem. Though you guys might like a clearer answer as I got from iPage. They told me the following, “We use Varnish Caching technology. Hence, your website may not display the changes immediately.”
Very annoying. Either way, the simplest answer is to add no cache code to your .htaccess file like below:
Header set Cache-Control: “private, pre-check=0, post-check=0, max-age=0?
Header set Expires: 0
Header set Pragma: no-cache
Thanks, Whit!!! [now back to my story]
After finding this, I finally called iPage. After debating with their “tech support” person about whether or not this could be their fault (which it clearly is), the person finally found that he could turn off some sort of caching that iPage has running by default on shared hosting accounts. Eureka! Unfortunately, it took 20 minutes to get thru to support. More unfortunately, I had to plea and argue with the person for fifteen minutes before I could inspire him to discover that indeed, the caching is happening. And most unfortunately of all, before I finally convinced the person to to look for the solution, the person tried to convince me that I should be willing to put up with it taking “ten minutes” or more for a CSS update to take affect. His words, “ten minutes.” Seriously? Ten minutes for a CSS tweak to take effect? I can’t believe someone would say such a thing. We’re talking about changes that take five seconds to make. We’re talking about the workflow that virtually every web developer relies on: upload a change to the server, view the change in a browser, rinse repeat. Ugh!
Oh, and the kid also said that this caching that he turned off on iPage’s end might take up to 24 hours to actually turn off… WTF!
So while I’m at it let me just say this about iPage also: FTP times out a lot with them. Very annoying, but I can deal with that.
I don’t think the money you save by going with iPage (a few dollars a month) rather than another hosting provider ( bluehost or hostgator, for instance) is worth it.
I’m angry at them for
OK. I’m done now. Back to work.
Mailpress is rad, but apparently they need to make an update to their plugin.
I use it and love it but with wordpress 3.05, I’ve found that I’m not able to approve comments. When I click on the ‘approve’ link for a comment, the comment turns white for a second, like it has become ‘approved’ but suddenly goes red right after. Weird bug.
Whenever you encounter weird bugs like these, it’s a good idea to make sure all your plugins are up to date and then, if you still have a problem, turn your plugins off one at a time to see if one of them is causing the problem.
The maximum number of friend requests you can send per day, as far as I can tell, is 100. I may be slightly off. Here’s the thing:
When you run out of friend-requests, it doesn’t tell you! So you can end up spending an hour (or hours) adding people without realizing you are accomplishing nothing! The way to tell is you refresh that user’s page, and it doesn’t say ‘friendship requested,’ or you just send the request twice and the second time, it will say the same thing it did the first time: “Do you want to make friends?” instead of “you already requested this person’s friendship” (or whatever the specific wording is, you get the point.)
Diclaimer: I may be blocked or something rather than just hitting a preset speed-bump. I did sent a lot of requests. I’ll know tonight at either Midnight somewhere in the US or in the UK.
Recently I found an awesome user group on Last.FM that had showcased one of my tracks as the “sound of the year…”
So I figured I’d better add all of the members as friends.
I know that back in the day, MySpace had a policy that allowed somewhere around 400 actions per day, that is to say, if you sent 400 friend requests, you wouldn’t be able to message anyone or anything…
LastFM doesn’t seem to have much trouble with unwanted spam. I have a few friends on Last.fm that spam me, but it’s all good spam (decent or great music to check out).
I’m basing my number, 100 on the fact that I got through two, fifty-user pages before the requests stopped working.
UPDATE: Two days later
After Midnight PST, was able to send 100 more friend requests.
But after Midnight the following night, I was only able to send around before they stopped working. I added a thread on Last.FM’s community/support forum here.
Maybe someone will shed some light on this. Search engine results for this problem are horrible.
(Thanks for the tip-off, Kim Flournoy!) MailPress seemed to be causing an error whenever someone would try to post a comment to my site. The comments were actually getting through, but the commentor would see the mess of PHP errors below.
Upon deactivating MailPress, submitting a comment would result in a blank white screen (called a white screen of death in some parts). I deactivated AJAX Comments (just a hunch) and the blank screen was fixed, and I was able to re-activate MailPress without any problems. To summarize,
The problem is AJAX Comments, not MailPress, or at least the two don’t play nice together. I choose MailPress as the one to keep and AC as the one to blame.
Warning: fsockopen() [function.fsockopen]: unable to connect to ssl://mail.my-website.com:0 (Failed to parse address "mail.my-website.com") in /my-website/path/public_html/etc/wp-content/plugins/mailpress/mp-includes/Swiftmailer/classes/Swift/Transport/StreamBuffer.php on line 233
Warning: Cannot modify header information - headers already sent by (output started at /my-website/path/public_html/etc/wp-content/plugins/mailpress/mp-includes/Swiftmailer/classes/Swift/Transport/StreamBuffer.php:233) in /my-website/path/public_html/etc/wp-comments-post.php on line 95
Warning: Cannot modify header information - headers already sent by (output started at /my-website/path/public_html/etc/wp-content/plugins/mailpress/mp-includes/Swiftmailer/classes/Swift/Transport/StreamBuffer.php:233) in /my-website/path/public_html/etc/wp-comments-post.php on line 96
Warning: Cannot modify header information - headers already sent by (output started at /my-website/path/public_html/etc/wp-content/plugins/mailpress/mp-includes/Swiftmailer/classes/Swift/Transport/StreamBuffer.php:233) in /my-website/path/public_html/etc/wp-comments-post.php on line 97
Warning: Cannot modify header information - headers already sent by (output started at /my-website/path/public_html/etc/wp-content/plugins/mailpress/mp-includes/Swiftmailer/classes/Swift/Transport/StreamBuffer.php:233) in /my-website/path/public_html/etc/wp-includes/pluggable.php on line 890
Badass. Just looked at his site and the Footer of the site says:
Copyright © 2010 Dr. Dre “Detox” – The most anticipated Hip Hop album ever. Running on WordPress | Theme developed by rsuog.
Cool. WordPress is big.
From the WP Dev Blog, Matt Mullenweg giving his ‘State of the Word’ presentation. Very cool. I’m really excited about where WordPress is going.
When I get asked for help with an attack on a WordPress site, it’s often on the same few hosting providers. And when it’s not, it’s usually a small, local hosting provider. When I have spoken to the staff of one of these hosting providers, about what seems to only occur in these few situations, they never take responsibility for having oddball server settings. And it’s not uncommon for them to actually blame their customers for using WordPress in the first place!
Some of the more popular Hosting Providers that seem to have more trouble than others with WordPress malware attacks in the past two years (in my experience) are Network Solutions and IX Web Hosting. And in general, hosting providers that have a lot of issues with malware affecting WordPress sites either
As for some of the local, ma ‘n’ pa providers I’ve had problems with, I’m not going to hit them when they’re down by naming names. But let me just say this: Buying local isn’t necessarily a good idea when it comes to hosting. It’s often the worst thing you can do. You usually get crappy support, a high price, a non-standard product, and to make things even worse, you also often get a territorial ‘server guy’ who wants to blame any technical problems on the customer and not take responsibility for anything.
I can imagine being a hosting provider and not wanting to change how I do things just because a few of my customers want to run some weird PHP software they found somewhere. But WordPress is hardly obscure anymore. And although I could be wrong, it seems that the server settings required for a smooth, safe ride with WordPress are in line with “best practices” for hosting providers in general, since all the best and most popular hosting providers seem to run WordPress perfectly.
So in the ‘news,’ I guess on April 12th, 2010, someone (rshinsec) at Network Solutions announced that an attack on many of Network Solutions’ customers’ sites was actually caused by a “WordPress Vulnerability.” (Quote is actually from a WordPress.org page HERE, because according to the WordPress.org page, Network Solutions has since edited the announcement)”
“Beginning last week a WordPress vulnerability has been the target of attacks on multiple WordPress websites on hosting platforms around the web. We have a blog post with additional details about the vulnerability and how to secure your WordPress site.”
In fact, it was not a WordPress problem at all. So in response to some of the inaccurate anti-worpress blogosphere chatter caused by Network Solutions passing the buck like this, Matt Mullenweg, founder of WordPress posted to the WordPress Development Blog, clearing some things up, as well as putting it like this:
“Summary: A web host had a crappy server configuration that allowed people on the same box to read each others’ configuration files, and some members of the “security” press have tried to turn this into a “WordPress vulnerability” story.”
Thank you Matt! We the people that use and love WordPress need to stand up for ourselves and demand what we deserve. We are not a fringe community anymore. WordPress is mainstream software and any hosting provider that has issues with it needs to check themselves!
Loading...
2012 andrewapeterson.com. Proudly Powered by WordPress. Design Based on the "Twelve" Theme.