rcwatson

Never mind. I figured it out after finally finding this post.

Here’s what I did (currently just one case statement, but going to grow)

$postid = get_the_ID();
	$sidebar = '';
	switch ($postid) {
		case 55:
			//$sidebar = 'custom-widget-area';
			if ( ! dynamic_sidebar( 'custom-widget-area' ) ) :
			endif;
		break;
		default:
			//$sidebar = 'primary-widget-area';
			if ( ! dynamic_sidebar( 'primary-widget-area' ) ) :
			endif;
	}

Thanks.

Any ideas? Anyone? ??

Cool. Thanks for the quick responses.

My first choice was a direct upgrade, but I made some mistakes in managing the 2.9.2 instance that need to be wiped clean and started over.

Plus our environment is a shared one with other enterprise groups, which meant that someone else was managing our OS patch upgrades. After our WPMU server completely failed during one of those upgrades, we decided to split the shared environment into Dev and Prod systems so that OS patches could be tested on Dev to make sure they didn’t kill WordPress. Since the Dev environment didn’t exist prior, and the network tech didn’t have the time to replicate WPMU 2.9.2 on it so we could attempt a direct upgrade (only enough time to drop 3.0 on it), we had to opt for the fresh install and migration.

See, told ya’ it was complicated. LOL

I’ll take your word that the database structure is the same. But one item I neglected to include (sorry) was the fact that we’re changing the table prefix on the 3.0 instance for security purposes and so that it matches what will be our not-yet-installed 3.0 Production instance so we can easily script a mirroring of the data between the Dev and Prod environments.

Will we be able to globally find/replace the table prefix in the exported SQL statements before importing the WPMU database to 3.0 and not experience trouble? Any exceptions to that find/replace that you know of?

I figured it out. I had thought I deleted it from the mu-plugins folder when trying to put it in the regular plugins folder, but it was still in mu-plugins, so they were fighting for control leading to the error. Now just in mu-plugins.

Thanks.

Joost: I can’t get the latest version of the Slideshare plugin to display this presentation.

I installed and enabled the plugin from my own hosted version of WordPress 2.9 standalone and used the following embed code:

[slideshare id=2618863&doc=socialmediatimemanagement-091130193219-phpapp02]

I just get a blank content area with no slide.

When I installed the plugin, the plugin info page said it has not been tested with 2.9 and is compatible only up to 2.8.4. Is it yet not ready for WP 2.9?

There’s a paid solution for domain mapping in subdirectories as well which I haven’t used.

What is the name and URL of said paid solution? I’m interested in using this for the following scenario:

root blog:
https://www.examplecompany.com

branch blogs:
https://www.someothercompany.com
https://www.completelydifferentcompany.com

Would that be possible using the paid solution?

*bump* anyone find a fix for this? it’s totally putting egg on my face for an install I was promoting as a solution for content workflow. this was a critical component of that workflow. any help would be appreciated.

Thanks.

Ah, okay. Yes, I forgot to mention that we had thought of doing that, but weren’t too keen on keeping tabs on two separate copies of our CSS and XHTML templates.

I suppose we could use absolute URLs when referring to the locations of CSS, JS, and other external files within our blog environment. We’ve run into snags with that before with defining consistent BASE headers and such, but it’s something to think about.

We were just hoping that someone else with this same problem might have written some kind of connector code.