Dear all,
I am happy to announce the availability of the first stable release of the new MediaWiki 1.22 release series.
MediaWiki 1.22 is a 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-1.22 file for the full list of changes
in this version.
Our thanks to everyone who helped to improve MediaWiki by testing the release candidates and submitting bug reports.
== What's new? ==
MediaWiki 1.22 includes all changes released in the smaller 1.22wmfX software deployments to Wikimedia sites.
=== Anti-spam and countervandalism improvements ===
We're improving countervandalism and anti-spam features:
* The patrolling system has been improved to make the "mark as patrolled" link available on any patrollable page or revision, without having to go to Special:RecentChanges or Special:NewPages. It is no longer necessary to look up the "rcid" URI parameter from these special pages. (Bug 15936)
* Extension:SimpleAntiSpam, a small but harmless shield against the simplest forms of spambots, has been merged into core.
===Editing improvements===
* When comparing revisions in the history or when previewing changes while editing, "(No difference)" is now shown in place of a diff when the revisions are identical. (Bug 14431)
* After a successful edit, the confirmation message "Your edit was saved." is now shown. Formerly a separate extension (Extension:PostEdit), this feature is now part of the core software. (Bug 48276)
===Upgrades to Vector and other skins===
The old Vector extension has been merged into core, and the extension has been discontinued. The new version includes several improvements to both the Vector skin and cross-skin features. (Bug 45051) If you were previously using the Vector extension, you must uninstall it (the extension, not the skin) before upgrading to 1.22.
All skins:
* Section edit links are now displayed next to their respective headings rather than along the opposite side of the page. (Bug 41729)
* Lists of templates and categories used on the page, displayed below the edit form, are now collapsible. The area with license information, edit summary, and related functionality below the edit field has received a minor graphical lift. (Bug 43689)
* An "edit warning" is now displayed when the user attempts to leave the edit page with unsaved changes, on browsers supporting dialogs.
* Vector skin only:
** Navigation menu subsections are now collapsible.
** Page tabs can now dynamically fold into a dropdown menu when the browser window isn't wide enough to fit them.
===Support for Composer===
The Composer PHP dependency manager can now be used to install some extensions. It solves many common problems, including finding where to download an extension, resolving all of its dependencies and libraries, and selecting the right versions. Most MediaWiki extensions do not currently support Composer, but this is expected to change.
==Upgrade notices for MediaWiki administrators==
As with every release, there are some routine maintenance and upgrade tasks that go beyond the primary installation process.
===PHP JSON extension now required===
Though the minimum PHP version is still 5.3.2, MediaWiki now requires either the native JSON extension or the pecl-json-c fork. Most servers already have this PHP extension installed and enabled. However, if you administer your own server, and the MediaWiki installer says you don't have this extension:
* If you compiled PHP yourself with the --disable-all configure option, you may have to recompile with --enable-json.
* On Red Hat or CentOS, check for the line extension=json.so in /etc/php.ini or /etc/php.d/json.ini.
* Ubuntu 13.10, Fedora 19, and other recent Linux distributions package pecl-json-c separately, under names such as php5-json (Ubuntu universe) and php-pecl-jsonc (Fedora). They no longer include the original JSON extension because of licensing concerns.
=== Several ancient skins removed ===
On April 1, 2013, several ancient skins were removed from core (not an April Fools' joke): Chick, Classic, MySkin, Nostalgia and Simple.
Nostalgia was the phase I/UseModWiki-like skin, and Classic was the main skin before the introduction of the default MonoBook in MediaWiki 1.3 on May 22, 2004. Dating back to February 2002 both skins existed over a year before MediaWiki got its name.
=== Blank system messages must be deleted ===
Blanking a system message (editing it on wiki to remove all content) will no longer restore the default value for the message, but instead make it show as an empty string in the interface (fixing Bug 14176, "Add ability to disable MediaWiki messages"). If you have blank messages on your wiki (check Special:AllMessages), you must delete them unless you want them to display as empty.
===Protection rights usage has changed===
A new setting ($wgCascadingRestrictionLevels) was added for enabling cascading protection for protection levels other than "Allow only administrators" (Bug 47617). Shortly afterward, the way the "editprotected" and "autoconfirmed" rights work was changed. In particular, the "autoconfirmed" right is now only used for rate limiting, not page protection. If your wiki has custom user groups with the "autoconfirmed" right, you may need to grant those groups the new "editsemiprotected" right when you upgrade.
===Special:Disambiguations has been removed===
Special:Disambiguations, a page that listed "Pages linking to disambiguation pages", has been removed (Bug 35981). If your wiki used this feature, consider using Extension:Disambiguator. Switching to the new extension is easy and generally only requires a small change to a single template.
=== Bundled extensions ===
Newly bundled for 1.22:
* SimpleAntiSpam
Full release notes:
https://git.wikimedia.org/blob/mediawiki%2Fcore.git/1.22.0/RELEASE-NOTES-1.…https://www.mediawiki.org/wiki/Release_notes/1.22
**********************************************************************
Download:
http://download.wikimedia.org/mediawiki/1.22/mediawiki-1.22.0.tar.gz
GPG signatures:
http://download.wikimedia.org/mediawiki/1.22/mediawiki-1.22.0.tar.gz.sig
Public keys:
https://www.mediawiki.org/keys/keys.html
Hi,
we have published a new version of BlueSpice free.
BlueSpice 2.22 is a major release with many improvements. Besides the extension "reminder", which will become a separate module, our developers realized all features, we had in
mind a few months ago: http://blog.blue-spice.org/2013/09/04/bluespice-2-the-new-version-coming-up…
The most important features are:
· Dashboard: A lot of relevant information at a glance
· Notification: Improved messaging
· Skin: Completely reworked skin
· Flexiskin: Skin your wiki
· Readers: See all readers of a page (very nice tool and many discussions ... )
· Checklist: Provides Checklist functionality
· Avatars: Show autogenerated images for users.
Download, Release Notes und Installation Manual can be found here:
http://blog.blue-spice.org/2013/11/27/stable-release-bluespice-2-22-0-go-ge…
Thanks to all who supported us in the last months!
Richard
Dr. Richard Heigl
Strategieberatung
[Mailclosing]<http://weekly.blue-spice.org/>
Hallo Welt! - Medienwerkstatt GmbH
Residenzstraße 2
93047 Regensburg
Tel. +49 (0) 941 - 66 0 80-193
Fax. +49 (0) 941 - 66 0 80-189
www.hallowelt.biz<http://www.hallowelt.biz/>
heigl(a)hallowelt.biz<mailto:heigl@hallowelt.biz>
Sitz: Regensburg
Amtsgericht: Regensburg
Handelsregister: HRB 10467
E.USt.Nr.: DE 253050833
Geschäftsführer: Anja Ebersbach, Markus Glaser, Dr. Richard Heigl, Radovan Kubani
Hello
To be honnest I choosed Lockdown as I didnt find enough documentation and examples on IntraACL.... for now our project is still in test... so no problem to continue to test IntraACL...
Cheers
--- Message initial ---
De : vitalif(a)yourcmc.ru
Envoyé : 15 octobre 2013 17:02
A : mediawiki-enterprise(a)lists.wikimedia.org
Objet : Re: [Mediawiki-enterprise] Gathering money for MediaWiki ACL (was: How do you manage the security in your Mediawiki installation (Enterprise wiki) ?)
Hi Pierre, by the way, what was your experience with IntraACL? :)
_______________________________________________
Mediawiki-enterprise mailing list
Mediawiki-enterprise(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-enterprise
Hello,
I'm answering a catalog of requirements for a potential buyer. One of the most asked question for years is:
"Is it possible to open attachments (Excel e.a.), edit the content and save the changed attachment again?"
And my answer is: "No. That's possible in SharePoint (aaargl) or if the changed file is stored in an external (file) system".
Can somebody tell me more about the technical constraints? Is a solution thinkable? In my opinion MediaWiki this feature is very important for professional users.
Cheers,
Richard
Dr. Richard Heigl
Strategieberatung
Hallo Welt! - Medienwerkstatt GmbH
[Mailclosing-Newsletter]<http://hallowelt.biz/kontakt/newsletter/>
Residenzstraße 2
93047 Regensburg
Tel. +49 (0) 941 - 66080-193
Fax. +49 (0) 941 - 66080-189
www.hallowelt.biz<http://www.hallowelt.biz/>
heigl(a)hallowelt.biz<mailto:heigl@hallowelt.biz>
Sitz: Regensburg
Amtsgericht: Regensburg
Handelsregister: HRB 10467
E.USt.Nr.: DE 253050833
Geschäftsführer:
Anja Ebersbach, Markus Glaser, Dr. Richard Heigl, Radovan Kubani
Hi Mark!
I propose to split the topic and discuss the creation of ACL for MW in
this thread.
I see three sub-tasks here:
0) Writing a good proposal of how ACL should work. Will it be based on
namespaces? or maybe categories (although it's hard to imagine)? or
maybe per-page access? I can help to describe this vision document.
1) coordination with WMF and including ACL into Roadmap. First we need
to be sure that the possible patches to the core:
- will not be rejected just because of philosofy of openness
- will not be removed after several versions
I've got no ideas how that can be done. Probably via RFC with
signatures of interested companies.
2) Searching for the developers and tester. There are many possible
developers that may be interested in this task: HalloWelt, Custis,
DIQA-PM, maybe even Wikia. Besides there are a lot of independent
developers here
3) Fundraising. For independent developer it's possible to ask for
individual engagement grant [1] but mostly it should be a crowdfunding
from MediaWiki-related companies.
For that task we need a person who has personal contact with many
MediaWiki-related companies and is ready to contact each of them
asking to take part in funding. I'm not sure who that can be (maybe
me, maybe someone from organizing comittee of Wikimania or Wikisym,
maybe someone from WMF) but it's going to be a god damn lot of dirty
work that needs funding.
[1] http://meta.wikimedia.org/wiki/Individual_Engagement_Grants
Cheers,
-----
Yury Katkov, WikiVote
On Sat, Aug 24, 2013 at 4:38 AM, Mark A. Hershberger <mah(a)nichework.com> wrote:
> On 08/23/2013 06:31 PM, Yury Katkov wrote:
>> Of course, after some time the extension will stop working because of
>> ugly hacks that will definetely appear in the code.
>>
>> Another and more proper solution is not so fast, that is: to lobby the
>> proper ACL support in MediaWiki core before starting development.
>
> +1
>
> Markus Glaser and I have discussed precisely this as one of the biggest
> hurdles for Corporate adoption of MediaWiki. There are a lot of things
> to do in the MediaWiki space but, as you point out, this is one that we
> need developers outside the WMF for.
>
>> MediaWiki is used as an enterprise wiki and the impossibility of good
>> ACL should not be considered as not some kind of philosophy of the
>> software (as some people claims) but as a bug that needs fixing.
>
> +1 (again. That makes 2 points for Yury, so far.)
>
> So if -- as many of us on the -enterprise mailing list agree, I think --
> this is a bug that needs fixing, how are we going to fix it?
>
> That is, where is the money to pay for developer time going to come from?
>
> The release manager contractor[1] that the WMF is funding this year is
> meant to be finding funds outside of the Foundation to sustain release
> management long term. One way to do that is to begin extending
> MediaWiki in ways that enterprises would be willing to fund -- say, for
> example. through developing ACLs.
>
> If we can find some MW developers interested in working on adding this
> to core, and the money to fund those developer's work, the problem then
> becomes coordinating their work and making sure it has real momentum.
>
> Thoughts?
>
> --
> Mark A. Hershberger
> NicheWork LLC
> 717-271-1084