(Reposted from mediawiki-l due to zero responses.)
I've been adding custom tools to the WikiEditor toolbar (MW 1.17.0 version) and am running into difficulty with browser caching.
When I do something simple, such as adding a button or changing text in a dialog, the change doesn't take effect in my browser due to caching. Even if I hard-refresh (ctrl-F5), the changes do not appear. I have to delete my browser's cached content (e.g., in Firefox, Tools / Options / Advanced / Network / "Clear Now") to see the change. That seems extreme: a browser refresh or hard-refresh ought to be sufficient, right? Or ideally, no refresh at all.
This is in Firefox 7.1, Firefox 3.6, and IE8.
For example, I created a new dialog:
$('#wpTextbox1')
.wikiEditor('addModule', {
'dialogs': {
'mytool-module': {
title: "My title",
id: 'mytool',
html: function() {
return '<p>foo bar</p>';
},
...
which is launched from a button:
$('#wpTextbox1')
.wikiEditor('addToToolbar',
{
'section': 'main',
'group': 'insert',
'tools': {
'mytool': {
'label': 'my label',
'type': 'button',
'icon': mypath,
'action': {
'type': 'dialog',
'module': 'mytool-module'
}
}
}
}
);
Now if I modify the HTML of the dialog to be "foo bar BLAT" instead of "foo bar", I still see "foo bar" until I clear the browser cache.
However, I can change other parts (say, the button label) without this caching happening.
Is there something else special I should be doing to avoid this level of heavy caching?
Thanks,
DanB
Hi,
most of you already know about the small "virtual library" of MediaWiki
books (collections) on
http://www.mediawiki.org/wiki/MVL
I recently added links to the project site of OWASP to our security pages
https://www.owasp.org/ Open Web Application Security Project (OWASP)
because I like the OWASP site and this is a useful addition to
information we already have.
T.
I originally posted this idea on G+ and Arthur Richards suggested I cross-post it here. My friend, Isaac Potoczny-Jones is a computer security professional. He developed a new authentication schema that layers on top of existing technologies and leverages a user's smartphone and QRCodes to improve authentication usability, eliminate human-generated passwords, and further improve security by separating the authentication channel from the login session. He's calling this capability "Animate Login" and as part of the proof of concept, he developed a MediaWiki implementation. I believe the Wikimedia foundation should pursue adding this technique as part of the primary login options for it's projects. I would personally love to be able to just point my phone at the login screen and have the system log me in to Wikipedia without having to type anything or remember complex passwords. Wikimedia has worked hard to consolidate logins across the many projects over the last couple years and this would be a great way of providing seamless login. It should be very low overhead and relatively easy to implement. Isaac is very interested in seeing his tool put to use on Wikipedia. Wikimedia could lead the way to improved authentication that also vastly improves the user experience!
Isaac explains the project in some detail on this Google Plus post:
https://plus.google.com/u/0/112702172838704084335/posts/B9UR2zzDY3f?hl=en
His landing page for the project is here:
http://animate-innovations.com/content/animate-login
The website has videos, links to a MediaWiki instance where its in use and more.
>From the conversations I've had with him, I know that he has thought long and hard about this application and has sought to address/understand all of the potential attack vectors. Compared to human-generated passwords, this would be vastly more secure and dramatically improve the user experience of logging in. It might even entice new or old editors to login and give it a try and thus re-engage them in editing. I'm also certain it could generate a fair bit of buzz as people learn they can use their smartphone to login to Wikipedia.
I hope you'll consider working with Isaac. I'll point him to this thread so he knows it is here. I know he'd love to see this implemented in Wikipedia.
Don
Gentlemen, no matter if in Google search results, or Facebook link
previews, links that specifically have the zh-tw part in them
http://zh.wikipedia.org/zh-tw/ ...
still end up having simplified Chinese, despite no such simplified <title>
appearing in the entire page.
I suspect somehow the simplified Chinese version is considered Cache
Equivalent for <title> purposes ... but it is not and looks horrible to
me trying to present a fully Traditional appearing link.
Go ahead and test, share "http://zh.wikipedia.org/zh-tw/Gmail" via
Facebook, and notice the simplified Chinese there in the title of the
link created.
Hi,
Actually, I sent a mail to the maps mailing list already but there was
no feedback at all so I am taking Jeroens advice and try it again here,
there might be some users using maps and waiting for the image maps
feature. I already included some of the features suggested in my last
mail to "maps-l(a)lists.wikimedia.org" a little different though.
Recently I have been fixing the Maps extension openlayers image feature
to use images as maps again (the feature was broken around Maps 1.0).
Besides fixing the feature for the next version of maps, I have
implemented the following features already:
* Additional parameters on layer pages (unit, maxScale, minScale) to
better control how the map is being displayed.
* Markers can have a group, each group is represented as one overlay
layer and has its own marker colour (for default markers).
* the "display_..." functions/tags using a layer: page store this in the
database, layer-pages show which pages are using the layer and pages
using a layer will be purged when the layer changes.
* Database table for layers which should increase performance and allows
to define several layers in one page to group them. Using the layer page
name will include all of these group members into the base map-selection
of a map. Also, a <layer name="" type="">...properties...</layer> tag is
used to define layers now. Via 'name' the layer can have a name so a
specific group member layer can be used instead of the whole group of
layers defined on the same layer-page.
now I am writing because I am planing on implementing some more features
which I need some opinion on:
--------
1. I have implemented first attempts of allowing overlay maps. The
overlay feature introduces the attribute 'overlays' for 'display_map'
and 'display_point' like:
<display_map service="openlayers" layers="Moon Map" overlays="Moon
Station, Moon City">0,0</display_map>
where 'Moon Station' and 'Moon City' could be smaller maps located on
'Moon Map', simply images with more detail where you can zoom in from a
overall view of moon into a detail view of the base and the city. The
cool thing about this is, that overlay maps also could be displayed as
baselayers if you use them with the 'layers' parameter instead (since
they must have a layer: page anyway)
This works, but it doesn't make much sense without coordinates for the
overlays. So I am thinking about a appropriate syntax but can't come up
with anything nice:
<display_map service="openlayers" layers="Moon Map" overlays="Moon
Station|20;40, Moon City|100;40">0,0</display_map>
for example wouldn't be very consistent syntax compared to the other map
syntax and I don't even want to think about #display_points which has
some weird syntax compared to <display_points>
How about:
<display_map service="openlayers" layers="Moon Map" overlays="Moon
Station|Station, Moon City|City" addresses="Station (20,40), City
(100,40)">0,0</display_map>
So we would first declare some named addresses and assign them to
coordinates, from then on we can use the names for image layers just
like in mapping services like bing or google maps where you can just
write 'New York' instead of the actual geographical coordinates. And not
using the () within 'overlays' has the advantage that layer sites still
can contain '(' and ')' within the site name. It also allows to use the
addresses for markers like:
<display_points service="openlayers" layers="Moon Map" overlays="Moon
Station|Station, Moon City|City" addresses="Station (20,40), City (100,40)">
Station | Moon Station | This is the moon station | station.png | Group 1
</display_map>
So instead of using coordinates we can use names as coordinates for
markers within image layers as well!
This goes even one step further with the following...
2. ...allowing to define addresses within the layer page. This could be
a parameter 'addresses' which contains coordinates and names of
addresses which can be used for overlays and markers for 'display_point'
and for overlays using 'display_map'.
This could look like:
<layer type="image">
source = moon.jpg
...
addresses = station (20,40), city (100,40), ....
</layer>
addresses would be case-insensitive and would even make the use of the
'addresses' parameter within the display functions obsolete when using
overlays but the main advantage would of course be that markers can be
added very fast and without searching for coordinates first since all
important coordinates are described already.
'addresses' parameter of display functions will overwrite if one name is
given there and on a layer page.
3. its difficult with units. Layers can have different units like
degree, km, miles... I didn't look into how it works if markers with
units are defined in display_marker if there are layers with different
units. Perhaps we should allow coordinates with units like "20km,200m"
to make it clear. This could also be included in layer pages so we can
say "left-extend=20km" and stuff like that instead of having a "unit"
attribute.
There might me more simple solutions though, have not really looked into
that yet.
4. Since the custom layer features will require database support and
update now, we are thinking about making it as a separate extension for
Maps extension like SemanticMaps. Would be some work to separate all the
stuff though so I am also thinking about simply disabling the layers
functionality in case no database update was run yet - without throwing
any php errors.
--------
Any thoughts on that?
If you have any further ideas for the image layer feature, please write
a separate mail instead of answering to this one, except it is highly
related to one of the points above! Thanks!
Cheers,
Daniel
Hi,
With a lot of help from the folks in ops (special thanks to Rob,
Daniel and Ryan),
we've gotten the new continuous integration server up and running!
Right now, it's only running Jenkins (PHPUnit), but we should have TestSwarm
going in the very near future. The URL for all things testing is now:
http://integration.mediawiki.org
We've had a few bumps in the last ~48 hours in making sure all the tests are
consistently passing, but we've ironed out most of the issues by now and I
think we can begin relying on its output. The 'mw-jenkinsbot' bot in #mediawiki
will continue to report failures and such to IRC for us. I've also created a new
Bugzilla component--Wikimedia -> Continuous Integration--so feel free to file
bugs if you find issues with the new server (issues with the tests themselves
should be filed in MediaWiki -> Unit testing).
Some (lots) of documentation on mw.org is probably out of date now and links
will probably need updating, so if you come across any please go ahead and
fix them.
Thanks everyone for your help in getting this up and running, and welcome
everyone to our glorious new testing future.
-Chad
PS: The CruiseControl instance has been shut down completely (ci.tesla),
and the test Jenkins instance (ci2.tesla) will be shut down in a few days
when I'm confident we've fixed any remaining issues. Please update any
bookmarks you may have.
I just want to inform you about an LibreOffice Conference Announcements
dated October 14, 2011
"During the LibreOffice Conference, The Document Foundation has announced:
LibreOffice Online Prototype: ..
LibreOffice Online is based on GTK+ framework and HTML5′s canvas, and
has been developed by SUSE’s Michael Meeks, built on GTK+ broadway from
RedHat’s Alex Laarson."
Source:
http://blog.documentfoundation.org/2011/10/14/libreoffice-conference-announ…
Tom