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)
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.
(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!
The site links to sites who are also under attack and when the bug is running correctly on those sites, the sites redirect the hits to the final destination,
which is http://www.zml.com/
I don’t know if zml.com knows this is happening. I mean I suppose it’s possible that some unscrupulous SEO or Marketing guy promised them traffic and then resorted to this to get it. I’m contacting them now to inform them of this uncool practice being committed on their behalf, and if they are not willing to cooperate on putting an end to it, I will have no choice but to give them some negative attention.
The process of extracting the bad links from the content was long and hard since the strings of code inserted were very inconsistent.
The following is a list of the sites being linked thru, which I assume are all victims of this malware. If you own one of these sites, feel free to drop me a line and I will point you in the right direction as far as putting an end to this.
Message to ZML:
Hello,
I am a developer and recently one of my clients who is running WordPress for her personal website was attacked by some Malware that inserted thousands of links throughout her content. Those links resolve to your site, but via redirects thru other sites that I assume are also victims of the malware.
You look like you’ve built a pretty nice site here. And I’m writing to give you the chance to get on board with fixing this problem before I am forced to create some negative attention in the blogosphere and social media.
It doesn’t seem like you would want to be resposible for malware. But it also doesn’t seem like anyone would go through the trouble to make all these links back to you unless you were paying them. Perhaps you hired some marketing or SEO people and were not aware that they would be using these tactics? Please write back soon as I have very little patience for this kind of thing.
Thanks,
Andrew A. Peterson
Some samples of weird code that the bot inserted:
<wp:tag><wp:tag_slug>%d0%b0%d0%b2%d1%82%d0%be%d1%80%d1%81%d0%ba%d0%b8%d0%b5-%d0%bf%d1%80%d0%be%d0%b3%d1%80%d0%b0%d0%bc%d0%bc%d1%8b</wp:tag_slug><wp:tag_name><![CDATA[????????? ?????????]]></wp:tag_name></wp:tag>
<wp:tag><wp:tag_slug>%d1%81%d0%b2%d0%be%d0%b1%d0%be%d0%b4%d0%bd%d1%8b%d0%b9-%d0%bc%d0%b8%d0%ba%d1%80%d0%be%d1%84%d0%be%d0%bd</wp:tag_slug><wp:tag_name><![CDATA[????????? ????????]]></wp:tag_name></wp:tag>
UPDATE: After about four hours of hunting, I finally found a way to enable CodePress in WordPress! A plugin called Enable Codepress does just that! It only seems to work in FireFox, but it does work with WordPress 2.8.4
copy of a comment I left HERE, a tutorial having to do with adding line-numbers and syntax-highlighting to WordPress’ text-editor.
Wow. I am so frustrated. I have spent the last four hours trying to find a way for me to endow my clients, whom I have set up with WordPress, with the power of line numbers when editing CSS.
WordPress is nearly FTP-free, which is great for lay persons. I’ve had great results with teaching older people how to use FireBug to find and preview changes in their CSS by right-clicking on what they want to change and selecting “inspect element.” And it’s not too difficult for many of these folks to get into their Stylesheet in WP’s Theme Editor and find and change what they have tested in FireFox.
But would make the workflow a thousand times better would be a way to make the Textarea in the Theme Editor disply Line-Numbers. There are a handful of plugins that claim to do this, but none of them seem to work with WordPress 2.8.4 And in my hunt, I’ve found evidence that WP once had this feature briefly, but turned it off because it was too slow. I never noticed it and I’ve been using WP for years, and have always been up to date.
Now I find this blog post. Great. A hack to turn on the CodePress functionality in WordPress 2.8… The problem is I don’t understand how to do this!
Can’t you just make an installable Plugin? A plugin would be great because it would be nice to be able to turn the thing on and off, if it is indeed slow or buggy.
Or if some manual intervention with WP’s files is necessary, could you please-please-please explain which files you are editing in this tutorial? All of the examples show top line numbers (1, 2, 3). There’s no “this is what the whole thing should look like” …You don’t explain what file or files you are editing. This is so annoying because I’m not a programmer and this how-to assumes that we know certain things that I don’t know.
could brave these steps if I knew where to make them. I have been searching for this post for hours only to find that I’m not smart enough to understand the directions!!! Thanks for your consideration and for sharing information, even if I am ineligible for it.
Loading...
2012 andrewapeterson.com. Proudly Powered by WordPress. Design Based on the "Twelve" Theme.