eitch

I see… So it’s another problem, because the server was always configured with GMT offset -3, and only 2.9.2 does not configure this (leaving GMT 0). Still investigating >_< Thanks

No news on this issue yet. Just to understand… On MU, when I create a new blog, do you know what is the WordPress behavior when creating default options (from wp_ID_options) for that blog?

I though, at least on 2.8.x, that when a new blog is created, WordPress get its default settings from the Site Main Blog (/), or am I wrong? What happens with 2.9.2?

Before, when I created a blog, it got, for example, the GMT Offset (-3) option from the main blog. This is not happening on 2.9.2. Maybe this information helps me investigate more… ??

Did try everything noted there… ?? There’s something really wrong with this creation process with our current database. I’ll keep investigating, because I really don’t want to downgrade to 2.8.x again ??

I’ll keep updating this topic for future reference ??

Hi Andrea ?? It’s exactly from there. Tag 2.9.2. Today I’m going to keep investigating to see if something new happens… This is very strange, never had this problem while upgrading any WordPress ??

Did a restore on the previous version (2.8.4a) and the original database, and creating blogs were working fine. Unpacked the wordpress-mu package replacing all files and the problem began ??

Unpacked the previous version again, and creating blogs just worked again! Now I’m really helpless ?? I’ll continue this investigation on Monday.

Just checked with a ‘replace all files’ upgrade and the problem persists. I ran a diff to see the difference too and they’re the same, the first run actually replaced all the files from the wordpress-2.9.2-mu package file.

I’ll continue to check the database thing… Maybe the upgraded database is resetting the “sitewide_activated_plugins” in wp_sitemeta or something? Trying… Any ideas will be pretty much appreciated ??

Update: the problem does not happen *before* I click the “Update Site” under the Administration menu. Only after updating the database, this problem begins.

I will try now the ‘fresh copy’ approach, still using the same database, to see if this happens. Will update shoftly.

We gave up, it’s just too complicated to do this. Instead, we’re planning on migrating by a sql dump / search and replace approach.

Ok Frederick, I’ll do a fresh installation with all the instructions on our customizations (it’s not so much) this weekend. Will update this ticket monday. Thanks a lot for your attention ??

Thanks for your reply, but unfortunately our network isn’t available for anyone outside here. We were using WP-Super Cache and now we migrated to batcache + memcache. We got very interested in your plugin, and if you want the same information to reproduce the error on a test installation, I would be very glad to provide. If you have a spare time and want to test it, it would be nice, but if no, we’re going to stick with our current plugin until we get some time to debug the code ??

Thanks and congratulations on your work.

I’m having the same problem. The XML is too big, and this is a lot frustrating… I don’t see a reason why PHP memory usage on this script will grow larger than 256M. My XML file is also ~ 57MB… I think the code needs some clean up on memory usage… ??