Wiki-site.com is a wiki hosting company, listed at
https://en.wikibooks.org/wiki/Starting_and_Running_a_Wiki_Website/Hosted_Wi…
Their "Support Contact" page [1] for paid wikis says:
"For wiki management support, we've created a forum at the following
address"
(links to THIS list!!)
Rami Addady, if you're listening, at least you should say something like
"You can get help from the amazing community of MediaWiki software users
and developers at their public discussion list" NOT "We've created a forum"
What do you think?
I've often wondered why some list questions seem like people are
"demanding" support. Now I know it's because some companies literally tell
their customers that this is their support desk.
[1] http://www.wiki-site.com/index.php/Support_contact
Greg Rundlett
https://eQuality-Tech.comhttps://freephile.org
Hi All,
As a lone tinker with Mediawiki, who pays some attention to things
connected with it, I thought I would ask for a follow up to last year's
Mediawiki Stakeholders survey (see:
https://www.mediawiki.org/wiki/MediaWiki_Stakeholders%27_Group). An
itemized wishlist of most requested features was made (see:
https://www.mediawiki.org/wiki/MediaWiki_Stakeholders%27_Group/Tasks/Featur…)
with the top four being:
1. Easier installation and upgrade (for both core and extensions).
2. Editing and Visual Editor
3. Skinning and UI
4. Access Controls and Rights
I'm asking for this follow up because as far as I can tell little to no
process has been made on these issues. Additionally in some ways it seems
some things have gotten worse. But I'm hoping I'm wrong and someone with
more knowledge will enlighten me.
Here's some examples of things not improving, or getting worse:
1. Easier Installation and upgrade
a. Three years after the death of the Extension Matrix there still is
still no way to tell when a new extension is released.
b. Composer is an easier way to install extensions, but for those without
command line access it's a nightmare.
c. The upgrade process is still the same
2. Visual Editor
a. still a nightmare to install -- not in any sense is it an out of the box
solution.
b. On a shared host forget about the Visual Editor
3. Skinning and UI
a. same as extensions -- no easy way to find out about new skins
4. Access Controls and Rights
a. The most popular access control extension (Lockdown) only barely works
in 1.27 and causes other extensions to not work: Visual Editor, MsUpload,
and Upload Wizard (there's no doubt more).
b. Almost every other access right extension is unmaintained.
c. The two Semantic Mediawiki Access Right extensions are both
unmaintained.SemanticACL does not work at all in 1.27.
I know, or assume some of these things are being worked on, but still it
seems the stakeholders feature wishlist is not being translated into action
in anyway. So anyone know something I don't, or don't see on these issues?
(Btw, this is not a knock on the hard working developers behind Mediawiki,
and/or its extensions. But a desire to see if the desires of third-party
users have any impact on the direction of software).
Thanks
Chris
Hello,
I am trying to register two different window creation functions in OOjs UI
but somehow they conflict with one another.
The code is in [1] and you can use it like [2]. If you go to a page with
sections (e.g. my talk page) you should see new links in the section
heading called "add comment" and "close".
The first time you click on each, the respective dialog will be shown. But
whichever you click on first will only work once! So for instance, if you
first click on "add comment" and then cancel the dialog, then click on
"close" and cancel, now only "close" links will work (all of them) and none
of the "add comment" links will show a dialog anymore. No error is logged
in the console either.
I am pretty sure it has to do with the way I am defining my objects, but I
am not able to figure out what I am doing wrong. Please advise.
Thanks,
Huji
[1] https://en.wikipedia.org/wiki/User:Huji/close.js
[2] https://en.wikipedia.org/wiki/User:Huji/vector.js
The following code and comment appears in includes/db/Database.php:
protected function prepare( $sql, $func = 'DatabaseBase::prepare' ) {
/* MySQL doesn't support prepared statements (yet), so just
* pack up the query for reference. We'll manually replace
* the bits later.
*/
return array( 'query' => $sql, 'func' => $func );
}
However, the MySQL 5.7 documentation indicates that prepared statements are supported:
http://dev.mysql.com/doc/refman/5.7/en/sql-syntax-prepared-statements.html
Is the comment in Database.php outdated, and if so, could MediaWiki be made more secure against SQL injection by supporting prepared statements with recent versions of MySQL? Or does the support already exist, in spite of the comment?
Best wishes,
Tom
Wenlin Institute, Inc. SPC (a Social Purpose Corporation)
文林研究所社会目的公司
Software for Learning Chinese
E-mail: wenlin(a)wenlin.com Web: http://www.wenlin.com
Telephone: 1-877-4-WENLIN (1-877-493-6546)
☯
Thanks for all the comments Bawolff and Daniel!
They have confirmed the suspicion I had: using the 'Widget' extension
is a way to insert something into Mediawiki... but it puts a hole into
the security framework-- especially if you are passing parameters to
the Widget.
Broadly speaking, the Widgets seem to be an avenue to fulfill the
needs of two different constituencies - (1) a constituency that wants
to add things the WikiMedia Foundation (WMF) isn't going to develop
'cause it doesn't fit with their mission, and (2) a constituency to
add things that the WMF hasn't prioritized but could be useful to the
WMF.
OpenSeadragon I think fits with the later... and it begs the question:
How to generate enthusiasm for getting OpenSeadragon securely
integrated into MediaWiki?
At a functional level a deep zoom image (DZI) is an image... if
implemented it might improve on the current paradigm of a small
thumbnail-click for link to WikiCommons-click *again* for full
resolution of image; in OpenSeadragon
(as implemented with the widget) it is zoom with roller, click for
fullscreen with OpenSeadragon.
Once again thanks,
Michael
Quoting "Dr. Michael Bonert" <michael(a)librepathology.org>:
[Hide Quoted Text]
Hello,
I was wondering about the security of Widgets (
https://www.mediawiki.org/wiki/Extension:Widgets ) that get parameters
passed to them. Any thoughts?
Are the parameters passed through to the widget cleansed of html/scripts?
If it isn't -- is it possible to easily enforce typing/boundaries on
the parameters?
Generally, speaking, I am looking for a discussion around security & widgets.
A widget I created (below) takes three parameters (width, height,
filename) and feeds those to OpenSeadragon(
https://openseadragon.github.io /
https://en.wikipedia.org/wiki/Seadragon_Software ). It works on a
testing
server.
OpenSeadragon was discussed in brain storming in 2015 -
https://www.mediawiki.org/wiki/Reading/Quarterly_Brainstorming
My interest in this is virtual (microscopic) slides (e.g.
http://openslide.org/demo/ ) which are often
several gigabytes of data each.
Thanks,
Michael
------------------------
Widget code...
Create page: Widget:OpenSeadragon
---------------------------------------------------------------------
<noinclude>__NOTOC__
<!-- Copyright (c) 2016 Michael Bonert -->
<!-- Released under GNU General Public Licence - Version 3; see
http://www.gnu.org/licenses/gpl.html -->
To insert this widget, use the following code:
<nowiki>{{#widget:</nowiki>{{PAGENAME}}<nowiki>
|image=12881.dzi
|width=800
|height=600
}}</nowiki>
</noinclude>
<includeonly><!-- This inserts an OpenSeadragon image -->
<div id="openseadragon1" style="width:
<!--{$width|default:400|escape:'html'}-->px; height:
<!--{$height|default:300|escape:'html'}-->px;"></div>
<script src="../../openseadragon/openseadragon.min.js"></script>
<script type="text/javascript">
var viewer = OpenSeadragon({
id: "openseadragon1",
prefixUrl: "../../openseadragon/images/",
tileSources: "../../vslide/<!--{$image|escape:'urlpathinfo'}-->"
});
</script>
</includeonly>
-------------------------------------------------
Delete | Reply | Reply to All | Forward | Redirect | View Thread |
Blocklist | Acceptlist | Message Source | Resume | Save as | Print
Move | Copy
Back to sent-mail <
>+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Michael Bonert, BASc (Mech Eng), MASc (Biomed Eng), MD, FRCPC
Board Member and Founder
Libre Pathology Limited
Newfoundland and Labrador
Email: michael(a)librepathology.org
Mobile: 289 776-8722
Web: http://librepathology.org
Twitter: http://twitter.com/librepathology
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Hello,
I was wondering about the security of Widgets (
https://www.mediawiki.org/wiki/Extension:Widgets ) that get
parameters passed to them. Any thoughts?
Are the parameters passed through to the widget cleansed of html/scripts?
If it isn't -- is it possible to easily enforce typing/boundaries on
the parameters?
Generally, speaking, I am looking for a discussion around security & widgets.
A widget I created (below) takes three parameters (width, height,
filename) and feeds those to OpenSeadragon(
https://openseadragon.github.io /
https://en.wikipedia.org/wiki/Seadragon_Software ). It works on a
testing
server.
OpenSeadragon was discussed in brain storming in 2015 -
https://www.mediawiki.org/wiki/Reading/Quarterly_Brainstorming
My interest in this is virtual (microscopic) slides (e.g.
http://openslide.org/demo/ ) which are often
several gigabytes of data each.
Thanks,
Michael
------------------------
Widget code...
Create page: Widget:OpenSeadragon
---------------------------------------------------------------------
<noinclude>__NOTOC__
<!-- Copyright (c) 2016 Michael Bonert -->
<!-- Released under GNU General Public Licence - Version 3; see
http://www.gnu.org/licenses/gpl.html -->
To insert this widget, use the following code:
<nowiki>{{#widget:</nowiki>{{PAGENAME}}<nowiki>
|image=12881.dzi
|width=800
|height=600
}}</nowiki>
</noinclude>
<includeonly><!-- This inserts an OpenSeadragon image -->
<div id="openseadragon1" style="width:
<!--{$width|default:400|escape:'html'}-->px; height:
<!--{$height|default:300|escape:'html'}-->px;"></div>
<script src="../../openseadragon/openseadragon.min.js"></script>
<script type="text/javascript">
var viewer = OpenSeadragon({
id: "openseadragon1",
prefixUrl: "../../openseadragon/images/",
tileSources: "../../vslide/<!--{$image|escape:'urlpathinfo'}-->"
});
</script>
</includeonly>
-------------------------------------------------
Hello list members!
First of all: If you haven't used one of the extensions (CookieWarning[1] or
CookiePolicy[2]) and don't plan to use one of them in the future, you can
stop reading here :)
tl;dr: The extension CookiePolicy is no longer available and was marked as
archived, please use CookieWarning in the future. All functions of
CookiePolicy was merged into CookieWarning.
We found, that we'd two extensions, which aimed to solve the same problem.
Both of them accomplished the goal in slightly different, but basically
same, ways. That's why we decided to merge both extensions into one
resulting extension. The goal of this merge process is/was to make it less
confusing for users. The whole process is tracked in T145723[3] and it's
subtasks. This e-mail is to inform you what happened and what you probably
need to do now.
First of all: As the phabricator task shows, all functions of CookiePolicy
and CookieWarning are preserved in the resulting extension CookieWarning.
However, if you switch to the CookieWarning extension from CookiePolicy,
you'll need to adjust some settings. The same may apply to users of
CookieWarning, who upgrade to a newer version.. So please make sure you
reviewed the migration steps (available on the extension page of
CookieWarning[4]) and the new configuration options, especially its default
values.
If you currently use CookiePolicy on your wiki, it's strongly suggested to
switch to the new CookieWarning extension! Otherwise, you'll don't get any
updates anymore.
If you find any bugs or have feature requests, feel free to report them in
phabricator[5].
For anyone who wants to submit a patch to CookiePolicy or CookieWarning,
please make sure, that the mediawiki/extensions/CookiePolicy[6] project in
gerrit was marked as read-only and does not accept any changes anymore.
Please submit your changes to the mediawiki/extensions/CookieWarning[7]
project. Thanks :)
If you've any questions, feel free to answer to this e-mail, contact me in
IRC or open a new thread on the talk page :)
Have a nice weekend,
Florian
[1]
https://www.mediawiki.org/w/index.php?title=Extension:CookieWarning&oldid=22
41035
[2]
https://www.mediawiki.org/w/index.php?title=Extension:CookiePolicy&oldid=218
8043
[3] https://phabricator.wikimedia.org/T145723
[4] https://www.mediawiki.org/wiki/Extension:CookieWarning
[5]
https://phabricator.wikimedia.org/tag/mediawiki-extensions-cookiewarning/
[6]
https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/CookieP
olicy
[7]
https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/CookieW
arning
Greetings,
My work group runs a small inter-office wiki (MediaWiki) with a MariaDB backend. One of our side projects is to explore the possibility of integrating the wiki with one of our pre-existing information management systems. W were thinking that a database trigger could be used to call a stored procedure to export the data but we are running into problems implementing this solution.
==The Problem==
Every time we try to implement a trigger, the MediWiki instance reports the following error:
"A database query error has occurred. This may indicate a bug in the software."
==The Code==
A slightly redacted version of the trigger:
DELIMITER // CREATE TRIGGER [trigger name] AFTER UPDATE on text FOR EACH ROW BEGIN CALL [name of our stored procedure]; END; // DELIMITER;
The stored procedure itself has been tested and functions properly but I am not able to share the code. All I can say is that it builds and executes prepared statements in the course of its operation.
==The Question==
Has anyone else run into this problem? If so, what was the solution? Or am I bumping up against a database constraint that I am (obviously) unaware of?
Thanks in advance for any replies!
Sent from [ProtonMail](https://protonmail.ch) on my PDP-11
Hello all,
I would like to announce the release of MediaWiki Language Extension
Bundle 2016.10. This bundle is The bundle is compatible with MediaWiki
1.26 and 1.27 or above and requires PHP 5.5.9 or above.
Next MLEB is expected to be released in 3 months. If there are major
changes or important bug fixes, we will do intermediate release.
Please give us your feedback at
[[Talk:MLEB|https://www.mediawiki.org/wiki/Talk:MLEB]].
* Download: https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2016.10.tar…
* sha256sum: f82ac16b1a71433d68066c684c2e67379d3c435d1938044a9f0f0582cb6549b3
Quick links:
* Installation instructions are at: https://www.mediawiki.org/wiki/MLEB
* Announcements of new releases will be posted to a mailing list:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-i18n
* Report bugs to: https://phabricator.wikimedia.org/
* Talk with us at: #mediawiki-i18n @ Freenode
Release notes for each extension are below.
-- Kartik Mistry
== Highlights and upgrade notes ==
* Easy way to access wikitext editor from Special:Translate. T48955
* Special:Translate now works with MobileFrontend. T102922
* Special:Translate now works better in mobile devices. T146134
* WebAPI module to query user's babel languages.
* The style of ULS's dialogs have been updated and polished to be more
streamlined (for real this time, was incorrectly claimed to be
included in 2016.08).
== Babel ==
* Kunal Mehta made is possible to store babel languages in the
database for efficient querying if a configuration option is enabled.
* Kunal Mehta added an WebAPI module to query user's babel languages.
* Kunal Mehta made it possible to read user's babel languages from a
central wiki if a configuration option is enabled. T95877
* Ricordisamoa added a configuration option that can be used to set
namespace limits to restrict for which pages are automatically
categorized to babel categories. T69334
* Niklas Laxström removed references to non-existing configuration
option BabelPreferISO639_3.
* Kunal Mehta made the new babel database table to start populating
automatically if it exists.
* Kunal Mehta changed the main babel category no longer include users
who set the skill level to zero. T146909
== CLDR and LocalisationUpdate ==
* Maintenance and localisation updates only.
== CleanChanges ==
* Niklas Laxström fixed a minor issue causing unnecessary code to load
on certain configurations. T146476
== Translate ==
* Glaisher improved how Translate checks and enforces restrictions for
non-translatable languages.
* C0nnex taught Translate to support new authentication method for
Microsoft Translate API. T46679
* Niklas Laxström removed the broken new line handling from Microsoft
Translate API support. T60121
* Jon Robson and Niklas Laxström made Special:Translate work with
Mobile Frontend. T102922
* Niklas Laxström polished Special:Translate to work better in mobile
devices. T146134
* Glaisher added way to access wikitext editor from Special:Translate. T48955
* Federico Leva and Niklas Laxström made "hide own translations"
button in Special:Translate only appear when relevant. T50972
* Erik Moeller added support for explicitly chosen namespace constant
in wfAddNamespace.
* Niklas Laxström fixed an issue causing email confirmation emails to
be sent twice for sandbox users. T147570
* Erik Moeller added support for CLDR-style plural keywords to JSON
file format support.
== UniversalLanguageSelector ==
* Amir Aharoni changed "Language search" to "Search for a language". T138235
* New design implemented by Niklas Laxström was imported from jquery.uls.
* Niklas Laxström improved language change tooltip positioning. T145483
* Amir Aharoni documented available hooks and added one new hook. T145755
* Fomafix improved and simplified the way the CSS is loaded for ULS
triggers to avoid flash.
* Ed Sanders updated beta feature image to use proper layout and
colours. T144428
* Niklas Laxström fixed an issue that caused unparsed plural syntax
appear in the compact language links. T148117
--
Kartik Mistry/કાર્તિક મિસ્ત્રી | IRC: kart_
{kartikm, 0x1f1f}.wordpress.com