petersig

Another reason for a slow site is bad code in the header, the footer, or even the posts. One of my blogs was shut down by the host, because of an extreme overload. It is so very unlikely that this blog was slashdotted, that I checked further.

I’m using WP 2.1.2.

I looked at all 12 or 15 posts, and found that one post was empty, that shouldn’t be. I then went to the admin panel and looked at mmanage, and pulled up “edit” for the post just to see if it was still there. It was: with the original post, plus pages and pages of links – like having an akismet file with 1500 links, all at once. After emailing back to security at Hostgator, that I had found the problem, and what it was, I looked further. How could someone mutilate a post? He or she would have to have admin privileges, so I looked at the Users and the profile sections. Sure enough, there was a user listed as “WordPress” at http://www.com, who had admin privileges, and who had written some additional javascript code in the Users panel.

The beginning of such code intrusions is a <u style="display:none"> command, and then the pages of links that would overload any server. I’ve seen that, or similar, do not display commands when I’ve found code in the header or the footer or the sidebar that doesn’t belong.

This time, because the user name has a domain, he or she can be tracked. I guess the scare tactic to use is a “copyright violation cease and desist letter, followed by an appeal to the hosting service.

Yes, indeed, it’s in the footer.php file, and very hard to remove. I learned I had the file when running a “see your site as google bot sees it” simulation. Meso*elioma.com turned up at the very end of all the links, completely unrelated to the topic of my blog. Then I googled blogname + meso*elioma and found that it was on all my permalinks + pages. Googling gave me the text that was actually being displayed, which pointed to the theme’s footer. Then I went to “view” on the menu, and found “view source.” In View Source, drop down to “Page source”, click it, and a window of all the code opens up. Go to Edit, drop down to “Find in this page,” and type in meso*elioma, that mellifluous word.
It will show up, believe me.
Now the task is rooting it out. Actually, for this exploit running in WP 2.0.4, commenting out all the extra php from the Andreas 04 theme worked briefly, but I went back and checked again, and the SEO killer word was there again.

What I have now done is to eliminate all code from the footer.php file. I also moved the call for it down below the Google Analyticator code in the Main html file in your theme, but that may not make much difference.

Unless somehow this blank file calls a file from a website without my being able to see it, that should work. I will type in the credits that normally go in the footer and put them on my sidebar.

The affected/infected blog is
http://www.formytummy.com/

I don’t know how it got there, or what was compromised to get it there, so what further fixes my blog might need are up in the air.

Miklb,
I *did* have a thread to mark [resolved] today. I left a post indicating (actually) that I had resolved the problem myself, and what the solution was. Then I saw your post and went back looking for a way to mark the thread [resolved]. I couldn’t find any way to do that.

Find your css or style.css or stylesheet file, in the Admin section “Presentation” / Themes Themes Editor – pick Themes Editor. Any well-made theme will have as its first file the Stylesheet file.

Since we know from your complaint that there’s only one font operational for your blog, then it’s usually true that:

The font is declared in the first block of the Stylesheet, in code that looks like this:

body{
margin:0;
padding:0;
font:76% tahoma,verdana,sans-serif;
background:#e6e6e6 url(images/bodybg.png) repeat-x;
color:#333;
text-align:center;
}

Look for a line similar to the one above that says `font:76% tahoma, verdana, sans-serif;’

At this point, supposing that you see roughly what I see when I look at my Stylesheet, it is an eminently intelligent, swift, smart, good idea to make a backup copy of your theme, by finding the WP-Content folder in your WordPress installation, opening it, and finding the Themes directory, then opening that and locating the name of your them. Then the ftp program that has shown you this will allow you to “Download” to your own computer, maybe in a file with your blog name–on your Desktop, not your Documents file.

Now, back to the stylesheet:
Don’t change the size of 76% in that line declaring the fonts, or you’ll be in worse trouble than you are now. In the following part of the line you see the names of two or more fonts. In the theme I’m using as an example, there are two font names, and then a font type, which is san-serif.

In HTML (of which CSS is a part) this is a way of letting a browser find a font to use, if neither of the first two fonts is available.

The simplest fix is to pick the fonts you want and put them in the place of the ones that your Stylesheet is declaring.
Then scroll down to the bottom of the window and look for the button outside the window that says “Update File.”

Your Stylesheet will be updated with the new fonts.

Anything more than the simplest fix such as this, and you need to be working with a CSS manual handy.

Much success!

See below for today. I had posts doubling.

Quick checks.

Does this happen when you switch to another theme.
If it doesn’t show up in another theme, then (I think) the problem may be in the index file of your theme.

Look for and identify The_LOOP. If you don’t know what it is, see the Codex.

Then look for anything within The_LOOP that occurs more than once. To check, use comments; <!-- before what looks like something extra, and --> after just that line.
Then hit the button to update your code, and hit the <view site>.

If that worked, you should be seeing either single or double. If single, then you are fine. If you are seeing double, there might be another extra line of code in The_LOOP (particularly “content” lines in PHP code).

—
If those things don’t work, then MichaelH has the right suggestion, about plugins.
To troubleshoot plugins, take them one by one.
Do this:
Deactivate the plugin
Check <view site> if your blog is still in quadruplicate.
If it is, reactivate the plugin.
Repeat until you either find the plugin that is causing problems and deactivate it, or you run out of plugins.

Just in case it’s more than one plugin, note where you stopped.

I use 17 plugins, plus or minus 3, and just spent the afternoon deactivating and reactivating all of them to trouble shoot a problem.

The real problem is that the plugins, and the hacks to the theme that I’ve done, prevent me from upgrading from WP2.04 to anything that does, for example, support widgets. I spend time downloading and checking out plugins that *say* they are compatible with 2.04 but that actually need widgets to function.

That idea, of paying someone to do the work, looks attractive. Given the low current and expected return from this blog I’m working on, all it would do is give me more time for my day job–which I desperately need.

I do pay for the hosting and the bandwidth, and have other blogs with later versions of WordPress (2.1.0 so far) that are easier to manage.

What I would be willing to do (assist with) is developing a database of which versions and plugins work together. AND update the plugin listings accordingly. Also, a wayback machine for plugin versions that *did* work with earlier WP versions would be good. And yes, I’ll send a copy to the wp.org/extend/ideas site.