Hello!
You are receiving this email because your project has been select 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 relation 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 scripting
language.
The first release candidate of PHP 5.1.2 can be found at
http://downloads.php.net/ilia/php-5.1.2RC1.tar.bz2. This is not a final
RC, but we hope it will be followed by a final RC2 that should be
released in January 2006. At this time I would like to ask you to test
your application against this release and let us know about any issues
that you discover. We are particularly interested in backwards
compatibility breaks and new issues appeared in this release, but were
not present in prior 5.1 versions. If you find any issues, please
contact the PHP QA team at "php-qa(a)lists.php.net".
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.
regards,
Ilia Alshanetsky
5.1 Release Master
Hello,
Working on an extension, I need a custom page with access to another DB,
SQL requests and processing. I guess the best way to integrate this into
mediawiki is through a special page, but I was unable to find any useful
doc (whereas help for extensions on meta-wiki is really useful. Thanks).
Do you have any links, tips or help to point me in the right direction ?
Thanks in advance,
--
Boris Herbinière-Sève
I've partially rewritten the StableVersion extension. It now can
* store multiple stable versions (someone wanted this; I can turn that off)
* store multiple types (not actually supported yet, but the potential is
included), e.g.:
** stable
** stable candidate (someone wanted this)
** "soft-protected"
** other "levels of stability" like "thoroughly reviewed"
And most important:
When you click on the "declare this stable" link, it now caches the
source *with replaced templates*, meaning the stable page will look the
same even if the templates it uses were changed or deleted.
With some help *ahem* the feature could go live this year, IMHO.
Magnus
There have been quite a few requests for Wikipedias in new languages in the recent months.
All of them have been examined carefully and they were broadly discussed by the community.
Seven of them have qualified. They are considered promising and useful projects and a very clear majority of users is convinced that they will be a beneficial extension of the Wikipedia family.
However, before those babies can grow and prosper we need a specialist to assist their births.
In other words: I'd like to ask you to create the wikis specified below please.
* Nedersaksisch: nds-nl.wikipedia.org [Netherlands Low Saxon]
* Romani: rmy.wikipedia.org [Vlax Romany]
* Líguru: lij.wikipedia.org [Ligurian]
* emaitėka: bat-smg.wikipedia.org [Samogitian]
* Basa Banyumasan: map-bms.wikipedia.org [Banyumasan]
* Ripoarisch: grp.wikipedia.org [Ripuarian]
* Pennsylfaanisch-Deitsch: pdc.wikipedia.org [Pennsylvania German]
Further details can be found at http://meta.wikimedia.org/wiki/Approved_requests_for_new_languages
Thank you very much for your time and attention, also on behalf of our new fellow Wikipedians!
Arbeo
---------------------------------
Telefonieren Sie ohne weitere Kosten mit Ihren Freunden von PC zu PC!
Jetzt Yahoo! Messenger installieren!
I have CCed this question to the Wikitech mailing list. I hope they can be
of assistance to you.
Connor Lee
Wikimedia Help Desk
On 12/14/05, Jan Vanoverpelt <jan.vanoverpelt(a)gmail.com> wrote:
>
> Dear,
>
> After installation of the Mediawiki-software, I changed the default
> "English" language into Dutch by changing $wgLanguageCode in
> localsettings.php AND by setting $wgUseDatabaseMessages=false in
> defaultsettings.php (the latter had to be done in order to see the
> changes, like is indicated in the Mediawiki-FAQ).
>
> My problem is that because $wgUseDatabaseMessages=false, I cannot display
> the page "special:allmessages" anymore, neither can I change the content of
> the navigation bar. As a solution for this problem, the FAQ-answer proposes
> to run the script rebuildMessages.php in the maintenance-folder. I did
> this but without any results.
>
> Does anyone know how I can fix this problem so I am allowed to see the
> page special:allmessages and change the content of the navigation bar while
> I still have my wiki-site in the Dutch language?
>
> thanks in advance!
>
> _______________________________________________
> HelpDesk-l mailing list
> HelpDesk-l(a)Wikimedia.org
> To unsubscribe from this list, visit:
> http://mail.wikipedia.org/mailman/listinfo/helpdesk-l
>
>
>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
During my testing, I noticed that under certain conditions a temp folder
would be created in images/. .cvsignore doesn't tell us to ignore this
folder... so..
- --- C:/Documents and Settings/Edward/My Documents/My
Webs/jpsband/mediawiki/t/images/.cvsignore
+++ images/.cvsignore
@@ -3,4 +3,5 @@
thumb*
timeline*
tmp*
+temp*
?
I reckon no one would have problems with committing such a patch...
- --
Edward Z. Yang Personal: edwardzyang(a)thewritingpot.com
SN:Ambush Commander Website: http://www.thewritingpot.com/
GPGKey:0x869C48DA http://www.thewritingpot.com/gpgpubkey.asc
3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
iD8DBQFDqe10qTO+fYacSNoRAk7dAJ9+/VzUT6bYnhx+sCGtYFwZKiyTUQCaAkL4
M85XD8vdm7QqJrK65KjYjgs=
=HZm4
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
MediaWiki 1.5.4 is a security and bugfix maintenance release.
A hardcoded internal placeholder string has been replaced with a random
one. This closes a hole where security checks in inline style attributes
could be bypassed, injecting JavaScript code that could execute in
Microsoft Internet Explorer.
Other browsers would not be vulnerable.
Several minor fixes are included in this release, most notably a fix
to clear the "you have new messages" flag properly for usernames
containing spaces when e-mail notification is enabled.
See the changelog at the end of the release notes for a full list of
fixes.
Release notes:
http://sourceforge.net/project/shownotes.php?release_id=379951
Download:
http://prdownloads.sourceforge.net/wikipedia/mediawiki-1.5.4.tar.gz?download
MD5 checksum:
c5cff706c4d2fc8dd5aabd10f1714be0 mediawiki-1.5.4.tar.gz
SHA-1 checksum:
12ccdbdd295152937595d4a00c41ae156bf19015 mediawiki-1.5.4.tar.gz
Before asking for help, try the FAQ:
http://meta.wikimedia.org/wiki/MediaWiki_FAQ
Low-traffic release announcements mailing list:
http://mail.wikipedia.org/mailman/listinfo/mediawiki-announce
Wiki admin help mailing list:
http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
Bug report system:
http://bugzilla.wikimedia.org/
Play "stump the developers" live on IRC:
#mediawiki on irc.freenode.net
- -- brion vibber (brion @ pobox.com / brion @ wikimedia.org)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFDqfJ+wRnhpk1wk44RAodbAKCP6RPb2vysJTeUMMMq5eT9EXUkUgCfXzKL
mL8OeBGrSnXpPWteNI42ylI=
=oCrk
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I previously emailed this mailing list (
http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/21070
) asking about uploading big files. The single I response I recieved was
not sufficient... Commonist did not support non-Wikimedia projects, so I
set off to create my own special page extension to MediaWiki.
I have completed it, but there are a few hairy bugs pertaining to
MediaWiki that I need to sort out. And, perhaps, a friendlier API for
UploadForm.
It was a tricky problem: I wanted to keep code duplication down to a
minimum, but I had to use a class that was not designed to be extended
and have different functionality: it was a very procedural/transaction
script style class. I ended up extending it, overloading the
constructor, and supplying all the information that the constructor
previously determined from the reqest.
So... my hairy bug:
When an image upload is successful, wgOut gets this idea that we should
redirect to the image page. This is a bad idea for multiple uploads for
obvious reasons. However, I have not been able to isolate the source of
the call: a trace to the point where the header is called reveals that
wgOut buffers output.
I have overloaded these functions: mainUploadForm(), uploadError() and
showSuccess(), so they are probably not sending the redirect, but it
persists. I finally solved the issue by, after executing all the forms,
setting the redirect back to '', which is hackish.
Also, $wgMessageCache-> seems to be malfunctioning inexplicably for
certain messages. Some of them are instantiated, some aren't. Are there
any caveats to the function?
My main beef, however, is the way my subclass blatantly ignores all the
private recommendations and overloads them. Are they used in the sense
of being protected? Since I'm not following the rules, my extension is a
hack, albeit an elegant one that doesn't touch the original code and
minimalizes duplication. I'd volunteer to refactor SpecialUpload.php:
it's a fairly isolated piece of code, and splitting up the code into
more functions will make custom upload extensions much easier to write.
I also have to publish the extension. So... what do you think?
- --
Edward Z. Yang Personal: edwardzyang(a)thewritingpot.com
SN:Ambush Commander Website: http://www.thewritingpot.com/
GPGKey:0x869C48DA http://www.thewritingpot.com/gpgpubkey.asc
3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
iD8DBQFDqdTpqTO+fYacSNoRAtBBAKCD90gQ4GHGBWxmuheKb3FguRVqpACfeojm
fg8H6uvBCENSypUixkapuDI=
=JOLT
-----END PGP SIGNATURE-----
The article on Christmas is set to be on the Main Page on December 25th.
It used to be Featured quality. That was a year ago. Since then, it has
had 600 major edits, 500 other edits, and is nearly unreadable.
Compare the originally Featured version to the current version:
http://en.wikipedia.org/w/index.php?title=Christmas&diff=32012542&oldid=877…
Now, it is up for FARC:
http://en.wikipedia.org/wiki/Wikipedia:Featured_article_removal_candidates/…
To prevent stagnated articles from being presented as "top quality" on
the Main Page, there seems to be two solutions: set a time limit for
Featured Articles, which requires them to be renominated on FAC if they
become too different from their original Featured versions; or,
implement the "stable article" option that Tim Starling has talked
about, which would allow admins to set a "last good version" to be
presented to the public at all times, while the real version is somehow
edited "behind the scenes". As productive edits pile up, admins can set
a newer version as the "last good version". While this can still result
in an article being drastically-changed, it is much more likely to be
changed for the better in the long run.
brian0918
Hi,
We are starting to look into using Wikimedia as a type of knowledge base
for our organization. We currently use MS Server and SQL Server 2000. We
have setup PHP on IIS, but I was wondering if it is possible to have
Wikimedia work off of MS SQL Server instead of MySQL. If not, it's not a
huge problem to install MySQL server on a linux or win machine, but we
would like to be able to link articles from other database interfaces we
have designed in the past using MS SQL server.
Thank you,
Zakir Durumeric
The WiderNet Project
http://www.widernet.org