mcbalz

I have three WP blogs. Two upgraded automatically just fine. A third let me click on the “automatic upgrade” button but didn’t get any further than the output line saying that it was downloading the .zip file. Why did the auto upgrade stall out? No error message. It doesn’t sound like the same issue.

Working with a client I just discovered a similar iframe malware insert in a number of php files including wp-login.php… this one was at the first line of the files, prior to the first <?php mark.

This was causing users who accessed the website using a PC to have their anti-virus software issue a warning… and it prevented admins from logging into the site.

By deleting the code from a number of files via the control-panel I was able to log back in, upgrade WordPress, change the passwords for all admin-level users, and hopefully prevent further changes to the .php.

I also deleted a subscriber account I didn’t recognize and checked the MySQL database to make sure there were no stealth users.

But I wonder whether or not this code is coming in via the web-based blog interface (i.e. using an admin-level account) or via some compromise of the hosting account? Any thoughts on this?

Michael, I really appreciate your patience and persistence here. You are an IT god.

The answers to your questions are:
yes
NO (I didn’t realize this before, but you caused me to check)
yes

So, in the new, working, but empty WP install, I corrected the $table_prefix in the wp-config.php file. Then I deleted all the tables in the new, working but otherwise empty database. And I imported all the old tables, which had the different table prefixes.

Now I am going to test the thing… drumroll please…

No, I am so sorry… it doesn’t work. A blank screen comes up, that’s all. Why is this happening?

*** later ***

I finally did make this work… by tinkering with the existing tables in the new install. Here’s how I did it.

First, I once again deleted all the tables inside my database, and ran a fresh install on the WP 2.8. What I learned from doing this (3 times before I got everything right) is that the “5-minute install” process is designed to take an empty database and set it up with the appropriate table structure. (Therefore, If you first delete the tables in your MySQL database and then try to open up your blog, it will effectively reinstall itself; like I said I did this about three times).

Trying to import the old tables into the new ones did not work. There were errors in the import. The inner structure of the tables did not match. It turns out that the backed up tables from my old blog were not created by a WP 2.8 install. What version was out in the days immediately prior to the official release? That was what I used.

Anyway, the result was that the WP_links, and the WP_Options table were both incompatible with the new release. But what I learned in the process was that the data had partially imported. I got working comments, but not working posts. It was importing the tables alphabetically and quitting (exiting the process) when something incompatible came up.

So what I did was I took a copy of the MySQL database dump file from the previous version and, using a text editor, deleted all the data relating to the options, links, and users tables (4 tables) leaving the relevant tables only for comments, posts, and terms (6 tables).

I then deleted all the comments, posts, and terms related tables on the new install. Then imported the copy.

BINGO. My blog is up and running. Time to customize.

https://eschata.apocryphum.com/

I should clarify my last post… my new WP install is now dead because I deleted the old tables and imported the new ones in their place. Strangely, they did not import with the proper names (they added a “2” in front of the names, i.e. wp_2comments instead of wp_comments). I renamed the tables to wp_comments, etc.

But a completely blank browser window is all I get. WordPress ceases to function entirely.

Also, there doesn’t seem to be any way for me to get it back, short of recreating the database entirely from scratch, and reinstalling a freshly unpacked WP from the .zip. In other words, starting really from the beginning again. Which leaves me where I was.

Michael,

I am (or rather, have already) moved to a new site. I was forced to do that. At present, it is a totally blank WP install, with no custom theme and only one post… “Hello World!”

There’s no way, it seems, for me to access the old tables as a normal WordPress site… they are a .sql file. That is the only form in which they exist.

But if I delete the new tables in the new database, then import the .sql file containing the old tables, the site doesn’t work. A blank screen comes up.

What do you make of this?

MCB

Michael, I followed the advice at the link you provided, but it just duplicated all of the database categories, now titled wp_2comments, etc… when I run the new installation it doesn’t find any of the old posts.

In other words, the instructions there allowed me to import the 10 old WP SQL tables into my new database, as ten ADDITIONAL tables. But how can I get WP to recognize them?

Michael, how can I get the database information into a WP installation?

I had this problem and, through my inept tinkering, ended up actually completely destroying both of my new 2.8 blogs. Turned out it was a php memory limit set by the service provider and NOT customizable by me. The 8 MB limit my provider gives is not enough to run WP 2.8.

I was running only ONE plug-in (Akismet), and I had small databases (less than 2 MB each) but I still couldn’t run WP 2.8 on account.

I think this is a major bug that the WP development community needs to fix. I want to use WP… it is clearly the best… but at present I just can’t do it. Also, after porting over to my self-installed WP blog, I deleted my old blogger blog, and after this fiasco, all that I have left is the MySQL database. My old blog is now totally off line.

I’m feeling kinda bitter about this issue.

bh_WP_fan… none of the solutions you have mentioned work for me.

The wp_config.php fix seems to do nothing.
(Also tried the parallel suggestion to change the variable in the wp_spettings.php file).

Changing .htaccess results in a server 500 error.

I can’t find any php.ini file.

I don’t think this is a true memory issue.

I have two blogs on my domain. Both are having the same issue.

Both were working fine yesterday… AND I DID NOTHING TO CHANGE THEM since then.

Both blogs are using MySQL databases that are each well under 2 MB. Mind you, these are small blogs. There shouldn’t be a problem with memory allocation.

I have searched the forums. The solution suggested by Shane G causes my server to fail with a “500” error.

I have also tried changing the define memory limits variables in the WP settings files and had NO luck.

Incidentally, my databases are well under 2 MB. This appears to be a bug. What’s going on?

MCB

I have two separate WP blogs that were working fine yesterday, and today are crashed out, giving the following error (each is slightly different in the numbers, but the same message).

Blog One:
Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 4864 bytes) in /home/mcbalz/public_html/eschata/wp-includes/default-widgets.php on line 613

Blog Two:
Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 19456 bytes) in /home/mcbalz/public_html/training/wp-includes/default-widgets.php on line 547

I am having this problem but I haven’t been able to fix it by changing he wp-settings.php file as suggested in one Forum thread.

I have checked the MySQL databases and both of my blog databases are well under 2 MB! These are small private blogs.

This is emphatically NOT a problem related to the size of the actual database… what is going on?