Hello,
in the past few days the following problem occurred in a local mediawiki installation: When opening an article for edit, everything seems in order. Showing the preview also works and the change applied to the article is shown. But when trying to submit, one gets the other-user-edits-conflict-warning and in the preview field there is the old unchanged version. This happens with every article (as far as tested) independently whether that respective article being edited by someone else or not.
Writing a new article works, trying to edit it just afterwards leads to the described problem.
Already did a rebuildall which took all night (2500 articles), but the problem remains the same. Is that something known and what am I missing here?
Greetings Philipp
On 6/14/05, Philipp wikilist-1@e-something.de wrote:
in the past few days the following problem occurred in a local mediawiki installation: When opening an article for edit, everything seems in order. Showing the preview also works and the change applied to the article is shown. But when trying to submit, one gets the other-user-edits-conflict-warning and in the preview field there is the old unchanged version.
The first step in troubleshooting this sort of problem is to take a good, long look at the server's clock. Is it correct (within a few minutes, at least)? Was it recently changed? Does the database have absurd timestamps in it? If the web and database servers are separate, do their clocks pretty much agree?
The clock isn't the only possibility, but in my experience it's a pretty common cause of phantom edit conflicts.
On 6/15/05, Brent 'Dax' Royal-Gordon brentdax@gmail.com wrote:
On 6/14/05, Philipp wikilist-1@e-something.de wrote:
in the past few days the following problem occurred in a local mediawiki installation: When opening an article for edit, everything seems in
order.
Showing the preview also works and the change applied to the article is
shown.
But when trying to submit, one gets the
other-user-edits-conflict-warning and
in the preview field there is the old unchanged version.
The first step in troubleshooting this sort of problem is to take a
good, long look at the server's clock. Is it correct (within a few minutes, at least)? Was it recently changed? Does the database have absurd timestamps in it? If the web and database servers are separate, do their clocks pretty much agree?
What's the second step in troubleshooting? I have the same problem and my clock is correct (ntpdate keeps it so) and the webserver and database both live on the same machine (and the database knows the correct timezone). The timestamps in cur look fine (so long as they're actually supposed to be GMT, which is what I'm assuming). I have MW 1.4.9 installed on a FreeBSD 5.2.1-RELEASE server running Apache/1.3.29 (Unix) PHP/4.3.4 mod_ssl/2.8.16 OpenSSL/0.9.7c (I suppose I need to upgrade some things now that I'm noticing... :)
I have similar configurations running the same version of MW, with no problems. This is a new one for me. I've wiped the wiki directory and dropped the database, done a re-install of MW, and gotten the same exact results. I can create new pages, but anytime I try to edit an existing page (no matter what user I am, WikiSysop or not) I get an "Edit conflict" that it won't let me resolve.
The only thing I'm doing on this machine that's out of the ordinary is connecting to it via an ssh tunnel (it's behind a firewall that won't allow port 80 traffic through from outside the local network). I don't see how that could affect anything but I figured I'd mention it for completeness.
Any suggestions?
-Bill Clark
On 9/17/05, Bill Clark wclarkxoom@gmail.com wrote:
I can create new pages, but anytime I try to edit an existing page (no matter what user I am, WikiSysop or not) I get an "Edit conflict" that it won't let me resolve.
Some initial testing indicates that these lines in Article.php are the problem:
1077 if( $dbw->affectedRows() == 0 ) { 1078 /* Belated edit conflict! Run away!! */ 1079 $good = false;
Investigating further...
-Bill
On 9/17/05, Bill Clark wclarkxoom@gmail.com wrote:
Investigating further...
Actually, it looks like the timestamps are simply getting all screwed up in Article.php for some reason.
What's really weird is that the timestamp seems to be losing exactly one hour between the $this->loadLastEdit() line in getTimestamp() and when it's actually returned. Nothing is happening in the code between those two lines, yet somehow the timestamp changes. This makes no sense whatsoever. Clearly I'm misunderstanding something here.
Investigating yet further...
-Bill
Bill Clark wrote:
Actually, it looks like the timestamps are simply getting all screwed up in Article.php for some reason.
What's really weird is that the timestamp seems to be losing exactly one hour between the $this->loadLastEdit() line in getTimestamp() and when it's actually returned. Nothing is happening in the code between those two lines, yet somehow the timestamp changes. This makes no sense whatsoever. Clearly I'm misunderstanding something here.
Is this on every page or some particular page?
When was the page last edited? Was it during a daylight saving time transition in your server's timezone?
Some versions of PHP have a bug where timestamps going through gmmktime() and gmdate() get converted to/from local time internally, which can corrupt them if they occur during a daylight saving time transition (hence ambiguous timezone); the result is a time that's one hour off, and matching timestamps no longer match.
If you're experiencing this, try adding in your LocalSettings.php:
putenv("TZ=UTC");
-- brion vibber (brion @ pobox.com)
At 21:32 -0700 17/9/05, Brion Vibber wrote:
Bill Clark wrote:
Actually, it looks like the timestamps are simply getting all screwed up in Article.php for some reason.
What's really weird is that the timestamp seems to be losing exactly one hour between the $this->loadLastEdit() line in getTimestamp() and when it's actually returned. Nothing is happening in the code between those two lines, yet somehow the timestamp changes. This makes no sense whatsoever. Clearly I'm misunderstanding something here.
Is this on every page or some particular page?
When was the page last edited? Was it during a daylight saving time transition in your server's timezone?
Some versions of PHP have a bug where timestamps going through gmmktime() and gmdate() get converted to/from local time internally, which can corrupt them if they occur during a daylight saving time transition (hence ambiguous timezone); the result is a time that's one hour off, and matching timestamps no longer match.
If you're experiencing this, try adding in your LocalSettings.php:
putenv("TZ=UTC");
-- brion vibber (brion @ pobox.com)
I also had this problem (a few months back). I had installed on two servers. The problem appeared on a server with mysql4 and not on the server with mysql3. But that may irrelevant.
The problem disappeared (with 1.5.x releases as I recall) and I have hence removed the fix below from LocalSettings.php
# Ugly hack warning! This needs smoothing out. $wgLocaltimezone = "UTC"; $oldtz = getenv("TZ"); putenv("TZ=$wgLocaltimezone"); $wgLocalTZoffset = date("Z") / 3600; putenv("TZ=$oldtz");
Not sure who suggested this workaround?
Gordo
On 9/17/05, Bill Clark wclarkxoom@gmail.com wrote:
Investigating yet further...
I found the problem: wfTimestamp is adding an hour to the timestamp on my system for some unknown reason.
I fixed it by making the following changes to Article.php (not in diff -u format because this is really just a temporary workaround until I figure out the 'real' source of the problem, and I don't expect anybody to consider this a patch that should be shared):
425c425 < $this->mTimestamp = $s->cur_timestamp; ---
$this->mTimestamp = wfTimestamp(TS_MW,$s->cur_timestamp);
630c630 < $this->mTimestamp = $s->cur_timestamp; ---
$this->mTimestamp = wfTimestamp(TS_MW,$s->cur_timestamp);
1073c1073 < 'cur_timestamp' => $this->getTimestamp() ---
'cur_timestamp' => $dbw->timestamp($this->getTimestamp())
1096d1095 < 'old_timestamp' => $this->getTimestamp(),
As best I can tell, there's not really any reason to use wfTimestamp() (or timestamp() -- which is just a wrapper for wfTimestamp()) in these cases anyway, since the value of cur_timestamp was pulled straight from the database in the proper format in the first place.
I'm through with this for now, since I have a viable workaround for my system. When I have the time I'll look into it further, in case anybody is interested.
-Bill
wikitech-l@lists.wikimedia.org