WordPress MU

DeannaS I just found this ticket. A comment from Denis-de-Bernardy says, "I only ever got this once, when I tried to click save draft while the autosave was still running."

Any chance this happened to you? Can you tail your log file and see if the autosave has kicked off?

Hi Donncha,

Non authenticated hitting http://domain.com/wp-admin -> wp-login.php after logging in I am redirected to the mu homepage but does not allow access to the dashboard. Previously with 2.8.6 it would redirect me to the dashboard after logging in.

If I hit SSL initially https://domain.com/wp-admin it works I can access the Dashboard.

So it seems the define(FORCE_SSL_ADMIN, false) is not being recognized?

-scott

Donncha, indeed I've installed 2.9.2 on a dev site with my normal load of plugins, and haven't encountered any specific issues. I'll try to do some additional testing this afternoon if there's anything specific that still needs looked at. I meant to say in my earlier post about testing the image editing and insertion that everything worked as it should, just a funky UI for cropping images which seems to be the intended behavior.

Running tail while I try to do an add I get:

(A whole bunch of stuff loads when I first hit the post.php page, but once I start typing I get...)

POST/ test2/wp-admin/admin-ajax.php (a few times)
GET /test2/wp-admin/images/button-grad-active.png
POST /test2/wp-admin/post.php
GET /test2/wp-admin/css/install.css

So, the admin-ajax.php calls look to me like it's doing the autosave.

I also get the "Draft Saved at..." message in the editor window.

DeannaS - I reinstalled and still can't see that error. Can you email me at donncha @ ocaoimh.ie with login details so I can try this myself and attempt to debug it?

skinnydog - tried to install ssl support on my test server but it killed my virtualhosts, including some live sites unfortunately. May try again tomorrow.

not sure if this is new to 2.9.2 or something that's been around awhile, but in my test install with the 2.9 branch checkout, if I have a site admin in the backend of a blog it's not a user on, and try to edit that site admin's own account via Site Admin- > Users, I get a Call to a member function has_cap() on a non-object wp-admin/includes/user.php on line 80.

If this isn't something 2.9.2 specific, are we reporting bugs in the regular wp trac?
Seems there should be some kind of UI to say "you don't have permission" or some other graceful error than that.

OK, so this seems to be not 2.9.2 specific. So the question is where should this be reported, the regular WP trac?

miklb - I've managed to get that error and I've seen it before, usually when a $user object isn't an object. Looking for a fix now.

Probably worth reporting it on http://core.trac.wordpress.org/ too of course, thanks!

We had that has_cap problem before but the promote function is gone now. Hmm.

Donncha, thanks, I just checked out trunk for WP 3.0, and indeed the issue persists there, so I'll indeed open a ticket.

So, 3 known bugs in 2.9.2. 2 are edge cases involving site admins that 99% of users won't see and there's also the ssl bug that has been around for a few versions but I only found out about in this thread.

I've had no luck getting an ssl capable webserver running so I can't debug the ssl problem very well, I can't replicate the edit page problem, but I saw it happening on DeannaS' server and editing the site admin has probably been a problem for a long time but nobody noticed.

Regardless of whether we fix those problems over the weekend I'm going to release MU 2.9.2 on Monday. It's a security fix and has taken long enough. I'm Very very glad more people tested it before release. At least we know about these problems now. Thank you all!

Ok, I lied. No release today. I had this to work on. It's a "Global Terms" page for site admins.

Currently all it has is a fixer function to sync up broken taxonomy blog tables with the sitecategories table. Update your SVN from the 2.9 branch and please test it.

Open up a blog's terms table and change the term_ids around. Load up the Global Terms page and enter that blog's blog_id to fix it. When you look at the table again they should be fixed.

It doesn't try to fix taxonomy records where the slug is different to the name.

Okay, maybe I'm not understanding what the global terms thing is supposed to do. But, here's what I did:

Create a term in blog 2 called "Test Category."
Log in to phpMyAdmin and change "Test Category" to "I am a changed category"
Go back to the Global Terms page, enter blog 2 and click "submit"
The code successfully changed the slug to match the new term, but did not do anything in the wp_sitecategories table. I would think that it would either edit or add a record in the global terms table when it updates the local term. Yes? No? If I change a category through the blog's interface, it does change it in the global terms table.

