A group of us are starting a project to seamlessly combine the
authentication systems in open source software like Mediawiki,
Wordpress, Bugzilla and forums.
We're in the API planning phase and would appreciate input and code from
anybody, especially Wikimedia people.
Read more about it here:
For the past few days I've been experiencing this frustrating issue with
my account in the Greek Wikipedia
(http://el.wikipedia.org/wiki/User:Ferengi). I'm unable to edit several
pages, since every time I try to access an edit link, I get instead a
prompt to save index.php. An example of what actually gets saved is below:
This only happens when I'm logged in, if I log off I can edit pages
without issues. This issue is not browser specific, as I have tried IE7
and FF2 on one PC and IE6 on another, both with WinXP SP2, and IE7 on a
virtual machine with Server 2008 beta, and in all cases I had the same
results. I also had my monobook.js deleted in case it was causing
trouble, but that didn't fix anything. Any ideas?
The last pages-meta-current.xml.bz2 in 20071018 is said to be 5.4GB, but
when I downloaded it, it was only 1.5 GB.
Why is that? Is there a problem with this dump? I saw there was a lot of
discussion about it. What should I do?
P Please consider the environment before printing this e-mail
It doesn't seem possible to set a redirect from function that uses the
ArticleSaveComplete hook, because the Article object then resets it
later on after the hook is run.
Is there a way around this? Can we add a feature to Article that
I'm implementing a feature that does a check after the article has
been saved. In this case, if there are missing images it'll redirect
the user to a special page that will prompt the user for a few
options, but right now the Article object is clearing the redirect.
You are receiving this email because your project has been selected
to take part in a new effort by the PHP QA Team to make sure that
your project still works with PHP versions to-be-released. With this
we hope to make sure that you are either aware of things that might
break, or to make sure we don't introduce any strange regressions.
With this effort we hope to build a better relationship between the
PHP Team and the major projects.
If you do not want to receive these heads-up emails, please reply to
me personally and I will remove you from the list; but, we hope that
you want to actively help us making PHP a better and more stable tool.
The second and final release candidate of PHP 5.2.5 was just released
and can be downloaded from http://downloads.php.net/ilia/. This RC
adds a few more bug fixes to the 5.2.5 version and works towards
further improvement of the language's stability. Since this is the
last RC (if all goes according to plan) please test this release and
let us know if you've identified any regressions. This is the last
chance to identify any issues before the final release.
In case you think that other projects should also receive this kinds
of emails, please let me know privately, and I will add them to the
list of projects to contact.
5.2 Release Master
I've written a few extensions that make use of UploadForm:
Both of these had to hack around UploadForm because it wasn't easily
extensible. Unfortunately, UploadForm has changed in version 1.11 and
these extensions are largely broken. Is there any way we can create a
standard function available to external callers that would upload an
image, that would be consistent from version to version? Something
$ret = UploadForm::upload($tempname, $path, $source, $ignore_warnings)
that could return an array of warnings / errors that a caller could
then either process or show to the user? Most of the functions of
UploadForm are largely dependent on internal members (mUploadTempFile,
mUploadTempName, etc) that are beyond the scope of an outside caller.
Or perhaps there's an easier way around this that doesn't involve
UploadForm? It'd be nice if extensions didn't have to reinvent
UploadForm to have the ability to upload a file.
On 11/1/07, david(a)svn.wikimedia.org <david(a)svn.wikimedia.org> wrote:
> Revision: 27091
> Author: david
> Date: 2007-11-01 04:08:42 +0000 (Thu, 01 Nov 2007)
> Log Message:
> Split mTitle into uiTitle and dbTitle; this is explained at the top of EditPage.php.
mTitle was publicly accessible, since it was declared with var and not
protected or private. Did you check whether this change broke any
other MediaWiki code, or any extensions?
We seem to have an issue with users editing on our site with Firefox
(reproducible on a Mac, not on Windows)
After posting the edit, the server responds with a redirect:
HTTP/1.x 302 Moved Temporarily
FF doesn't seem to reissue a request for this article though, and
shows the old copy of it without going back to the server. I've double
checked this using LiveHTTPHeaders.
This seems odd, does anyone have any idea why this would happen? It
also seems dependent on time, if the users makes submits an edit
within 30 seconds of loading the article, they get the stale version,
but if they wait longer, they are more likely to get the fresh
version. Other browsers do get the fresh copy if loaded separately
with the URL.
The normal 200 response for the article includes the cache information:
Cache-Control: s-maxage=86400, must-revalidate, max-age=0
but the 302 redirect doesn't include any info about must-revalidate.
Could this be an issue?
This didn't seem to be an issue earlier than today, we did upgrade to
PHP 5.2.4/eaccelerator 0.9.5.2, I'm not sure if this is related.