-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I'm happy to announce the availability of the first beta release of
the new MediaWiki 1.17 release series.
Please try it out and let us know what you think. Don't run it on
any wikis that you really care about, unless you are both very
brave and very confident in your MediaWiki administration skills.
MediaWiki 1.17 is a very large release that contains many new
features and bug fixes. This is a summary of the major changes of
interest to users. You can consult the RELEASE-NOTES file for the
full list of changes in this version.
*********************************************************************
What's new?
*********************************************************************
PHP 5.2.3
- ---------
We now require PHP version 5.2.3 or later. Why? Well, it brings with
it some tools for your beloved developers. It was released on June
1, 2007, so we believe this requirement will not be a hassle for
administrators. Be sure to check your PHP installation and contact
your host if it runs an outdated PHP version.
New installer
- -------------
MediaWiki 1.17 is shipping with a completely redesigned installer to
fix a lot of outstanding bugs, clean up the code quality, and make
it easier to use. Notably, you can now run upgrades from the web
without having to move LocalSettings.php. A couple of other notable
changes:
* The installer can now be fully localized like the rest of the
software and contains numerous help dialogs.
* The installer script directory has been renamed from config/
to mw-config/.
* You now download your generated LocalSettings.php at install
completion, rather than writing it straight to the
configuration directory. The previous behavior was a security
risk.
* IBM DB2 and MSSQL support were dropped from the installer.
ResourceLoader
- --------------
As web browsers have become more capable, the software that
MediaWiki runs on them has become more complex. This trend has
resulted in developers needing an efficient way to package and
deliver code to web browsers. To address this, MediaWiki 1.17
ships with ResourceLoader: a framework which combines and minifies
CSS and JavaScript before delivering them to the web browser.
ResourceLoader improves performance, while also making it easier to
write client-side features. ResourceLoader allows developers to
organize scripts, styles, and messages into named modules. Any
number of modules can be loaded through a single request, improving
page load times. Code is minified automatically and loaded when
needed, reducing unnecessary downloads. Other advanced features
include the ability embed images in style sheets using data URIs, or
automatically flipping horizontal information in style sheets for
right-to-left user interfaces.
Category sorting
- ----------------
Category sorting has been drastically improved.
* Sorting is now case insensitive.
* Sub-categories, pages and files can now be paged separately.
* When several pages are given the same sort key, they sort by
their names instead of randomly.
Language support
- ----------------
As with every release, MediaWiki 1.17 brings improved support for
languages in MediaWiki, with improved translation and features for
the many supported languages.
New languages:
* Moroccan Spoken Arabic (ary)
* Banjar (bjn)
* Kabardian (Cyrillic) (kbd-cyrl)
* Latgalian (ltg)
* Minangkabau (min)
* Dutch (informal) (nl-informal)
* Rusyn (rue)
API
- ---
API bug fixes and new features have been added to 1.17, providing
more options for input and output.
* API output can now be formatted by PHP's var_export() (format
type is dbg/dbgfm).
* An API module was added to list page properties.
* PARAM_REQUIRED can now be used on parameters, to have the API
enforce existence before code even reaches the module.
* The API now has a Really Simple Discovery module, useful for
publishing service information by the API.
The API contains 3 breaking changes against previous releases:
* action=patrol now requires POST.
* The patrol token is no longer the same as edit token.
* Session keys returned by ApiUpload are now strings instead of
integers.
Other
- -----
* Interwiki links in articles are now recorded in a separate
table.
* Users can now add CSS and JS to all skins by using
User:<name>/common.css and User:<name>/common.js.
Release notes
- -------------
Complete release notes are at
http://www.mediawiki.org/wiki/Release_notes/1.17
**********************************************************************
Download:
http://download.wikimedia.org/mediawiki/1.17/mediawiki-1.17.0beta1.tar.gz
GPG signatures:
http://download.wikimedia.org/mediawiki/1.17/mediawiki-1.17.0beta1.tar.gz.s…
Public keys:
https://secure.wikimedia.org/keys.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk3CmmwACgkQgkA+Wfn4zXl+EwCfZqqPPuFrSSF68hxzQfM6SXgr
gH0An2xr18+vNml2pv0D4XSPuLRDf/ie
=m5Rw
-----END PGP SIGNATURE-----
Hi
I was planning to make an api sandbox for mediawiki as a part of gsoc 2011.
while going through mediawiki documentation, i found that many functions
needed POST rather than GET requests. i am planning for flickr like api
sandbox<http://www.flickr.com/services/api/explore/?method=flickr.contacts.getList>for
mediawiki.
in flickr the documentation of every method has a link to api explorer
(sandbox) where user can test different values for each parameter and the
result is displayed in a div in the same page.
media wiki sandbox will display available parameters that can be used for a
particular method (drop-down if the values are previously known). the user
can fill the forms with his own values. the api then will send a GET or POST
request (AJAX request) according to the scenario (using JQuery or some other
JS library) and display the results in a div in the same page. the page
shall also display a url for executing the same ajax request.
to make the api sandbox really useful, it ideally should have automatic php
code generation too ( i don't know if it is overambitious ). for example for
login and logout, user can just give his userid and password and the code he
would write for php is automatically displayed.
i eagerly await for suggestions
--
Salil
IRC : _Salil_
Brion Vibber wrote:
> On Mon, May 2, 2011 at 11:54 AM, Alex <alejrb at gmail.com> wrote:
> > Question: why does it have to normalise at all?
> >
> > I do think that the editing environment at Wikipedia means that consistent
> > non-normalised editing by wikitext users and subsequent normalisation by
> > anyone using WYSIWYG would be messy and disruptive, but would a change
> > whereby it more precisely records the wikitext, and then doesn't try and
> > change it unless that part of the document is edited, be feasible?
> Indeed, that's the nicest thing to do.
Better, but not good. Since diffs can span several edits, it
is not really going to be helpful in many instances.
--
Greetings - Purodha
Maybe there's a better tool to tell you what function is defined in what class in PHP, but I couldn't find one in the time it would take me to write it, so I wrote it. It's not even a screenful. Give it the class definitions, in class hierarchy order, on the command line. It will pull out the class name and function names, and tell you which function is actually being implemented by which class. It doesn't pay any attention to parent::self() calls, so you should watch out for them.
-russ
#!/usr/bin/python
import sys, re
functions = {}
classes = {}
cl = None
for fn in sys.argv[1:]:
for line in open(fn):
match = re.match(r'(abstract\s+)?class\s+(.*?)\s+(extends\s+(.*?)\s+)?\{', line)
if match:
cl = match.group(2)
supercl = match.group(4)
classes[cl] = supercl
if supercl:
classes[supercl] # superclass should already be exist
match = re.match(r'\s*(public\s+|static\s+)?function\s+(.*?)\(', line)
if match:
# we have a function definition.
funct = match.group(2)
functions[funct] = cl
keys = functions.keys()
keys.sort()
for key in keys:
print key,functions[key]
Can someone please tell me, in precise technical terms, what is wrong
with Wikia's WYSIWYG editor and why we can't use it?
I have heard that it has bugs in it, but I have not been told exactly
what these bugs are, why they are more relevant for Wikimedia than for
Wikia, or why they can't be fixed.
Years ago, we talked dismissively about WYSIWYG. We discussed the
features that a WYSIWYG editor would have to have, pointing out how
difficult they would be to implement and how we didn't have the
manpower to pull off such a thing. Now that Wikia has gone ahead and
implemented those exact features, what is the problem?
-- Tim Starling
Just added to MediaWiki.org:
http://www.mediawiki.org/wiki/Extension:WorkingWiki
WorkingWiki is a software extension for MediaWiki that makes a wiki into
a powerful environment for collaborating on publication-quality
manuscripts and software projects. It's designed for research labs'
wikis, but may have diverse other uses as well.
(I probably should have made it public long ago, but there was a big
refactor and it took a long time to settle out...)
Lee Worden
McMaster University
On Wed, Apr 27, 2011 at 12:43 PM, Chad <innocentkiller(a)gmail.com> wrote:
> Getting the merges reviewed [0] and making sure we have a good set of
> release notes. That's what I know of, and Reedy's been working on the
> latter.
>
I've been thinking about this over the past few days, and I've got a proposed
release schedule and development roadmap to carry us through the rest of the
year.
As we all know, 1.17 is due to drop Real Soon Now. To summarize for those who
don't know the status: it's pretty much done. In talking with Roan, Tim and Sam
earlier this week, we discussed that we're pretty much ready to drop a
1.17beta1.
Tim was concerned about the release notes, but as I pointed out in my previous
e-mail, Sam's tidied this up (and it's low-hanging fruit if someone wants to
check behind us for sanity). That being said, I don't see any reason why we
can't drop a beta1 sometime this week. Give it a week, and drop a beta2. Wait
another week, then go final I think, all depending on what response we get from
the betas.
As for 1.18, I say we branch it the same day we drop 1.17 final (making the
branch is easy). There's still quite a bit of code to review, but going ahead
and giving ourselves a cutoff point will make catching up easier. Large projects
still outstanding in 1.18 to review are the img_metadata merge, and rewrites of
Skin and Action code. By branching soon I think we can try to get a release out
by the end of summer, at the very latest.
Looking ahead to 1.19, I'd like to do the same and branch soon after 1.18 has
been dropped. Since 1.19's a little further out and hasn't started taking shape
yet, I'd like to go ahead and propose what sort of release we should aim for.
Going back over the past couple of releases, we've had quite a few "rewrites"
of major portions of code. While these are a necessary part of the process of
developing MW, they are difficult to review due to their complexity. This
complexity also makes it more likely for things to break. If I may be so bold,
I would like to ask that 1.19 not contain any of these rewrites. Let's focus on
making it a bugfix/cleanup release. Personally I think it would make for a very
clean and polished release, as well as reducing the time for us to review and
ship it.
If we go this route, I don't see any reason we couldn't ship 1.19 by year end
(or if we really push, 11.11.11, as the other thread suggested). I
think it would
put us in a really good place to move forward into 2012, and help get us back
into a somewhat regular release pattern.
I really would love to hear from people to see if they think I'm crazy or if
this could work out fairly well. I know it's pretty tl;dr for most people, but
the ones who read it are the ones I wanna hear from anyway ;-)
-Chad
Bounces? That is, some return codes from a program delivery can be interpreted as a failed delivery. Or perhaps the program is segfaulting or running out of memory? Or replies sent to the envelope sender, which can be interpreted as bounces, but which lack the empty sender of a real bounce.
Ryan Lane <rlane32(a)gmail.com> wrote:
I'd also love to know how it keeps getting unsubscribed. This is the
third time...
On Mon, May 2, 2011 at 7:03 PM, K. Peachey <p858snake(a)gmail.com> wrote:
> On Tue, May 3, 2011 at 10:05 AM, Happy-melon <happy-melon(a)live.com> wrote:
>> Wow, now here's a blast from the past... :-D A lot of these stats are now
>> in the BZ4 report page, but it's still very nice to have the weekly
>> reminder. Cookie for whoever dug it out and got it going again!
>>
>> --HM
> Ryan resubscribed the email address it sends from to the mailing list :p
> -Peachey
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l