> you can obtain from your gerrit settings (however, I would prefer
> working with ssh :P).
>
> Best,
> Florian
>
> -Ursprüngliche Nachricht-
> Von: Wikitech-l [mailto:wikitech-l-boun...@lists.wikimedia.org] Im
> Auftrag von Daniel Barrett
> Gesendet:
I’ve finally solved my failures with VisualEditor in 1.28. The wiki server
(Ubuntu)
was missing the php-curl package. After installation, VisualEditor works
flawlessly.
I was able to diagnose this by watching the network traffic between MediaWiki
and parsoid
using Chrome’s developer tools (the
On 2016-12-20 06:22, Daniel Barrett wrote:
>>> My goal is to remove some special pages for anonymous users but permit
>>> logged-in users to see them.
>>> Is there a better way to check for a logged-in user at this hook point?
>>> Or a better way to remo
_______
From: Daniel Barrett
Sent: Monday, December 19, 2016 8:21 PM
To: Wikimedia developers
Subject: Re: [Wikitech-l] VisualEditor in 1.28 - fails after upgrade from 1.27
> Ok, that's a start. Can you get the rest of the stack trace for the
> exception so we can figure out how that's getti
On 19 December 2016 at 14:48, Daniel Barrett <d...@cimpress.com> wrote:
>> Maybe it was this ticket in September?
>> https://phabricator.wikimedia.org/T146686<https://phabricator.wikimedia.org/T146686>
Alex Monk <am...@wikimedia.org> writes:
>Yes, that loo
the first time I've seen it...
On 19 Dec 2016 3:31 pm, "Brad Jorsch (Anomie)" <bjor...@wikimedia.org>
wrote:
> On Mon, Dec 19, 2016 at 8:20 AM, Daniel Barrett <d...@cimpress.com> wrote:
>
> > Here you go:
> >
> >
> > BadMethodCallException f
Maybe it was this ticket in September?
https://phabricator.wikimedia.org/T146686
I’ll try to get a full stack trace later today when I have access to the wiki
again.
DanB
From: Wikitech-l [mailto:wikitech-l-boun...@lists.wikimedia.org] On Behalf Of
Alex Monk
Sent: Monday, December 19, 2016
27
Thanks Andre. Yeah, I'll need more than that to help.
On 19 Dec 2016 10:10 am, "Andre Klapper" <aklap...@wikimedia.org> wrote:
> On Mon, 2016-12-19 at 02:05 +, Daniel Barrett wrote:
> > /*
> > [37fc66f00dced89747fd4433] 2016-12-18 23:40:16: Fa
Here's what Chrome shows me. If you can tell me how to get more detail, I'll be
happy to do it.
load.php?debug=false=en=startup=scripts=vector:4
[37fc66f00dced89747fd4433] 2016-12-18 23:40:16: Fatal exception of type
"BadMethodCallException"
(anonymous) @
_____
From: Daniel Barrett
Sent: Sunday, December 18, 2016 6:31:16 PM
To: Wikimedia developers
Subject: VisualEditor in 1.28 - fails after upgrade from 1.27
After updating my wiki from 1.27.1 to 1.28.0, VisualEditor has stopped working.
I click the Edit tab, and the page content fades slightl
After updating my wiki from 1.27.1 to 1.28.0, VisualEditor has stopped working.
I click the Edit tab, and the page content fades slightly in color as if
VisualEditor were about to load. But then the editor tools don't appear, and
Chrome displays a dialog box:
example.com responded:
In a custom extension, I have a unit test that was working fine in MediaWiki
1.26, but it fails in MediaWiki 1.27. I'd appreciate any pointers in the right
direction.
The extension performs a page move, more or less like this (but with error
checking):
$mp = new MovePage($source,
Never mind - solved it. I discovered that one of my phpunit test files contains
@requires extension mysql
and this extension is gone in PHP 7.0.
DanB
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
[Tried mediawiki-l, now trying wikitech-l]
What does it mean when I run MediaWiki unit tests on my server, and phpunit
skips some tests with this error:
Extension mysql is required
This is on a fully working MediaWiki server with mySQL installed, running on
Ubuntu 16.04.
$ mysql --version
>On Tue, Jul 12, 2016 at 11:01 AM, Daniel Barrett <mailto:d...@cimpress.com>
>wrote:
>> What is the proper incantation for faking a successful login (for a given
>> user) as part of a unit test? My old code was:
>>
>> $context = RequestContext::getMain();
>&
What is the proper incantation for faking a successful login (for a given user)
as part of a unit test? My old code was:
$context = RequestContext::getMain();
$specialPage = new LoginForm( $context->getRequest() );
$user->logout();
$specialPage->showReturnToPage('successredirect');
James, thank you much for your detailed response!
Regarding the tag not being visible in the VE menu:
>Yeah, this is something I'm not totally sold on how we can solve. Giving
>immediate access to all 20+ text styling options wouldn't be so great
>(overwhelming, and encouraging people to use
Within the next few weeks, I'll be deploying VisualEditor for 1000+ authors
here at Cimpress/Vistaprint, in a wiki with 225,000 articles.
I plan to collect feedback from our users on what works and what doesn't. What
would be the best way to communicate this feedback to Wikimedia?
Here are
I was looking through the VisualEditor roadmap
(https://www.mediawiki.org/wiki/VisualEditor/Roadmap) and did not notice
anything about third-party MediaWiki extensions for the editor. Did I miss it?
I do see plans for "non-Mediawiki" extensions (under "Release for third-party
non-MediaWiki
to be in touch with, along with others on the
VosualEditor team, who are easily reached on IRC. See the MediaWiki page on
VisialEditor for details.
- Trevor
On Thursday, January 21, 2016, Daniel Barrett <d...@cimpress.com> wrote:
> I was looking through the VisualEditor roadmap
Last week, I asked the right way to inject raw JavaScript so that "mw" and
"jQuery" were defined. I was helpfully pointed to
ResourceLoader::makeInlineScript(), which wraps the JS in the appropriate magic:
https://lists.wikimedia.org/pipermail/wikitech-l/2015-December/084408.html
Now,
h-l [mailto:wikitech-l-boun...@lists.wikimedia.org] On Behalf Of
Daniel Barrett
Sent: Wednesday, December 30, 2015 11:03 AM
To: Wikimedia developers
Subject: Re: [Wikitech-l] The right way to inject user-supplied JavaScript?
Kevin Israel writes:
>Since MediaWiki 1.26, all ResourceLoader modules are
Kevin Israel writes:
>Since MediaWiki 1.26, all ResourceLoader modules are loaded
>asynchronously, so inline scripts now need to account for the
>possibility they may be executed before the jquery and mediawiki modules
>have loaded.
>
>If you use ResourceLoader::makeInlineScript() to build the
tl;dr: What's the right way for a tag extension to execute JavaScript provided
by the user? (On a private wiki without Internet access.)
Details:
I run a private wiki for developers (not accessible from the Internet) that
lets any wiki page author run JavaScript on a page by adding a tag:
MZMcBride writes:
>It also seems worthwhile to note that "Special:Search" already has an
>advanced profile/tab where users can select arbitrary namespaces to search.
Technically that is true, but I suspect that 95% of the time, 95% of users care
only about the main namespace. Filter by category,
Brian Wolff writes:
>I feel like the types of people who use shared hosting are very unlikely to be
>following this list.
I am one of those people. I happily use shared hosting for MediaWiki because
(1) it is very cheap and (2) I don't have to maintain the OS.
DanB
https://people.wikimedia.org/~ori/geshi_changes.txt
What about languages that aren't listed in your Supported or Unsupported
lists? We use lang=tsql in many pages on our wiki, for T-SQL, but it's not
clear to me what the replacement is. Thanks.
DanB
Here is another practical example where nowiki/ may be required:
https://www.mediawiki.org/wiki/Extension:Arrays#Using_arrayprint
DanB
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
What is the best way (in code) to locate the most recent revision of article in
which the text actually changed? That is, the revision was not a move or
other non-editing operation?
I figure the logic would be something like:
$r = GetTheMostRecentRevision();
IF $r NOT a Move
THEN
return $r
Will anything bad happen if entries in the MediaWiki logging table are not
inserted in chronological order?
Due to a bug, our logging table has incomplete data. I'd like to insert the
missing data using a script.
However, the log_id column is auto-increment. This means that when the table is
I'm writing a parser function extension that outputs about 5000 lines of text
(an organizational chart of a company) as a nested, bulleted list.
* Bob the CEO
** Jane Jones
** Mike Smith
*** etc.
It takes about 3 seconds (real time) for MediaWiki to render this list, which
is acceptable.
I have an extension that affects wiki tables using JavaScript. In order for it
to work, I need it to load *before* one of the core JS modules,
jquery.tablesorter.
Is there a supported way to modify the ResourceLoader dependencies of
jquery.tablesorter?
Effectively I want to do something like:
Thanks for the suggestion to use position=top. I'll try that.
DanB
My email address has changed to d...@cimpress.com. Please update your address
book.
Cimpress is the new name for Vistaprint NV, the world’s leader in mass
customization. Read more about
On Tue, Apr 22, 2014 at 12:36 AM, Daniel Barrett d...@vistaprint.comwrote:
We modified the code for foobar to add a feature: autocategorizing.
[Now] if you visit an article Blat that
previously contained foobar, you will see it is properly categorized
at the bottom. However, if you visit
I'm the original poster -- here is my real-world use case where a null edit is
required.
My wiki has a custom parser tag, (say) foobar. Many articles include it in
their wikitext.
We modified the code for foobar to add a feature: autocategorizing. It
automatically categorizes any article
Federico Leva (Nemo) writes:
https://www.mediawiki.org/wiki/Manual:Pywikibot/touch.py is regularly used to
make millions null edits, don't bother inventing something else.
Awesome! This worked perfectly. Thank you so much!!
DanB
___
Wikitech-l mailing
What is the proper way to make an empty edit of an existing article
programmatically, in a maintenance script? I tried this:
$title = Title::newFromText(My existing article name); // succeeds
$wikiPage = new WikiPage($title); // succeeds
I asked:
What is the proper way to make an empty edit of an existing article
programmatically, in a maintenance script?
Bartosz Dziewonski replied:
I'd look at maintenance/edit.php if I were you :)
Thanks. I just tried the technique in edit.php and it worked great... at first.
I merely
https://www.mediawiki.org/wiki/MediaWiki/Homepage_redesign/Preview
What requirements is this page supposed to meet? It's hard to say if it's
good without knowing what it's supposed to do. Apologies if I missed a memo.
DanB
___
Wikitech-l mailing
Search around for '255' appearing in .php, .inc, or .js files and change the
checks to 1023. [...]
Should someone maybe define a constant Title::MAX_LENGTH instead of hard-coding
255 in many PHP files?
DanB
___
Wikitech-l mailing list
Is it dangerous to call WikiPage-doEdit inside a parser tag callback?
I'm writing a parser tag extension whatever, whose callback function is:
public static function myCallback($input, $argv, $parser) {
$t = Title::newFromText('anytitle'); // any article title at all
$p =
Thanks for your suggestion!
I wound up deferring the edits by adding them to the MediaWiki job queue.
DanB
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
The extension [1] changes the RC view so that any changed article is only
listed *once*.
Are you aware that Preferences has an option to do something similar?
Group changes by page in recent changes and watchlist (requires JavaScript)
DanB
___
The MediaWiki API seems to add paragraph tags when it parses wikitext, but only
sometimes. Example:
http://www.mediawiki.org/w/api.php?action=parsepage=Extension:Header/versionformat=jsonprop=text
This page (Extension:Header/version) contains only the text 1.0 but gets
turned into p1.0/p when
I think your question answers itself, because you have a syntax error in your
suggested HTML string:
$html = 'div class=foo'p'
...
Use the Html class and you'll have fewer worries about malformed HTML.
WordPress code is full of hard-coded HTML strings and it's maddening to read
and
Of Mariya Nedelcheva
Miteva
Sent: Tuesday, February 12, 2013 9:23 AM
To: Daniel Barrett; Wikimedia developers
Subject: Re: [Wikitech-l] Stable PHP API for MediaWiki ?
By the way, Daniel, have you had similar problems with your next upgrades?
Maybe things have indeed improved since your post about
I wished for:
1. A desire for a department to have their own space on the wiki.
S Page asked:
I assume you looked at enabling subpages in the main namespace?[1]
That way Human Resources/Payroll/Show_me_the_money gets a nice breadcrumb up
to Payroll
and Human Resources landing pages.
vita...@yourcmc.ru writes:
I think it would be good if you provide some examples - what changes were a
problem for someone?
See extensive examples in my post about 1.18 update difficulties:
http://lists.wikimedia.org/pipermail/wikitech-l/2012-January/057486.html
DanB
vita...@yourcmc.ru writes:
In our organisation (CUSTIS, Russia) we easily solve it by creating one
primary wiki + separate ones for different departments.
In practice, we have found this doesn't work well for us (with thousands of
employees).
Each department winds up writing its own wiki page
Vistaprint (www.vistaprint.com) has a hugely successful MediaWiki system
internally. 150,000+ topics, 1000+ active users across several continents, five
years of history, and a fully supported team of developers to create
extensions. (We are looking into open-sourcing some of them.)
The main
Lee Worden worden@gmail.com wrote:
is there a plan
for extension developers to be able to hook in to provide editing for
the things their extensions support?
Roan Kattouw responded:
Yes, absolutely! We've been working on cleaning up and rewriting various
internal APIs in VE
such that
bawolff wrote:
You're calling the recursiveTagParse while the parser is not in a parsing
state.
Thanks for the explanation.
The easiest way to do this is to have some text yadda yaddamytagfoo/mytag
and pass it to $wgParser-parse
I tried this:
I'm trying to test a parser tag extension with phpunit and have run into a
strange problem. Whenever my extension calls $parser-recursiveTagParse(), the
unit
test blows up in Parser.php, complaining that $parser-mOptions is a non-object.
The tag callback looks pretty normal:
static function
Is there any easy way (via extension) to modify the src attribute of images
on wiki pages?
I see hooks for modifying href values - LinkBegin and LinkEnd. But I don't see
something similar for images, whose URLs seem to be produced via File::getUrl().
Purpose: I want to add a querystring
Can an extension detect that a given article has been transcluded from a given
namespace? Here's why I ask.
On our wiki, we have an extension with a special restriction: it can be used
only in a specific namespace, N. So it contains logic like this:
if ($title-getNamespace() == NS_N) {
//
On 29/06/12 21:42, Daniel Barrett wrote:
How can I prevent this conversion so ampersands (and presumably other
special characters) are preserved?
Followup up my own question: StripState is not relevant here. It's the fact
that it's a parser tag extension. Simply returning in the callback
I have a parser tag extension that calls $parser-insertStripItem() to add some
text to StripState:
function myCallback($input, $argv, $parser) {
return $parser-insertStripState(this is a test);
}
When the text renders on the wiki page, however, all ampersands have been
converted
How can I prevent this conversion so ampersands (and presumably other special
characters) are preserved?
Followup up my own question: StripState is not relevant here. It's the fact
that it's a parser tag extension. Simply returning in the callback will
produce amp;. Is there a way to
than
amp; ?
Reference:
http://www.mediawiki.org/wiki/Manual:Tag_extensions#How_can_I_avoid_modification_of_my_extension.27s_HTML_output.3F.
This is MediaWiki 1.18.1.
Thanks,
DanB
_
From: Daniel Barrett
Sent: Friday, June 29, 2012 3:42 PM
To: 'Wikimedia
Roan writes:
It sounds to me like stripState should have a way to change what a
given strip marker's value is after you've already inserted it. That
in combination with a hook that runs at the right time (after all the
stripping is done but before the unstripping begins) would fix your
problem
I wrote:
...the StripState class looks remarkably closed. All the members are protected
(not public),
and I didn't see any accessor functions to change the values of strip markers.
I worked around this by defining a subclass of StripState, MyStripState, that
can change those protected members:
I have a parser function #lookup that performs a database query, given a string
key. When a wiki page contains {{#lookup:MyKey}}, the callback function looks
up the associated value and uses StripState to place it into the article:
$parser-setFunctionHook('lookup', 'lookupCallback'));
...
Is there a method to list all pages which uses a certain parser
extension foo in a kind of auto-Category Pages-using-foo ?
This is my #1 most-requested feature for wiki admins. If someone were to
implement it, you'd have my undying thanks. :-)
DanB
How to add a tracking category to a parser extension tag:...
Yep, I know about tracking categories. But if there were a way to track ALL
parser tag extensions (i.e., what pages they are used on) without modifying
their source, that would be better.
DanB
Since moving to MediaWiki 1.18, several of our extensions that use namespaces
have broken in the following way. Any advice/explanation would be very much
appreciated! (I don't see anything in the release notes.)
Some of our extensions contain logic like this:
if ($wgTitle-getNamespace() ==
Just a quick note from an unbiased observer who loves MediaWiki and
open-source...
Proprietary or not, Atlassian Jira is the best bug-tracker I have ever used,
out of about 10 systems.
- Very configurable
- You can create very simple bug forms for nontechnical users
- Plug-in architecture for
I've finally fixed this, see
https://www.mediawiki.org/wiki/Special:Code/MediaWiki/110988 .
The fix will be in the 1.19 release.
You rock, Roan!!!
DanB
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
I am seeing some strange behavior regarding a wiki user's email address. When I
set it to the empty string, either via PHP or MySQL, MediaWiki still seems to
believe the old email address is still present. Any advice?
Background: We have a wiki extension that sets a user's email address if it's
I am seeing some strange behavior regarding a wiki user's email address.
I should also mention that this behavior is new in 1.18. In prior versions of
MediaWiki, if I blanked the email address in the database via SQL Update
statement, the first logout/login operation would restore it.
DanB
Since nobody responded, this is now bug 33926,
https://bugzilla.wikimedia.org/show_bug.cgi?id=33926.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
After enabling WikiEditor on our MediaWiki 1.17.1 system, a small number of
users are experiencing browser crashes in IE. (The whole browser hangs as
WikiEditor is rendering.)
The solution has been to visit My Preferences and simply click the Save button.
After that, no more crashes.
Any
http://test.wikipedia.org/?banner=blackout
As a writer, I believe the current message (The Wikipedia community has
authorized...) is long and wordy and therefore not likely to be read by most
users. I recommend shortening simplifying it. Here's an example that removes
30+ words and preserves
Rob, thanks for your comprehensive and thoughtful reply.
... bug 31676 (the 32-stylesheet limit of IE,
https://bugzilla.wikimedia.org/show_bug.cgi?id=31676) which IMHO is a
very serious time-bomb waiting to explode. I hope it makes it into
1.19wmf deployment as planned.
Is this all versions
As MediaWiki 1.19 is getting ready, I'd like to offer information on how
MediaWiki 1.18.0 was the most difficult MW upgrade I've ever been through.
Some background: my team administers an internal wiki at a major company with
~2000 users, over 100 extensions (many of them custom/unreleased),
Me:
8. Our MediaWiki:common.js stopped running on the login page. I realize
this was a security fix; it just took me by surprise. Fixed by writing a
custom extension using the hook UserLoginForm to inject the few lines of JS
we needed, and I'm evaluating other non-JS solutions for
In 1.18.0, the page Special:UserLogin no longer runs the JavaScript in
MediaWiki:common.js. Is this an intentional change from 1.17, and if so, is
there a workaround to make custom JS run on the login page?
(I tested this by putting alert('foo') in MediaWiki:common.js. The alert
appears on
You could probably hack around it by using one of the many hooks in the
page rendering stack to add the JS module on the pages where it's not
already there, but before doing so it's worth thinking about the reason why
it was removed in the first place.
Thank you HM. In our case, we are using a
On 11 January 2012 21:51, Daniel Barrett d...@vistaprint.com wrote:
* Remove any trailing @companyname.com from the username. Users in our
company are accustomed to logging in this way on
their Windows boxes, and we'd get several support calls per week from people
who can't log into the wiki
Sajith Vimukthi wrote:
I am planning to develop a new Open Source project keeping mediawiki as the
baseline
Nobody else said this explicitly, so
FYI Sajith, MediaWiki has a very powerful third-party plug-in system
(extensions). Maybe instead of modifying MediaWiki, you could just
Roan Kattouw wrote:
You probably need to do window.addHandler( .. ) instead?
Alternatively, use jQuery to bind events. If you just want to do
something upon document ready, use:
jQuery( document ).ready( function() { ... } ); or even jQuery(
function() { ... } );
Thanks Roan. I used your jQuery
The following JavaScript works fine in MediaWiki 1.17.1, when placed into a
ResourceLoader-loaded module, producing an alert box:
addHandler(window, 'load', function() {
alert('hello');
});
However, the same code does not seem to run in MediaWiki 1.18.0 in Internet
Explorer 8: no alert box is
Brion Vibber wrote:
My recommendation under ideal circumstances would be to use closures (needs
PHP 5.3) to wrap a parameter to your real callback; on older versions you
could use create_function which is ugly, but probably not much worse for
performance.
Thanks Brion. I have switched from
If I create a tag extension like this:
$parser-setHook('foobar', 'myCallback');
function myCallback($input, $args, $parser, $frame) {
return 'hello world';
}
can the callback myCallback efficiently detect the name of the parser tag,
foobar, that invoked it?
The business problem is this: I
Happy Melon suggests:
foreach( array( 'foo', 'bar', 'baz', quok' ) as $var ){
$parser-setHook( $var, WrapperClass::myCallback_$var );
}
...
Thanks for the suggestion. I am already doing something similar (see my
original note about dynamically creating 20 callbacks today), but it's
Now that skins/common/wikibits.js is gone, so is the function ts_makeSortable.
What is the equivalent call to ts_makeSortable(table) in MediaWiki 1.18?
Here is our code we need to convert:
function makesortable( context ) {
$('table.sortable', context)
.each(function(index, table){
Thomas Dalton writes:
The challenge is having pages that can be edited both by wysiwyg and in
wikitext without the
two tripping over each other.
To address this, I think any visual editor project needs to decide which
audience it's serving:
- The average user
- The average user AND power users
Thomas Dalton wrote:
even if power users don't use the new interface they
still need to be able to use the old one to edit the same articles. If the
wikitext created by the visual editor is unnecessarily complicated and
unreadable (like the html produced by ms frontpage, for instance) then
there
I also noticed the lack of documentation on LogPage so I just wrote this on
mediawiki.org:
http://www.mediawiki.org/wiki/Logging_to_Special:Log
Other developers -- please fill in more detail if you like!
DanB
___
Wikitech-l mailing list
I have a parser function that is not being rendered properly by the
experimental Preview tab in WikiEditor. The function does the following:
* It add a custom property foo to the ParserOutput object, with value
bar
* It hooks OutputPageBeforeHTML to render the value bar
When I use
Now that $wgMessageCache is obsolete in 1.18.0, what is the approved way for an
extension to add a system message dynamically at runtime?
That is, what is the new way to do $wgMessageCache-addMessage(a, b)?
http://www.mediawiki.org/wiki/Manual:$wgMessageCache does not say.
Thanks,
DanB
Tim Starling writes:
You should have a look at how tracking categories work in the core,
see Parser::addTrackingCategory().
Ooo, shiny! Thanks for the great tip.
Is there any way to use addTrackingCategory (or similar) if the category name
must be computed at runtime, not a piece of static
Is there any documentation on using the QueryPage class in an extension? I'd
like to create a special page with the QueryPage features but am running into
problems hooking it up to run. I don't see any QueryPage docs on
mediawiki.org or meta. (Or is there a more modern way to get a paging
Roan Kattouw asks:
getSQL() ?!? wfSpecialPopularpages() ?!? Are you sure you're looking at a
recent version of MediaWiki?
Yes, version 1.17.1:
https://svn.wikimedia.org/viewvc/mediawiki/tags/REL1_17_1/phase3/includes/specials/SpecialPopularpages.php?revision=104510view=markup
I see these
you should be able to create a QueryPage subclass in
an extension, set $wgSpecialPages['specialpagename'] =
'SpecialPageClass'; , add to $wgQueryPages (I forget the exact format
there), and you should be all set.
Thanks. I tried that, and when I added the $wgSpecialPages line, I got an error
Seeking help with Special:Log and the LogPage class...
I recently created a custom log and am writing information to it as follows:
$log = new LogPage('mylog');
$log-addEntry('mylog',
$wgTitle,
wfMsg('my-message',
To what degree are extensions derivatives, under copyright law, of MediaWiki
code?
IANAL, but I'd think that extensions are derivative of MediaWiki in the same
manner that my email is derivative of the English Language Dictionary.
DanB
___
Please consider https://bugzilla.wikimedia.org/show_bug.cgi?id=32241 (which I
just discovered and reported) for 1.18.0.
It causes your first WikiEditor operation (e.g., clicking the Bold button) to
fail if you are running Windows 7.
DanB
___
Roan writes:
This is probably a ResourceLoader thing, then, not directly related to
WikiEditor. Please try waiting 5-10 minutes for the cached version of
the startup module (the request with modules=startup) to expire (it
has s-maxage=300, max-age=300), then RL should request your module
with an
I waited 30 minutes after changing the JavaScript file but the change is still
not appearing in WikiEditor,
even after browser refreshes.
Hmmm... after about 60 minutes, the change showed up (after a hard refresh) in
WikiEditor. Any idea why it took so long?
DanB
Hmmm... after about 60 minutes, the change showed up (after a hard refresh) in
WikiEditor. Any idea why it took so long?
Something really weird is going on with caching and ResourceLoader/WikiEditor.
Originally my JavaScript file (loaded via ResourceLoader) emitted the string
A. I changed it
1 - 100 of 105 matches
Mail list logo
