Forwarding this question on behalf of someone from the Public Library of
Science -- please reply both to me and to her, as she's not on the list.
Thanks.
>>> On Tue, Nov 8, 2011 at 10:56 PM, Jennifer Lin <jlin(a)plos.org> wrote:
> >>>> Hi, Daniel. I received your contact info from Peter Binfield.
> >>>>
> >>>>
> >>>>
> >>>> At PLoS, we are extending our ALM app to include Wikipedia citations
> >>>> for PLoS articles, but recently came upon an issue, which we’ve
> >>>> logged with your developers.
> >>>>
> >>>> https://bugzilla.wikimedia.org/show_bug.cgi?id=32026
> >>>>
> >>>>
> >>>>
> >>>> The gist of it is that the Wiki API has a limitation of 100 returns.
> >>>> For PLoS articles that are referenced more than 100 times, we get
> >>>> back a different set of results each time. Some of the same sources
> >>>> are returned, some new ones. Although we have the total number of
> >>>> citations, we do not know if we are capturing all of them, even
if we
> >>>> run the query many times over. Seems likely that there could be a
> >>>> more efficient way of pulling the exhaustive set. The bug report
explains the technical details.
> >>>>
> >>>>
> >>>>
> >>>> Although there was some initial contact with a Wiki developer,
> >>>> activity seems to have stopped. Do you have any suggestions on how
> >>>> to proceed at this point in time? We are very eager to add
Wikipedia
> >>>> as an ALM source given its importance to the research community
at large.
> >>>>
> >>>>
> >>>>
> >>>> Thanks so much, Daniel.
> >>>>
> >>>> Cheers, -jlin
> >>>>
> >>>>
> >>>>
> >>>> Jennifer Lin
> >>>>
> >>>> Public Library of Science, Product Manager
> >>>>
> >>>> (415) 935-2095
> >>>>
> >>>> 1160 Battery Street
> >>>> Koshland Building East, Suite 100
> >>>> San Francisco, CA 94111, USA
--
Sumana Harihareswara
Volunteer Development Coordinator
Wikimedia Foundation
I have Mediawiki installation went from 1.17 through 1.18 RC1 and to 1.18
But another Mediawiki has had some problems going direct from 1.17 to 1.18
I took out Recaptcha and now see this:
*Fatal error*: Cannot redeclare wfprofilein() (previously declared in
/xxxxxxxx/public_html/includes/profiler/Profiler.php:14) in
*/xxxxx/public_html/includes/ProfilerStub.php* on line *25*
Gordo
--
Gordon Joly
gordon.joly(a)pobox.com
http://www.joly.org.uk/
Don't Leave Space To The Professionals!
Hi all,
We have setup a mediawiki with some extensions (LDAP authentication,
FlaggedRevs, etc.)
It basically works fine, but we have the problem, that specifc
permissions, assigned to the group are not applied correctly.
We have three groups (admin, contributor and readonly) - and the
readonly group, doesn't apply it's desiganted permissions correctly:
// Most extra permission abilities go to this group
$wgGroupPermissions['admins']['block'] = true;
$wgGroupPermissions['admins']['createaccount'] = true;
$wgGroupPermissions['admins']['delete'] = true;
$wgGroupPermissions['admins']['deletedhistory'] = true; // can view
deleted history entries, but not see or restore the text
$wgGroupPermissions['admins']['editinterface'] = true;
$wgGroupPermissions['admins']['import'] = true;
$wgGroupPermissions['admins']['importupload'] = true;
$wgGroupPermissions['admins']['move'] = true;
$wgGroupPermissions['admins']['patrol'] = true;
$wgGroupPermissions['admins']['autopatrol'] = true;
$wgGroupPermissions['admins']['protect'] = true;
$wgGroupPermissions['admins']['proxyunbannable'] = true;
$wgGroupPermissions['admins']['rollback'] = true;
$wgGroupPermissions['admins']['trackback'] = true;
$wgGroupPermissions['admins']['reupload'] = true;
$wgGroupPermissions['admins']['upload'] = true;
$wgGroupPermissions['admins']['reupload-shared'] = true;
$wgGroupPermissions['admins']['unwatchedpages'] = true;
$wgGroupPermissions['admins']['autoconfirmed'] = true;
$wgGroupPermissions['admins']['upload_by_url'] = true;
$wgGroupPermissions['admins']['ipblock-exempt'] = true;
$wgGroupPermissions['admins']['review'] = true;
// Implicit group for all logged-in accounts
$wgGroupPermissions['contributor']['move'] = true;
$wgGroupPermissions['contributor']['read'] = true;
$wgGroupPermissions['contributor']['edit'] = true;
$wgGroupPermissions['contributor']['createpage'] = true;
$wgGroupPermissions['contributor']['createtalk'] = true;
$wgGroupPermissions['contributor']['upload'] = true;
$wgGroupPermissions['contributor']['minoredit'] = true;
// Implicit group for all logged-in accounts
$wgGroupPermissions['readonly']['read'] = true;
$wgGroupPermissions['readonly']['move'] = false;
$wgGroupPermissions['readonly']['edit'] = false;
$wgGroupPermissions['readonly']['createpage'] = false;
$wgGroupPermissions['readonly']['createtalk'] = false;
$wgGroupPermissions['readonly']['upload'] = false;
$wgGroupPermissions['readonly']['minoredit'] = false;
As you can see, readonly group, should only have read permissions. But
when logging in with a readonly account, the account still has
permissions to create a new page or move an existing page.
I have absolutely no idea, why this isn't working and therefore asking
now for some help.
Anything helpful will be much appreciated, and I'm also open to provide
some more information, if required.
Thanks and all the best,
Simon
We are proud to announce the first stable release of the 1.18 series.
*********************************************************************
What's new?
*********************************************************************
MediaWiki 1.18 brings the usual host of various bugfixes and new
features.
jQuery 1.6.4 is now included as standard, along with numerous
more jQuery plugins.
Breaking changes:
* action=watch / action=unwatch now requires a token
As of 1.18, some commonly used extensions are now being included in the
released tarball; this is allow ease
of installation of these extensions in new MediaWiki installs. If you
already use the extension just replace
the files like you have done for MediaWiki iteself. The following extensions
are bundled with MediaWiki as of
1.18. All are currently in use on Wikimedia sites.
* ConfirmEdit Various CAPTCHA techniques to try to prevent spambots and
other automated tools from editing your wiki.
* Gadgets A system to allow users to enable or disable JavaScript or CSS
tools made available to users site-wide.
* Nuke A special page allowing administrators to mass-delete content added
by a spammer or vandal.
* ParserFunctions Additional parser functions (like #if and #switch to
supplement the "magic words" present in MediaWiki.
* Renameuser A special page which allows authorized users to rename user
accounts.
* Vector Enhancements to the Vector skin.
* WikiEditor An improved and customizable editing toolbar developed along
the Vector skin.
Major features
-- ------------
Better gender support
-- -------------------
Until version 1.17, MediaWiki used neutral nouns to address and identify
users on their user page.
In English, this was not an issue since "User" matches both genders, but in
some languages the
neutral gender is always masculine; for example, this would cause
French-speaking female
Wikipedia users to be referred to as "Utilisateur" (male user) instead of
"Utilisatrice" (female user).
With version 1.18, user pages reflect the user's gender, if they have
specified it in their preferences.
More gender support (for instance in logs and user lists) will be available
in MediaWiki 1.19.
Improved file metadata support
-- -----------------------------
MediaWiki now detects the camera orientation from Exif metadata, and rotates
the
picture preview accordingly. The original file remains unchanged.
The overall metadata support in MediaWiki has been greatly extended.
Previously, MediaWiki could only
extract limited Exif metadata, and showed a subset of it on file description
pages. Since 1.18, MediaWiki
can extract IPTC and XMP metadata from uploaded files, and more Exif
information. This includes an
embedded description, author information, GPS coordinates, or copyright
statement.
Improved directionality support
-- -------------------------------
A lot of work has been done to fix directionality bugs (Left-To-Right,
Right-To-Left). Most notably bug 6100 is
fixed, which allows to display an RTL interface on an LTR wiki properly (and
vice versa). This was developed
under $wgBetterDirectionality, which is now no longer used because the
improvements are merged with the core code.
A positive consequence is that the page content on wikis with multiple
scripts is aligned according to the
direction of the selected variant. For example, on a Kazakh language wiki,
selecting the Arabic script
variant will align the text as RTL, while selecting the Latin or Cyrillic
variant will align it as LTR.
Easily find where to customize interface messages
-------------------------------------------------
MediaWiki allows you to customize the user interface by editing pages in the
MediaWiki namespace.
However, even though they can be viewed at Special:AllMessages] the sheer
number of these messages
makes it difficult to find which one needs to be customized. In MediaWiki
1.18, a new pseudo-language
is introduced (qqx) to help people find such messages, by displaying the
messages' key instead of the
actual messages. All one has to do is append ?uselang=qqx to the page's
index.php/
URL
(see https://www.mediawiki.org/w/index.php?title=MediaWiki_1.18&uselang=qqx
as an example).
New plugin for collapsible elements
-- -----------------------------------
The new jQuery.makeCollapsible allows you to create collapsible tables,
lists and so on,
by adding the class mw-collapsible to the elements.
See the manual for
details: https://www.mediawiki.org/wiki/Manual:Collapsible_elements
Protocol-relative URLs
-- ----------------------
MediaWiki now supports protocol - relative URLs in links, interwiki targets
and $wgServer.
Protocol-relative URLs look like //example.com/wiki/Foo ; the browser will
recognize this
as http://example.com/wiki/Foo when following a link from an HTTP page, and
https://example.com/wiki/Foo when following a link from an HTTPS page.
This way, protocol-relative URLs enable a wiki to support HTTP and HTTPS
while serving
the same HTML for both, which means the parser cache doesn't have to be
split.
More personalisable styles and scripts
-- --------------------------------------
MediaWiki now automatically loads javascript and stylesheets more specific
to each user.
There is a separate CSS and JS file for each usergroup
(MediaWiki:Group-sysop.css,
MediaWiki:Group-autoconfirmed.js, etc), and also a CSS file for users
viewing without
JavaScript (MediaWiki:Noscript.css).
Other changes
-- -------------
$wgEnableDublinCoreRdf and $wgEnableCreativeCommonsRdf no longer
work in core, and the functionality has been moved to the relevant
extensions.
See http://www.mediawiki.org/wiki/Extension:DublinCoreRdf and
http://www.mediawiki.org/wiki/Extension:CreativeCoreRdf as appropriate
Math
- ----
$wgUseTeX has been superseded by the Math extension. To re-enable
math conversion after upgrading, obtain the Math extension from SVN or from
http://www.mediawiki.org/wiki/Extension:Math and add to LocalSettings.php:
require_once "$IP/extensions/Math/Math.php";
Language support
- ----------------
As with every release, MediaWiki 1.18 brings improved support for
languages in MediaWiki, with improved translation and features for
the many supported languages.
New languages:
* Angika (anp)
* Brahui (brh)
* Central Dusun (dtp)
* Jamaican Creole English (jam)
* Khowar (khw)
* Liv (liv)
* Kichwa (qug)
API
- ---
API bug fixes and new features have been added to 1.18, providing
more options for input and output.
* API modules were added to access QueryPage based special
pages, to Compare pages, Revert files, and to be able to access
other special pages such as Special:UnwatchedPages,
Special:MimeSearch and Special:ActiveUsers
* The output of the generated help page has been improved
The API contains a breaking changes against previous releases:
* action=watch now requires POST and token.
Other
- -----
Our thanks go to everyone who helped to improve MediaWiki
by testing the beta release and submitting bug reports and patches.
For more information about what's new in the MediaWiki 1.17 branch, see:
http://www.mediawiki.org/wiki/MediaWiki_1.17
Frequently asked questions about upgrading:
http://www.mediawiki.org/wiki/Manual:FAQ#Upgrading
Changes since 1.18.0rc1
-- ---------------------------
* (bug 32228) regression in Special:Search which did not conserve profile on
new search
* (bug 32460) Categories were improperly aligned in Simple and CologneBlue
* (bug 32412) TOC links on [[Special:EditWatchlist]] points to the fieldsets
* (bug 32582) Fix TOC show/hide link regression on IE 8
Release notes
- -------------
Complete release notes are at
http://www.mediawiki.org/wiki/Release_notes/1.18
**********************************************************************
Download:
http://download.wikimedia.org/mediawiki/1.18/mediawiki-1.18.0.tar.gz
Patch to previous version (1.18.0rc1), without interface text:
http://download.wikimedia.org/mediawiki/1.18/mediawiki-1.18.0.patch.gz
Interface text changes:
http://download.wikimedia.org/mediawiki/1.18/mediawiki-i18n-1.18.0.patch.gz
GPG signatures:
http://download.wikimedia.org/mediawiki/1.18/mediawiki-1.18.0.tar.gz.sighttp://download.wikimedia.org/mediawiki/1.18/mediawiki-1.18.0.patch.gz.sighttp://download.wikimedia.org/mediawiki/1.18/mediawiki-i18n-1.18.0patch.gz.s
ig
Public keys:
https://secure.wikimedia.org/keys.html
I have Mediawiki 1.17 installed. I have been using the Special Extension
distributor to download the extensions I want to use. Now it only offers
to download a 1.18 version ("snapshot" I think). Is this likely to cause
functional issues with the extension I need. Seems to me the drop down
should offer both the current or other versions if it truly is making
the extension for the version listed available. I do not want to update
my current server to the newest version as I figure it still has a few
kinks to work out. I will do that when it is actually released. Any
ideas?
frosty
I was looking to have a query that displays output differently based on
the users' group membership.
I want to display something based on the query like
api.php?action=query&list=allusers&augroup=inactive&aulimit=500
where a member is a member of a group it will give result A, and if they
are not member of a group, give result B through a {{#switch:}}.
I cannot see a simple way to beyond the api to query for membership, and
thought that there may have been stuff based on the use of magic words and
parser functions. Am I missing something? If there isn't the means, if
one isn't a hacker, how can one get the results from queries dynamically?
Thanks.
Regards, Billinghurst
Hi,
how could I reduce Spezcial:Recent_Changes to changes on pages the current user can read?
Cheers,
Micha
--
Michael Merz
Mail: dermicha(a)dermicha.de
Skype: michamerz
Hello everyone,
I've been attempting to implement a Wiki family for a while now with no
luck. I'ved tried several methods from t
http://www.mediawiki.org/wiki/Manual:Wiki_family including Scenario 2, 5
etc. I always seem to run into some problem and it never fully works.
I'm trying to run off of a single database using table prefixes, and using
sub-folders. My main purpose is to have new languages on the wiki, such as
gamification.org/de, /fr etc. because members of our community want to
translate our wiki.
I'm pretty pressed on time to get this implemented, is there anyone in the
community who this is easy for and could help me set this up, paid?
If you can, please contact me asap. Thank you!
--
Nathan Lands
CEO & Co-Founder | Gamify, Inc.
415-713-3285 | San Francisco, CA
Gamify: http://gamify.com
Gamify Network: http://gamification.net