Am I missing the boat?

Just edit the "Test Category" record in your blog's terms table and change the term_id. That page should sync the term_id with the cat_ID in sitecategories.

Nope, that didn't really seem to work either.

Blog's term table:
Old Settings
Term ID = 5
Term = "I changed this category"
Slug = "i-changed-this-category"

Php MyAdmin - set those to:
Term ID = 6
Term = "This is cat 6"
Slug = "i-changed-this-category"

Press global terms submit button

Blog's table set to:
Term ID = 5
Term = "This is cat 6"
Slug = "i-changed-this-category"

Global Terms Table set to:
Termid = 5
Term = "I changed this category"
Slug = "i-changed-this-category"
Termid = 6
Term = ""
Slug = ""

Remember what I said about the slug being different to the name? It will only update the term_id, which it did, changing it back from 6 to 5.

Just updated the page so it renames the term name if it doesn't match the slug so it'll handle the situation above. Thanks for testing :)

Interesting. I see that you decided to change the term name to match the term slug, and not the other way around. I'm not sure exactly when this would be used, as I've never encountered any problems with the blog terms and global terms getting out of wack. But, it would seem to me that if someone changed the term name, they'd not want to lose that change and they'd want the slug updated to match the term.

So, maybe just some more explanation on the admin page for the checkbox.

I'm also still seeing the odd behavior that if you change a blog's term and then click the fix terms button (without checking the box) and extra blank entry gets created in the global terms table.

I change the term name so that URLs won't break. On MU sites users can't change the name without changing the slug. That's not the case with regular WP blogs of course.
I'm not sure how WP 3.0 will handle this. I'd love to get rid of this limitation.

Thanks for the feedback, must look at sitecategories and I'll update the page with more docs.

I saw the blank entry in sitecategories too but can't replicate it any more so maybe that was fixed by something I did since then. :)

I can replicate it (just did an svn up).

1. Edit a blog's term id via php myAdmin.
2. Do not check the "rename terms" box, but click the fix terms button.
Voila.

Tried that and can't replicate it any more. I was about to tag 2.9.2 too, but let me try this again a few times.

EDIT: Change the term name and term_id and a blank record is created :)

You don't have to change the term name if the term name is already different from the slug, either. (Just trying to canoodle all possibilities.) (I did just svn up and it still creates the empty row that way.)

Can you svn up again? The latest code should stop the empty records as it does some sanity checking of the term in global_terms. The Global Terms page itself now only checks the sitecategories table for slugs now.

Don't hate me. :)

Okay, we're no longer getting the empty row. Yay!

But here's another wee little oddity (and this might just have to be the way things are)...
1. PHP myadmin - edit the slug and ID of a blog's term
2. Check the fix term box and click submit

A new record gets created in the site categories table, with the next incremented ID. The edited row in the blog's category table gets set to the new site categories ID. The name in both tables becomes the slug.

1. PHP myadmin - edit just the slug (or just the ID - both result in the same thing)
2. Check the fix term box and click submit

A new row is created in the site's category table with incremented ID, no term and the edited slug. The blog's row ID gets change to the new site category's id.

Thanks DeannaS, just got that fixed. I think that page is now working ok! :)

Hello! I am sorry i do not know if this is the right place to post this, but I am having problems with tags and categories and it's driving me crazy. Just 2 or 3 of them work fine, the rest of them when i click on any, it sends me to a different page(this happens with both either category or tag), or it shows the home page, plus the tags in english are not showing, only the ones in spanish (my site is bilingual).
I had wpmu 2.9.1, and upgraded to 2.9.2 but nothing changed, I still have the same problem. I also have buddypress 1.2.1 installed.
does anybody have any idea of why this is happening. help please :-( .

My site is: http://ikeesh.com
in case somebody wants to take a look at it, to see what i'm talking about. can somebody tell me how to fix this?
thanks in advance.

ikeesh, I think you'd have more luck getting a reply if you open a new topic/thread instead of replying to the end of an unrelated thread.