mrarrow

Except .taxonomy-drilldown-dropdowns li { width: 120px; float: left; display: inline; } would set the width of the whole line so you’d still need a method of setting the width of the label and therefore dictating where the dropdown appears i.e. in line with each other.

Absolutely brilliant, nice one – that’s fixed it! There were two incidences that had to be changed in that file.

Maybe in a future release, this might be a worthwhile option to add as a configurable item within the backend widget interface (and in the php code)?

I know it might not make immediate sense but once you see it in action, then I reckon its a valid request (at least to me!).

That way, you still have the option of drilling down further on the search result page (as all the original dropdowns still have their values in them) or you can reset it and do a new search (I now just need to make sure the Reset button doesn’t take me back to the home page – i.e. it keeps me on whatever the current page is).

Once again, thanks very much – its much appreciated.

Because once a user has done the intial search by selecting multiple dropdowns and is viewing the search results, then in my case, they have no need to further drill-down, as the results are pretty self-explanatory.

And considering I was initially confused as to why this code was ‘losing’ dropdowns after a search (I thought it was the theme to start off with!), my “beloved” users are going to be even more befuddled.

I take it its not simple to stop this behaviour then?

Many thanks.

OK, well it seems I’ve now bottomed-out this issue.

When I have Defensio 2.5.8 network activated, new sites don’t create the required tables. If I network DEACTIVATE Defensio, I can then create a new site and everything behaves as expected. I then simply reactivate Defensio and all works well. Errrmmm……

I have noticed that in PHPMyAdmin, all of the Defensio entries (e.g. wp_2_defensio, signature, status, classification etc) are all latin_swedish_ci in the collation field. Whereas everything else in the d/b is utf8_general_ci

So I’m wondering if this is the cause. Needless to say, I’ll be getting in touch with Defensio again (2.5.9 was partly because of me!)

Yes, i can create tables manually. I run my own vps so i set any restrictions and there aren’t any on that account.

As i say it all set up correctly. Just not new subsites

The exported file came from a standard wpmu 2.9.2 install not a single wp and was just done via the normal tools > export feature.

OK, well I thought I’d report back as to my mind, this is a serious pain in the… Everyone around the web is saying, “Oh just use the relocate command” or glossing over the actual nuts and bolts of doing an SVN upgrade from 2.9.2 to 3.0, but this is all BS. I’m sure there’s some very good technical reason why subversion fails when upgrading from 2.9 to 3.0, but it aint very considerate.

Anyway, MrBrian you can’t simply delete the hidden .svn directory and checkout the new code, as during the new checkout, Subversion complains that there are already files of the same name in the location you’re trying to use. So you end up having to delete all the existing files, in any case.

So, the only way I’ve found to do is as per Ron R’s suggestion, that you have to backup the custom directories (themes, plugins etc) and then do a new install. So deleting all the existing files/directories and doing a new CO with the WP 3.0 code.

Which is quite frankly nerve-wracking enough on a development site, let alone on a clients live site.

I’ve only just switched to using Subversion in the past couple of WP releases coz I wanted to get away from having to do exactly this type of procdedure (and having a nice fall-back to a previous release if a something goes screwy in the process). Turns out that at least for this release you gotta go back to manually moving/deleting files, and there’s no going back once you’ve gone to 3.0… 😐