We just tried going to 1.4.0 and got this result - make sense to anyone?! TIA
OK - I've upgraded the Wiki software to version 1.4.0. It all seemed to go smoothly, so please check if everything looks OK. In case of emergencies, I backed up the old version into folder mediawiki-1.3.1, and also dumped the old database into that folder (using mysqldump) as file database-dump.
Oh no! I just logged in to the Wiki and all the dates are completely crazy, although the data all seems to be there. Should I revert to
the
old system?
and
The new installation was unusable. Apart from the silly dates, I couldn't update any Wiki pages. The "recent changes" pages showed a list of changes dated in the year 2030, and the history of an individual page showed potty dates such as 1919 or 1995. Check it out at http://www.ucl.ac.uk/calt/alpd/wiki-new
I've now reverted to the old system. I restored the old database into a new one with a different name (uczaw3e_alpdwiki2). The restore from the dumped database appeared to go OK - please check that everything seems in place.
I'll try to think of another way to do the upgrade. I was trying to
do
it in the existing folder, in case you had made any changes to it. Have you ever added or changed any files in the folder? If not, I'll try it in a new folder. Doh - just tried it in a new folder and got the same mess. I'm a bit stumped.
Jason Davies wrote:
The new installation was unusable. Apart from the silly dates, I couldn't update any Wiki pages. The "recent changes" pages showed a list of changes dated in the year 2030, and the history of an individual page showed potty dates such as 1919 or 1995. Check it out at http://www.ucl.ac.uk/calt/alpd/wiki-new
I've certainly never seen anything like that before.
You might want to look in the database to see what the cur_timestamp and old_timestamp fields actually contain.
Check also that the computer's clock is set correctly, and that the time() function returns sane values.
Interestingly, the Recent Changes changes from now link contains the correct MediaWiki-format timestamp: 20050328203841 but the display is '08:20, 9 Feb 1920'.
What sort of computer is this? What OS/architecture?
Make sure that the files aren't corrupted and that you're not mixing included files from different versions or anything.
-- brion vibber (brion @ pobox.com)
I've certainly never seen anything like that before.
the reply from the guy who set it up is tis Brion:
I'm not sure if I can post to that list. I did the whole thing from scratch to prove I wasn't going nuts, and I wasn't. The new installation is at http://www.ucl.ac.uk/calt/alpd/mediawiki-1.4.0 ; I've saved a copy of the installation log at http://www.ucl.ac.uk/calt/alpd/mediawiki-1.4.0/MediaWiki- installation.html ; the working version 1.3.1 is still at http://www.ucl.ac.uk/calt/alpd/wiki - the two versions are using different copies of the database.
We're using PHP 4.3.8 on an AIX box and MySQL 4.0.16 on a Sun Solaris box. The time() function is fine. The rc_timestamp and rc_cur_time columns in the recentchanges table look fine with sensible-looking
2004
and 2005 dates. The only difference I can see (using phpMyAdmin) between the working and non-working versions of that table is that the working version shows 'NONE" as the "cardinaility" of the index columns, but the non-working version shows actual numbers. I'm not really sure what this means, but I don't think it matters.
If you can't get an answer from the mailing list, I'll have to start comparing the PHP code of the two versions to see if I can spot something. That should be fun.
make any sense?
the reply from the guy who set it up is tis Brion:
addendum:
After some detective work, I think I'm on the trail. In function date() in languages/Language.php, there's a call "$ts = wfTimestamp(TS_MW,$ts);", which adjusts the time stamp for some reason, and which wasn't in version 1.3.1. When I remove that, the dates reported in the recent changes list look more sensible. That wfTimestamp function is used all over the place, so I'll have to see what it's supposed to be doing.
does this make sense to anyone? TIA, again.
Jason Davies wrote:
After some detective work, I think I'm on the trail. In function date() in languages/Language.php, there's a call "$ts = wfTimestamp(TS_MW,$ts);", which adjusts the time stamp for some reason, and which wasn't in version 1.3.1. When I remove that, the dates reported in the recent changes list look more sensible. That wfTimestamp function is used all over the place, so I'll have to see what it's supposed to be doing.
does this make sense to anyone? TIA, again.
It might "make sense" if PHP's built-in functions are malfunctioning and the functioning of wfTimestamp() is therefore broken. :)
Take that function in isolation (and the constant definitions it uses, right above it in GlobalSettings.php) and see if you can figure out how it's misbehaving.
Check that: * the format constants have the correct values * the correct preg_match calls match given input * the matches in $da contain the correct substrings * the result of gmmktime is a sensible Unix timestamp * nothing is overriding that timestamp * the correct output format is selected in the switch() * gmdate is returning sensible values
-- brion vibber (brion @ pobox.com)
It might "make sense" if PHP's built-in functions are malfunctioning and the functioning of wfTimestamp() is therefore broken. :)
thanks Brion, will pass that back...would this be consistent with 1.3.1 running correctly? or the PHP functions going to be completely independently? (still getting my head round all this). thanks for all your help.
It might "make sense" if PHP's built-in functions are malfunctioning and the functioning of wfTimestamp() is therefore broken. :)
for the record, this turned out to be because of changes in the PHP database to run Oracle server. We're hoping that PHP upgrade in a little while will solve. Thanks for the advice on this.
Jason Davies <ucgajpd@...> writes:
It might "make sense" if PHP's built-in functions are malfunctioning and the functioning of wfTimestamp() is therefore broken. :)
for the record, this turned out to be because of changes in the PHP database to run Oracle server. We're hoping that PHP upgrade in a little while will solve. Thanks for the advice on this.
Jason, any headway? I am experiencing the exact same timestamp symptoms, on AIX 5.1. Can you clarify the "changes in the PHP database to run Oracle server". I'm not sure that we have done that.
Jason Davies <ucgajpd@...> writes:
It might "make sense" if PHP's built-in functions are malfunctioning and the functioning of wfTimestamp() is therefore broken. :)
for the record, this turned out to be because of changes in the PHP database to run Oracle server. We're hoping that PHP upgrade in a
little
while will solve. Thanks for the advice on this.
Jason, any headway? I am experiencing the exact same timestamp symptoms, on AIX 5.1. Can you clarify the "changes in the PHP database to run Oracle server". I'm not sure that we have done that.
I can't help much, I'm really the messenger boy. I forwarded what I had - we ended up going to the last build of 1.3.11 for now. The PHP changes were done by someone in the college but I don't have access to the code.
mediawiki-l@lists.wikimedia.org