• Welcome to Simple Machines Community Forum. Please login or sign up.

Problem running upgrade.php script Get fatal error message Line 2070

Started by SQL_Rudy, September 27, 2011, 05:21:44 PM

Previous topic - Next topic

SQL_Rudy

Hi,
I'm upgrading 1.1.4 to 2.0.1 using the Large Upgrade packages and like others with similar, I error out at the beginning of the cleanup section 5.
Here is the error message:

Notice: Undefined index: ucwords in /home/content/.../Sources/Load.php on line 2070

Fatal error: Function name must be a string in /home/content/.../Sources/Load.php on line 2070

At first I ran this by exracting the .zip package locally and then FTPing the files up to the correct directories.
After seeing the other similar threads, I ran it again where it sat.  Then I FTP'd the entire target tree to chmod 777
Ran it again, same thing.
Went and got another .zip  and .bz set of large upgrade packages.  This time I put both packages on the app root and extracted them on the server.
Did that twice with the same error message.

Looking at the code, it appears that it is having trouble finding the languages data and of course skipping the cache clean up and enabling further down the code.

Can anyone suggest a solution or at least a work around for this?  I was thinking about editing the Load.php file to ignore the languages section but I don't want problems with upgrades later.

I was able to edit the Settings.php file to put the system into simple maintenance mode to confirm the database and app were running and they are.  While I was there I went ahead and ran the table fix maintenance but it made no difference when I ran the upgrade script again.

I'm all ears at this point as I'm needing to export this whole app and move it to another server soon and I'd rather have it come out clean.

Thanks for listening.

kat


SQL_Rudy

Quote from: K@ on September 27, 2011, 05:25:50 PM
Welcome to the ol' forum, Rudy, even if it's coz something's gone squiffy. :(

Does this help, at all?

http://www.simplemachines.org/community/index.php?topic=348711.0

Thanks for the greeting!  It helps a lot.
Actually I was a member here a while back but as it happens, I forgot the account info so after dealing with it, I just decided to be new again.  :)
I need to hang out here more but I have not had much in the way of problems with my SMF apps and I don't use them too far out of the box so the rest is just distractions.  Until I have a problem of course.


SQL_Rudy

Ok.  I don't know if it matters and I don't think it would but I'm running Linux/Apache.

Adding the reloadSettings(); to the upgrade.php just before the loadUserSettings(); statement at line 131, solved the problem and the upgrade.php completed successfully.

Not being one to leave things alone, I then went back and edited out the reloadSettings(); statement from upgrade.php and ran it again to see if what it was choking on now existed and would still pass.  It failed without it so I re-edited it again and added it back in.  Ran sucessfully again.

Seems like something someone should add the upgrade.php file before bundling it for the upgrade, to me.  Doesn't seem like reloadSettings() would break much anywhere else.
Thanks for the lead.  I have no idea how the others were able to get by it with just re-running the upgrade.  Maybe they were on Windows where magic things happen?


kat

I think the majority are on Apache, like you.

I'll flag this up on the team boards, though. :)


Joker™

It's upto dev's whether they consider this as a bug or not, but it seems that various user has to add the reloadSettings() function in upgrade.php in order to complete the upgrade.
Github Profile
Android apps
Medium

How to enable Post Moderation

"For the wise man looks into space and he knows there is no limited dimensions." - Laozi

All support seeking PM's get microwaved


Arantor

Interesting, I've never seen this occur before but looking at it, it should only happen if there are mods not uninstalled before upgrading.

There's two ways we could fix this, we could either fix the upgrader or we could fix Load.php in 2.0 to always run reloadSettings if $modSettings is empty at the point of going to loadUserSettings. There are a bunch of places this will need fixing since it can occur on multiple branches of the upgrader.
No good deed goes unpunished
All helpful urges should be circumvented

Advertisement: