Has the parser just been changed with regards to tildes (~~~~) inside
HTML comments? It appears they used to be ignored, and are now
suddenly being replaced en masse the next time someone edits the page
(and can't be easily reverted - it just changes the sig to the
reverter's instead). See
http://en.wikipedia.org/wiki/Wikipedia:Articles_for_creation/2006-06-02-ear…
for an example.
I distinctly remember there was a way to add a title to a special page
simply by entering in a URL, then adding the title to the wiki edit
field, and then saving. The new "writing a new special page" how-to is
very confusing - and it wants me to write PHP to get the title to show
up. There was an easier way...
I can't find this how-to anywhere- though I'm sure it used to exist. FX
can you walk me through how you've added a wiki page title to a special
page?
Thanks!
-----Original Message-----
From: mediawiki-l-bounces(a)Wikimedia.org
[mailto:mediawiki-l-bounces@Wikimedia.org] On Behalf Of Rick DeNatale
Sent: Thursday, May 19, 2005 2:33 PM
To: MediaWiki announcements and site admin list
Subject: Re: [Mediawiki-l] Re: How to create a new Special page
On 5/13/05, FxParlant <f-x.p(a)laposte.net> wrote:
> Hello;
> There is a paragraph on how to create a special page in the FAQ
>
>
>
http://meta.wikimedia.org/wiki/Meta:FAQ#How_do_I_add_my_own_dynamic_cont
ent_to_MediaWiki.3F
>
> It's not so difficult. At the end,it says you have to create a simple
> page and write the name of your special page in it. If you forget this
> the title of your special page will have < and > around. I
haven't
> got a clue why creating a page with the name in it solves this, but it
works
That page seems to have changed, it now just has a pointer to an
article about writing an extension which really doesn't seem to build
a special page.
I just figured out how to build a new special page which is like the
Uncategorized pages page, but looks at the Image namespace. I wrote it
up at http://meta.wikimedia.org/wiki/Writing_a_new_special_page
_______________________________________________
MediaWiki-l mailing list
MediaWiki-l(a)Wikimedia.org
http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
I'm currently trying to adapt several gadgets that are meant for wikis using the Monobook/Vector skins to the Monaco skin, and so far, I've managed to successfully port over the UTC Clock gadget and Sandbox page gadget to Monaco, but aside from those I've been having trouble since, frankly, my knowledge of Javascript/JQuery is slim and I'm not familiar with all the variables used in writing user scripts. I've fairly decent with CSS style sheets, but I still need help with Javascript, so does anyone know of some good resources I could look into, preferably tailored for writing scripts on MediaWiki?
Also, if anyone wants to see what I have done so far (and have released publicly), the wiki I have been testing my live gadget/user script code on is here:
https://mediawikitesters.orain.org/wiki/Main_Page
Lis ton message de Nganguem Victor avant qu'il ne soit effacé!
Pour lire ton message, suis simplement ce lien:
http://eu1.badoo.com/chatnoirxx/in/p4hxwt052ok/?lang_id=6
D'autres personnes sont aussi présentes:
Oded (Tel Aviv, Israël)
Priya (Udaipur, Inde)
RajaYogi BK (Udaipur, Inde)
Karuna (Udaipur, Inde)
Chika Reginald Onyia (Pnompen', Cambodge)
...Qui d'autre?
http://eu1.badoo.com/chatnoirxx/in/p4hxwt052ok/?lang_id=6
Les liens ne fonctionnent pas dans ce message? Copie les dans la barre d'adresse de ton navigateur.
Tu as reçu cet email suite à un message envoyé par Nganguem Victor de notre système. S'il s'agit d'une erreur, ignore simplement cet email. La requête sera alors effacée du système.
Amuse-toi bien !
L'équipe Badoo
Courrier automatique de Badoo suite à l'envoi d'un message à ton attention sur Badoo. Les réponses ne sont ni stockées, ni traitées. Si tu ne veux plus recevoir de message de Badoo, fais-le nous savoir:
http://eu1.badoo.com/impersonation.phtml?lang_id=6&mail_code=65&email=media…
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
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++