araneo

Manual installation seems to have worked fine. Is there a way to test it, i.e. to deliberately trigger moderation?

tomatoma and kapeka’s trick solved my problem as well.

This has to be a bug, right? I can’t see why it would be deliberate, unless maybe to stop an infinite loop, but there should be better ways to control that.

Thanks. Somehow I had the 1.2.1 version in there.

Update: after adding xmlrpc.php, pingbacks do work; but trackbacks still do not.

There was no xmlrpc.php in the 1.2.1 installation, indeed, but that does not seem to be enough. I added it from 1.2.2 but it still makes no difference (and anyway it was there in the 1.2.2 test installation.)
Looking at wp_posts with phpMyAdmin, I can see that the trackback URL is saved in the field “to_ping” of the referring post, but it does not cause any pingback or trackback to show up in the referred post’s comments.

I reran upgrade.php. I have now the ‘active_plugins’ row, with the plugins listed.
“Hello Dolly” now works, so the basic mechanism is working, but “Adhesive” still does not work: there is no ‘sticky’ checkbox in the Post Status area. (I tried both 1.5 and 1.6alpha.)
I haven’t tried the others, since they require changes to the basic code.

Is it harmless to rerun it? I’m clear on what it does exactly, there are so many functions that it would take me hours to trace everything, and I wouldn’t even be sure I hadn’t missed something.

It was an upgrade from 1.2, but I had not played with plugins then so I have no idea whether they worked or not.
I have phpMyAdmin running, so I can easily add a row manually but I need to be sure that’s the right thing to do!
Anyway, shouldn’t plugins.php barf loudly when it tries to update a row that does not exist? I get no error message at all, quite the contrary it returns with a success message!

OK, I did some more digging. From what I can figure out, the list of active plugins is supposed to be kept as a concatenated string in table ‘wp_options’, in a row called ‘active_plugins’. There is no such row in that table! Help!

I just encountered the same problem in 1.2.1. The plugins appear to activate, they get bold and “activate” changes to “deactivate”, but nothing actually happens. (I tried Adhesive, todayAgo and nextPreviousDay.)

> I am now tracing post.php …
And the error seems to take place in auth.php.
Somehow, the authentication cookie is stored with one path information (which turns out to be a logical link to the actual directory) while the script that uses auth.php appears to attempt to retrieve it using the path stored in “siteurl”, which is different until I commit the upgrade. The result is that it is impossible to test a new installation in parallel with an existing one. That’s not good for something so highly customizable.

> You installed ‘in parallel’ – does each install share the same table?
Yes, they do. Or they should. Obviously something isn’t right, since the login script for 1.2.1 writes in its base directory in “siteurl”.
But even after I fixed that back to 1.2, the login from the original 1.2 installation (nothing changed, worked perfectly less than an hour before the 1.2.1 test) is still not working.
I have walked through the entire wp-login.php and found that the problem is NOT there: the script authenticates the login properly and hands off the followup to the normal redirect …./wp-admin/post.php via the header function at line 132: header(“Location: $location”);
Then, something inside /wp-admin/post.php bumps me right back to wp-login.php with the following URL (broken for clarity):
…./Blog/wordpress-1.2/wp-login.php?redirect_to=%2F
Blog%2Fwordpress-1.2%2Fwp-admin%2Fpost.php
I am now tracing post.php …

I am in the process of walking through wp-login.php.
So far, everything looks OK, and I have ascertained that the passwords stored in the database are the correct md5 hashes of the original passwords for all the users and the admin. Whatever the problem is, it’s not that.

That’s it! wp_post2cat was bad. I refilled it from the data in b2posts (since each legacy post had only one category, it was a one to one update, very easy.) It seems to be working now; back to customization.
Thanks to all for the help.

Another hint: when I look at the categories with wp-admin/categories.php they are listed as they should except that the number of posts in each category is wrong: only the default shows 1, presumably the test post created by the installation, while the other two categories show zero. I looked at wp_posts with phpMyAdmin and the post_category column is properly filled with the correct category number for each post.