[Wikitech-l] Disable module "mediawiki.searchSuggest" in MW 1.20+

[Robert Vogel]

Hi everybody!

I'm writing an extension that needs to replace/disable the build-in suggestion 
feature of the search box. In earlier versions this could be archived by 
setting $wgEnableMWSuggest 
(http://www.mediawiki.org/wiki/Manual:$wgEnableMWSuggest) to false. But with 
1.20 this option is no longer available.

In includes/OutputPage.php:2484 it seems that $wgUseAjax is the only condition 
(despite of user settings) that is evaluated to decide whether to add the 
module "mediawiki.searchSuggest" or not. But I don't want to disable the ajax 
features completely.

ResourceLoader doesn't offer me any hooks or interfaces that would allow my 
extension to remove the module programmatically.

Any hints on this? Thanks in advance!

Best regards,

Robert Vogel
Social Web Technologien
Softwareentwicklung
Hallo Welt! - Medienwerkstatt GmbH
__

Residenzstraße 2
93047 Regensburg

Tel.  +49 (0) 941 - 66 0 80-198
Fax   +49 (0) 941 - 66 0 80-189

www.hallowelt.biz<http://www.hallowelt.biz/>
vo...@hallowelt.biz<mailto:vo...@hallowelt.biz>


Sitz: Regensburg
Amtsgericht: Regensburg
Handelsregister: HRB 10467
E.USt.Nr.: DE 253050833
Geschäftsführer: Anja Ebersbach, Markus Glaser, Dr. Richard Heigl, Radovan 
Kubani


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Disable module "mediawiki.searchSuggest" in MW 1.20+

[Robert Vogel]

Hi Matt, hi Krinkle!

Thanks for your replies. 

@Matt: Thank you for the hint. I'm now using the hooks "UserGetDefaultOptions", 
"UserLoadOptions" and "GetPreferences" to set the "disablesuggest" useroption 
to true and to remove the checkbox in the user preferences. This works for me.

@Krinkle: I've written a custom API module that returns categorized results. I 
wanted to have a categorized output like in this demo: 
http://jqueryui.com/autocomplete/#categories
My first approach was to override some of the logic in 
"mediawiki.searchSuggest" on the client side. But this didn't work as I 
expected. Then I saw that "jquery.ui.autocomplete" was part of MW framework and 
so I tried to use this according to the demo I mentioned before. But 
"mediawiki.searchSuggest" always "occupied" the input element so I couldn't 
apply "jquery.ui.autocomplete" to it.
But now with the hint from Matt it works pretty good :)

Are there any future plans to make the removal of already added modules 
available in ResourceLoader?

-
Robert

-Ursprüngliche Nachricht-
Von: wikitech-l-boun...@lists.wikimedia.org 
[mailto:wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von Krinkle
Gesendet: Mittwoch, 16. Januar 2013 18:02
An: Wikimedia developers
Betreff: Re: [Wikitech-l] Disable module "mediawiki.searchSuggest" in MW 1.20+


On Jan 15, 2013, at 9:18 AM, Robert Vogel  wrote:

> Hi everybody!
> 
> I'm writing an extension that needs to replace/disable the build-in 
> suggestion feature of the search box. 
> 
> 

In case there may be a better approach to solve your problem, what is it you're 
looking to add to this feature?

Most of this module is pretty trivial and only wraps around other features that 
have elaborate hooks and toggles (such as PrefixIndex and the API).

-- Krinkle


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Disable module "mediawiki.searchSuggest" in MW 1.20+

[Robert Vogel]

Hi Krinkle!

Thanks for the clarification!

> mediawiki.searchSuggest does NOT use jquery.ui.autocomplete.

Yes, I know. I never said anything like this. Maybe this was a 
misunderstanding. I said I wanted to replace "mediawiki.searchSuggest" with my 
own implementation _based on_ "jquery.ui.autocomplete". As 
"jquery.ui.autocomplete" is delivered together with MW and can easily be made 
available on the client side thanks to ResourceLoader and its dependency 
management it was a good choice for me.


> Instead you'd register your own module with its own name and make sure it is 
> loaded instead of some other module. The method used can differ based on the 
> feature at hand, but handling this at the module level is not the way to go.

Yes I understand this. And I think this was my problem. I did not find a proper 
way to "make sure it is loaded instead of some other module", because 
'mediawiki.searchSuggest' module is added by OutputPage and there seems to be 
no way (but changing the current users settings as Matt suggested) to avoid 
that.


> I think in the case of SearchSuggest it should probably be loaded by the Skin 
> [...]

This would probably be a good idea as it may allow a more specific server side 
hook. :)


So, again, thanks for your explanations. Those where very helpful and I think I 
now have a better understanding of the concepts of modules.

--
Robert


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Disable module "mediawiki.searchSuggest" in MW 1.20+

[Robert Vogel]

Hi Thomas,

thanks for sharing your experiences. The issues you mention can truly be 
problematic. I will keep them in mind. But for my use case 
"jquery.ui.autocomplete" does work quite well.

> [...] and my advice for MediaWiki is, _not_ to go this way.

I don't think there were considerations about changing MediaWiki's built-in 
suggestion feature. That's not what this discussion is about. It's just about a 
little (very specific) extension I'm working on. :)

Robert


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Asynchronous JavaScript execution order questions

[Robert Vogel]

Hi Daniel,

I'm not very experienced with ResourceLoader, but maybe 'mw.loader.using()' [1] 
suits your needs. You can specify a module dependency and a callback function 
on the client side. 

Another way to keep the right execution order may be to establish some kind of 
"global hook system" within your own extensions. Let's say Extension2 depends 
on javascript code executed by Extension1. Then trigger [2] an event using 
jquery 

$(document).trigger( 'extension1-init', [this, param1, param2] );

In Extension1 and in your Extension2 just bind [3] to this event:

$(document).on('extension1-init', function( event, extension1, param1, 
param2 ){
//Extension2 code, i.e. modify extension1, param1 and param2
}

--
Robert

[1] http://www.mediawiki.org/wiki/ResourceLoader/Default_modules#mw.loader.using
[2] http://api.jquery.com/trigger/
[3] http://api.jquery.com/on/

-Ursprüngliche Nachricht-
Von: wikitech-l-boun...@lists.wikimedia.org 
[mailto:wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von Daniel Renfro
Gesendet: Mittwoch, 30. Januar 2013 17:37
An: wikitec...@wikipedia.org
Betreff: [Wikitech-l] Asynchronous JavaScript execution order questions

Let me first say that the ResourceLoader [1] is a wonderful part of the 
software. Thanks goes out to everyone who contributed to this project - it's 
made my life much better. That being said, I don't think that I and my team 
have figure out how to properly take advantage of its benefits.

At Vistaprint, we are currently using the ResourceLoader to load modules, some 
of which contain JavaScript. The dependencies are made explicit in the 
registering of the ResourceLoader, and they execute in the proper order on the 
client side. In many of these JavaScript files we wrap our code in a jQuery 
.ready() callback [2]. Since these JavaScript files have dependencies on 
one-another (as laid out in the RL,) they need to be executed in the correct 
order to work properly. We're finding that when using jQuery's .ready() (or 
similar) function, the callbacks seem to execute in different (unexepected, 
browser-dependent) order. This causes errors.

Using the WikiEditor extension as a specific example:
Customizing the WikiEditor-toolbar is one of the specific cases where we've 
encountered problems. First, the WikiEditor provides no good events to bind to 
once the toolbar is loaded. This is not a problem because there is a documented 
work-around [3]. However, our JavaScript code needs to execute in the proper 
order, which it is not. We have about four JavaScript files that add custom 
toolbars, sections, and groups.

My questions:
It recently dawned on me that executing our code within a $(document).ready(); 
callback might not be necessary as the JavaScript for each ResourceLoader 
module is executed in its own callback on the client-side. This should provide 
the necessary scope to avoid clobbering global variables along with getting 
executed at the proper time. Is this a correct assumption to make? Is it a good 
idea to avoid binding our code to jQuery's ready event?

--Daniel (User:The Scientist)

[1] http://www.mediawiki.org/wiki/ResourceLoader
[2] http://docs.jquery.com/Events/ready
[3] 
http://www.mediawiki.org/wiki/Extension:WikiEditor/Toolbar_customization#Modifying_things


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] wikidata-vagrant: SSH command responded with a non-zero exit status

[Robert Vogel]

Hi everybody!

I tried to set up a WikiData development environment using Vagrant[1]. At first 
everything seemed to be okay. The “precise64” VM was downloaded and the 
automated setup with “puppet” started. But then after Apache, MySQL and PHP 
were installed the following error occurred:

←[0;37mdebug: Puppet::Type::Package::ProviderApt: Executing 
'/usr/bin/dpkg-query -W --showformat ${Status} ${Package} ${Version}\n 
php5-dev'←[0m
←[0;37mdebug: Class[Php]: The container Stage[main] will propagate my refresh 
event←[0m
←[0;37mdebug: Finishing transaction 70306158277360←[0m
←[0;37mdebug: Storing state←[0m
←[0;32minfo: Creating state file /var/lib/puppet/state/state.yaml←[0m
←[0;37mdebug: Stored state in 0.04 seconds←[0m
←[0;36mnotice: Finished catalog run in 318.46 seconds←[0m
←[0;37mdebug: /File[/var/lib/puppet/rrd]/ensure: created←[0m
←[0;37mdebug: Finishing transaction 70306152454460←[0m
←[0;37mdebug: Received report to process from precise64.hw.local←[0m
←[0;37mdebug: Processing report from precise64.lmw.local with processor 
Puppet::Reports::Store←[0m
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!

cd /tmp/vagrant-puppet/manifests && puppet apply --verbose --debug --modulepath 
'/etc/puppet/modules:/tmp/vagrant-puppet/modules-0' base.pp 
--detailed-exitcodes || [ $? -eq 2 ]

When I execute this last command manually on the VM I get the error
err: /Stage[main]/Generic/Exec[fix-sources]/returns: change from notrun to 
0 failed: sed -i'' -e 's/us\.archive/archive/g' /etc/apt/sources.list returned 
4 instead of one of [0] at /tmp/vagrant-puppet/manifests/base.pp:13

This seem to be due to file permissions. Executing this command as root works 
fine but afterwards this error occurs:
err: /Stage[main]/Wikidata::Repo/Exec[repo_setup]/returns: change from 
notrun to 0 failed: /usr/bin/php /srv/repo/maintenance/install.php 
Wikidata-repo admin --pass vagrant --dbname repo --dbuser root --dbpass vagrant 
--server 'http://localhost:8080' --scriptpath '/repo' --confpath 
'/srv/orig-repo/' returned 1 instead of one of [0] at 
/tmp/vagrant-puppet/modules-0/wikidata/manifests/init.pp:38

The “/srv/repo/” folder is almost empty, which is probably because of earlier 
errors.
I am able to connect to “http://127.0.0.1:8080” and see the “welcome” page. But 
both links (“repo” and “client”) are dead.

Has anybody an idea what the problem might be? I’m using a Windows 8 machine as 
host.

Thanks!

[1] http://meta.wikimedia.org/wiki/Wikidata/Development/Setup

--

Robert Vogel
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] wikidata-vagrant: SSH command responded with a non-zero exit status

[Robert Vogel]

Hi,

never mind. I've submitted a bug report 
(https://bugzilla.wikimedia.org/show_bug.cgi?id=49944). If I can help you with 
more information, please let me know.

--
Robert Vogel
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New committer

[Robert Vogel]

Hi DJ and hi everybody!

Thanks for the warm welcome :), and DJ thanks for your hints/questions 
concerning SVN. I am quite busy at the moment so I did not set up my SVN client 
(Tortoise) for the MW repo yet. But I hope to get it done next week.

Afterwards I will start adding some of the announced extensions. The Azure 
stuff is already in SVN. Markus committed it.

I am very excited about your Azure extensions. You said you had everything 
working with MW 1.18 except the media storage? As far as I know you work on the 
database abstraction layer for Azure SQL. Is that right? So with the file 
backend we should have a complete "Azure bundle", shouldn't we?

--
Robert Vogel
Social Web Technologien
Softwareentwicklung
Hallo Welt! - Medienwerkstatt GmbH


__

Untere Bachgasse 15
93047 Regensburg

Tel.  +49 (0) 941 - 66 0 80 - 198
Fax   +49 (0) 941 - 66 0 80 - 189

www.hallowelt.biz
vo...@hallowelt.biz


Sitz: Regensburg
Amtsgericht: Regensburg
Handelsregister: HRB 10467
E.USt.Nr.: DE 253050833
Geschäftsführer: Anja Ebersbach, Markus Glaser, Dr. Richard Heigl, Radovan 
Kubani

-Ursprüngliche Nachricht-
Von: wikitech-l-boun...@lists.wikimedia.org 
[mailto:wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von DJ Bauch
Gesendet: Donnerstag, 12. Januar 2012 02:15
An: Wikimedia developers
Betreff: Re: [Wikitech-l] New committer

I will be trying again tonight. I got some hints from Ben Lobaugh. It
looks like the problem I've been having is that I was using the host
name in conjunction with my svn+ssh connection attempt, when I should
have been using the name of my PuTTY session.

On Wed, Jan 11, 2012 at 5:38 PM, Platonides  wrote:
> On 11/01/12 18:25, DJ Bauch wrote:
>> Welcome, Robert!
>> You and I should be crossing paths. I have everything working through
>> version 1.18 on Windows Azure, except for the media storage. Right
>> this moment I am trying to figure out how to get my code committed,
>> but I have been struggling with setting up the Subversion access from
>> my Windows 7 box. Any hints or pointers on how to set things up may
>> help me transition from a potential to an actual contributer.
>
> So, what are you trying to do? The cli or soething else?, did you read [1]?
> You will need to use plink on windows to make the ssh tunnel, pageant is
> recommended but not required (unless it's a plink with no console?).
>
> Take a look at [2].
>
> 1-http://www.mediawiki.org/wiki/Commit_access#Getting_started_and_set_up
> 2-http://agateau.wordpress.com/2007/07/03/windows-svnssh-and-the-subversion-command-line-client/
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Watchlist and RC refactor, and why you will like it

[Robert Vogel]

Hi,

Jeroen's suggestions are very interesting to me. There is one thing I don't 
understand: Why is it a bad idea to provide a hook handler with as much context 
information as possible? Isn't is better to have context injected to the hook 
handler than to have the hook handler look for the context in some other way? 
Maybe even by accessing global state?

--
Robert Vogel

-Ursprüngliche Nachricht-
Von: wikitech-l-boun...@lists.wikimedia.org 
[mailto:wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von Aaron Schulz
Gesendet: Freitag, 10. Januar 2014 04:14
An: wikitech-l@lists.wikimedia.org
Betreff: Re: [Wikitech-l] Watchlist and RC refactor, and why you will like it

I'd agree with the general statement on inheritance (which can have weird 
coupling and diamonds of doom) and hooks (which can lead to hard-to-specify 
behavior and tangle). I'm not familiar with the main problem with SpecialPage 
having been articulated though.



--
View this message in context: 
http://wikimedia.7.x6.nabble.com/Watchlist-and-RC-refactor-and-why-you-will-like-it-tp5019664p5019751.html
Sent from the Wikipedia Developers mailing list archive at Nabble.com.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Gadget I18N: Recommendation?

[Robert Vogel]

Hello everybody,

I'm trying to figure out the best method for internationalization/localization 
of MediaWiki Gadgets. There are several approaches implemented in the different 
available gadgets, but none of them seem to use MediaWikis client side message 
system. I want to use something like

mw.message('my-gadget-some-key').plain();

But this only works with message keys that are available on the client side, 
based on the 'messages' field of a server side module definition 
($wgResourceModules). The clientside

mw.loader.implement( moduleName, scripts, styles, messages );

has a parameter for a 'messages' config object. But it does not load the 
translation texts for the keys automatically. Actually it expects a JavaScript 
object that contains keys _and_ values [1]. I've tried whether the values get 
overridden when a translation on the MediaWiki-namespace is available, but they 
don't seem to. Am I missing something important? Can you recommend a method for 
I18N in a gadget?

Just for the record: I've been experimenting with keeping the messages in 
subpages ("MediaWiki:Gadget.-/de.js") in JSON format [2] and loading them on 
runtime via AJAX [3]. I think  this has some beauty because it's close to what 
MediaWiki does on the server side. Unfortunately in this case I'll have to 
implement a language fallback [4] by myself. Any thoughts or hints?

[1] https://www.mediawiki.org/wiki/ResourceLoader/Features#Response
[2] 
https://www.mediawiki.org/w/index.php?title=User%3AOsnard%2FGadget-Test%2Fde.js&action=raw&ctype=text%2Fjavascript
[3] https://www.mediawiki.org/wiki/User:Osnard/Gadget-Test.js
[4] 
https://www.mediawiki.org/wiki/Localisation#mediaviewer/File:MediaWiki_fallback_chains.svg

--

Robert Vogel
Softwareentwicklung



Hallo Welt! - Medienwerkstatt GmbH
Residenzstraße 2
93047 Regensburg

Tel.  +49 (0) 941 - 66 0 80-198
Fax   +49 (0) 941 - 66 0 80-189

www.hallowelt.biz
vo...@hallowelt.biz


Sitz: Regensburg
Amtsgericht: Regensburg
Handelsregister: HRB 10467
E.USt.Nr.: DE 253050833
Geschäftsführer: Anja Ebersbach, Markus Glaser, Dr. Richard Heigl, Radovan 
Kubani


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Gadget I18N: Recommendation?

[Robert Vogel]

Hi Helder,

this is great news, thank you. Unfortunately there is not much information on 
_how_ to register the messages. I guess the code listing below "gd_shared" [1] 
with the line 

"messages": ["foobar-welcome", "foo-bye", "recentchanges"],

shall be an example definition. It probably is intended to go on some Gadget 
definition page in the MediaWiki namespace, doesn't it?

Do you know about the current state of Gadgets 2.0? Last edit of the page was 
in February, the talk page is of July 2013 and the Roadmap [2] doesn't contain 
any dates. 
On the talk page Krinkle states in 2013 that is almost ready but VisualEditor 
was more important and took the resources.

[1] 
https://www.mediawiki.org/wiki/ResourceLoader/Version_2_Design_Specification#Storage_of_Gadget_definition
[2] https://www.mediawiki.org/wiki/Extension:Gadgets/Roadmap#Gadgets_2.0

--
Robert


-Ursprüngliche Nachricht-
Von: wikitech-l-boun...@lists.wikimedia.org 
[mailto:wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von Helder .
Gesendet: Dienstag, 22. Juli 2014 22:30
An: Wikimedia developers
Betreff: Re: [Wikitech-l] Gadget I18N: Recommendation?

Gadgets 2.0 will solve this:
https://www.mediawiki.org/wiki/Gadgets_2.0#Messages

Helder
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Gadget I18N: Recommendation?

[Robert Vogel]

Hi Bartosz,

thank you very much. This is exactly the information I needed.

--
Robert

-Ursprüngliche Nachricht-
Von: wikitech-l-boun...@lists.wikimedia.org 
[mailto:wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von Bartosz 
Dziewonski
Gesendet: Mittwoch, 23. Juli 2014 17:19
An: Wikimedia developers
Betreff: Re: [Wikitech-l] Gadget I18N: Recommendation?

You can use mw.messages.set( { key: 'value', … } ) to set the message keys that 
are used by mw.message() and mw.msg(). No need for
mw.loader.implement() (in fact, you should probably never call that function at 
all).

This has no i18n support by itself, so you have to handle that part yourself 
(either loading them from somewhere else or just keeping the entire list in 
source code). A very simple practical example (with no language fallback chain 
support, it just falls back to English):

var translations = {
en: {
'my-gadget-some-key': "My message"
},
pl: {
'my-gadget-some-key': "Moja wiadomość"
}
};

var userLanguage = mw.config.get( 'wgUserLanguage' );
mw.messages.set( translations[userLanguage] || translations.en );

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Tutorials / HowTos for VisualEditor

[Robert Vogel]

Hi everybody!

I want to write an extension for the VisualEditor (great work by the way) and I 
need a little help. I've browsed through various documentation [1-4](and more) 
and already learned that using RL module 
'ext.visualEditor.desktopArticleTarget.init'  and 'mw.lib.ve.addPlugin' method 
is the way to go. Unfortunately my attempts to hook into the user interface by 
binding on events provided by the components (like 'save' from 
've.ui.MWSaveDialog' or 've.init.mw.Target') have not been successful yet. 
Maybe you could give me a little push into the right direction.

Are there any HowTos or Tutorials for VisualEditor that cover topics like

1.   Adding buttons to the toolbar

2.   Accessing the data model (e.g. retrieve all set categories from the 
Parsoid DOM)

3.   Extending/replacing a single tool (e.g. the GalleryInspector)

4.   Binding on components events (e.g. the 'save' event, to analyze 
content and maybe abort saving)

Points 1 and 2 get more or less explained by the docs I've found. But 3 and 4 
are very unclear to me. Some hints would be appreciated!

[1] 
https://www.mediawiki.org/wiki/VisualEditor_gadgets#Gadget_-_Registering_VE_plugin
[2] https://en.wikipedia.org/wiki/User:%D7%A2%D7%A8%D7%9F/veReplace.js
[3] https://doc.wikimedia.org/VisualEditor/master
[4] https://www.mediawiki.org/wiki/OOjs_UI/Toolbars

Greetings,
Robert Vogel
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tutorials / HowTos for VisualEditor

[Robert Vogel]

Hi!

James, Florian, thank you for your responses! This will be very useful for me.

I didn't have the time to look through all of Florian's links, so maybe it's 
somewhere in there, but, James, can you give me a hint how to register a tool 
with visual editor?
What is the recommended time/callback to call the 've.ui.toolFactory.register' 
method? mw.loader.using()?

Regarding the 'save' event question: I want to check if a category is set and 
if it is not, show a message window to the user _before_ he/she can save. I've 
already implemented a serverside check and the API returns an error if no 
category is set. But this API error message cannot be styled/customized and it 
gets displayed _after_ the user clicked "save".
But of course I will open a Phabricator task if that is the better place for 
such a discussion.

Thanks again,
Robert Vogel

-Ursprüngliche Nachricht-
Von: wikitech-l-boun...@lists.wikimedia.org 
[mailto:wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von James Forrester
Gesendet: Mittwoch, 26. August 2015 21:53
An: Wikimedia developers 
Betreff: Re: [Wikitech-l] Tutorials / HowTos for VisualEditor

On 25 August 2015 at 23:30, Robert Vogel  wrote:

> Hi everybody!
>
> I want to write an extension for the VisualEditor (great work by the 
> way) and I need a little help.


First off, the easiest way to get help is to ask in IRC ( 
#mediawiki-visualeditor ) or 
file a Phabricator task asking for something specific ( 
https://phabricator.wikimedia.org/maniphest/task/create/?projects=VisualEditor
).

One thing to remember is that though VisualEditor is *complex*, it's nowhere 
near *complete* – there's a lot of functionality still to build (essentially, 
anything we've not had a need to build yet), so the answer to "what method can 
I use to do X?" is often "there isn't one, but we can build it".

That said…


> I've browsed through various documentation [1-4](and more) and already 
> learned that using RL module 'ext.visualEditor.desktopArticleTarget.init'
> and 'mw.lib.ve.addPlugin' method is the way to go. Unfortunately my 
> attempts to hook into the user interface by binding on events provided 
> by the components (like 'save' from 've.ui.MWSaveDialog' or
> 've.init.mw.Target') have not been successful yet. Maybe you could 
> give me a little push into the right direction.
>

As a general rule, don't try to bind to VisualEditor's internal events.
They're intended for internal consumption and aren't an API, and change without 
notice.
​​

​


> Are there any HowTos or Tutorials for VisualEditor that cover topics 
> like
>
> 1.   Adding buttons to the toolbar
>

​We don't have an API for this yet, partially because the current system is 
terrible and building an API just to make a breaking change to it feels unkind. 
There are a number of ways you can grab onto the private.



> 2.   Accessing the data model (e.g. retrieve all set categories from
> the Parsoid DOM)
>

Are you trying to replace the category nodes with a new one with extra 
features? If so, you'd want t​o sub-class the core one, or register a node with 
more specificity in the registry than other things (and/or de-register the 
existing one). Neither of those are very stable, though. If something else, 
file a ticket and we can discuss options.


3.   Extending/replacing a single tool (e.g. the GalleryInspector)
>

​Probably you want to sub-class the existing tool and register that with the 
same name to over-write.


4.   Binding on components events (e.g. the 'save' event, to analyze
> content and maybe abort saving)
>

​Save abort hooks are done in MediaWiki. We haven't built (and don't intend to 
ever build)​ a hooks system into VisualEditor. If you file a ticket explaining 
what you're looking to do I'd be happy to give more advice.

​Yours,
--
James D. Forrester
Lead Product Manager, Editing
Wikimedia Foundation, Inc.

jforres...@wikimedia.org | @jdforrester
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tutorials / HowTos for VisualEditor

[Robert Vogel]

Thank you all for your responses!

I've opened up a task on Phabricator [1] to discuss about a "pre-save" system 
or public hooks in general.

[1] https://phabricator.wikimedia.org/T110644

--
Robert Vogel

-Ursprüngliche Nachricht-
Von: wikitech-l-boun...@lists.wikimedia.org 
[mailto:wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von James Forrester
Gesendet: Donnerstag, 27. August 2015 16:58
An: florian.schmidt.wel...@t-online.de; Wikimedia developers 

Betreff: Re: [Wikitech-l] Tutorials / HowTos for VisualEditor

On 27 August 2015 at 06:54, florian.schmidt.wel...@t-online.de < 
florian.schmidt.wel...@t-online.de> wrote:

> A VE save could be recognized with the postEdit hook[1] in JavaScript:
>
> mw.hook( 'postEdit' ).add(
> // your function
> );
>
> Remember, that this hook is also fired after a "normal" save (via the 
> Wikitext editor)[2].
>
> [1]
> https://github.com/wikimedia/mediawiki-extensions-VisualEditor/blob/44
> ad7574639be7e096d43784eb3942388e779eff/modules/ve-mw/init/targets/ve.i
> nit.mw.DesktopArticleTarget.js#L713-L717
> [2]
> https://github.com/wikimedia/mediawiki/blob/b79196778ed7c4f49ae09bee9b
> a16f861a6e3760/resources/src/mediawiki.action/mediawiki.action.view.po
> stEdit.js#L66-L75


​Yeah, but that's even later​ than the server-side mid-save PHP hook. :-)



> -Original-Nachricht-
> Betreff: Re: [Wikitech-l] Tutorials / HowTos for VisualEditor
> Datum: Thu, 27 Aug 2015 15:30:27 +0200
> Von: Daren Welsh 
> An: Wikimedia developers 
>
> I'm also interested in this kind of information. Right now I'm 
> specifically interested in what I can use as an equivalent to a hook 
> for when a user saves a page revision using VE. I'm working on an 
> extension that logs user actions (and does more with that 
> information). I have figured out how to play off of hooks to determine 
> a page view or a "traditional" page save, but I'm lost when it comes to VE.
>

​Probably simplest just do it server-side hooked onto the page save, with a 
special rule if the revision is tagged 'visualeditor'​?

​Yours,
--
James D. Forrester
Lead Product Manager, Editing
Wikimedia Foundation, Inc.

jforres...@wikimedia.org | @jdforrester
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] ResourceLoader: Control caching

[Robert Vogel]

Hi everyone!

I've got a little question about how to control caching of a RL module. But 
first, my case:

I've several (four) modules defined that depend on each other. Most of them are 
defined as a FileModule using $wgResourceModules with 'styles', 'scripts', 
'messages', .
One of them is implemented as a class that derives from ResourceLoaderModule 
(not ResourceLoaderFileModule). I've grouped (using the 'group' entry in 
$wgResourceModules) them so they all  get loaded together in one request (and 
separately from other modules).
This module group delivers pretty static content, but much of it (approx. 2MB). 
So it would be ideal to cache it on the client side.

Unfornuately the load.php call always incudes a 'version' parameter with the 
current timestamp and the 'expires' header of the response is set to "now".  So 
no client caching. I believe it has something to do with my custom 
ResourceLoaderModule subclass. I've already tried to override methods like 
"getModifiedHash" or "getModifiedTime" but without success.

What can I do to get rid of the 'version' parameter in the load.php call and 
the 'expires' header? 

--

Robert Vogel

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] How to make a good MediaWiki distribution?

[Robert Vogel]

Hello everybody.

I've opened up a task on phabricator (T130812) about the question of how to 
make a good MediaWiki distribution. And I'd like to ask anyone interested in 
this topic for thoughts, suggestions and advice. Your help is highly 
appreciated. Details can be found on the task page [1].

[1] https://phabricator.wikimedia.org/T130812

--
Robert Vogel
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] img_auth.php and extensions

[Robert Vogel]

Hello everybody,

some time ago I've overtaken maintainership of extension "NSFileRepo", which 
allows to secure access to uploaded files based on namespace permissions 
set/managed by extension "Lockdown". It worked well with LTS release 1.23, but 
unfortunately due to some changes in "img_auth.php" [1] [2] it does not work in 
current LTS release 1.27. I've tried to rewrite the extension to fit into the 
new system [3], but it seems to be a hacky approach. There is already a 
Pabricator task (T140334 [4]) in which I've asked for support (and also got 
some good responses), but I want to draw some attention by writing to this 
mailing list. Any help, hints, comments are much appreciated.

[1] https://gerrit.wikimedia.org/r/#/c/127589/
[2] https://gerrit.wikimedia.org/r/#/c/127701/
[3] https://gerrit.wikimedia.org/r/#/c/308573/
[4] https://phabricator.wikimedia.org/T140334

best regards,

Robert Vogel
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Development on img_auth.php

[Robert Vogel]

Hello!

Recently I've worked on some MediaWiki setups with enabled "img_auth.php". 
During that work I've noticed a few things that I think can be improved, to 
make an extension developer's life easier.
I know that this feature is mostly used by private/intranet wikis, so there are 
only limited resources for future development available at the WMF. Therefore 
I'd like to volunteer to work on "img_auth.php".
Is this something the Wikimedia dev community is interested in? Can I count on 
some support by the original maintainers of "img_auth.php"? I'd be happy about 
any feedback.

Oh, and I've already created a Phabricator task:  
https://phabricator.wikimedia.org/T153174

--
Robert Vogel
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Creating a broken link

[Robert Vogel]

Hi Victor,

you may use the return value of

    MediaWikiServices::getInstance()->getLinkRenderer()->makeLink(
Title::newFromText( 'Some title that does not exist' ) );

If you are within a ContextSource you may also call the shortcut
"$this->getLinkRenderer()"

--
Robert

On Mi, 2017-01-25 at 15:23 +0200, Victor Porton wrote:
> How to create a broken ("edit", "red") link to a page?
> 
> That is I want to generate a HTML code which displays a link,
> clicking
> which leads to the editor (for a page). The link should be red.
> 
> What is the right way to do this?
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] OOJS-UI: label/data mechanism in "OO.ui.ComboBoxInputWidget"

[Robert Vogel]

Hi everybody!

I'm working on some OOJS-UI components for an extension and I've stumbled 
across something:

The "OO.ui.ComboBoxInputWidget" allows to set an array of 
"OO.ui.MenuOptionWidget" objects in its "menu.items" config field.
Such an item can have a "label" and a "data" field. The "data" field can be of 
type "object" [1].

Now, if I use a "data" field of type "object" the value of the  
"OO.ui.ComboBoxInputWidget" will be "[Object object]", as it tries to cast the 
"data" value to a string when a user selects an option item.
So it looks like "OO.ui.ComboBoxInputWidget" allows only "data" of type 
"string" in its options. Is that correct?

That would also mean that there is no "label/data" mechanism of the input field 
itself. If I've got the following options

[
{ label: "Rot", data: "red" },
{ label: "Gelb", data: "yellow" },
{ label: "Grün", data: "green" }
]

and the user selects the option with label "Gelb" the input field shows 
"yellow", not "Gelb". Did I miss something? Is it possible to show a "label" to 
the user but retrieve the "data" (object) when calling "getValue" on such a 
field?

[1] 
https://doc.wikimedia.org/oojs-ui/master/js/#!/api/OO.ui.MenuOptionWidget-cfg-data

--
Robert
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] OOJS-UI: label/data mechanism in "OO.ui.ComboBoxInputWidget"

[Robert Vogel]

Hi Moriel,

thanks for your explanations. They're very helpful. The
ComboBoxInputWidget example you provided shows my use case very nicely.
When you open up the drop down menu you see the options "Option One",
"Option Two", "Option Three", ...
When you select one of them the (e.g. "Option Three") displayed value
in the field will be the actual value (e.g. "Option 3") and not the
label that you've selected. This can be quite strange when you've got
values that sound "technical". Consider some dynamic option mechanism
where users create options by "labels" and some kind of software
automatically creates the "values".

An example: You've got a option value "Q7186" and a label value "Marie
Curie". When the user selects "Marie Curie" the user interface will
say: "Q7186". A user might be confused.

I know that some UI frameworks handle this by showing the "label" of
the selected item to the user in a DIV element or something else and
storing the actual value in an internal variable. When it comes to form
submission and the need to provide an actual "value string" they use a
hidden field and maybe a "valueField" config option in case the "value"
is not a string but an object (thus allowing to set the string value of
the hidden field from a field within the value object).

It looks like OOJSUI does not support something like that (yet). It's
also not a big issue, I just was curiuos if I missed something relevant
and if I am the only one with such a use case.

So, thanks again :)

--
Robert

On Sa, 2017-02-25 at 14:23 -0800, Moriel Schottlender wrote:
> Hi Robert,
> > In general, the 'data' property for items inside the GroupElement can
> be
> strings or objects, as they represent some state of your item.
> In OO.ui.mixin.GroupElement, the method "getItemFromData" can then
> return a
> specific item based on its data property. If you use an Object for
> the
> data, OOjs-UI will use its OO.getHash() to basically stringify your
> object,
> so it can make sure it retrieves the right one.
> > The property 'data' actually comes all the way up the hierarchy chain
> from
> "OO.ui.Element" (if you look at that method, the description of that
> parameter is the same) -- and at that level, it definintely allows
> for any
> sort of data, be it a string or an object.
> > However, when dealing with specific cases, like that of the
> ComboBoxInputWidget (the terminology of "input widget" usually
> suggests
> something inside a form in OOjs-UI) means that putting the data as an
> object doesn't make sense usually. Unless your use case requires
> something
> very different, we usually want ComboBoxInputWidget to have the
> 'value' =>
> 'label' pair, so it uses its 'data' property as the 'value' and
> expects a
> string.
> > As for the second part of your question, I am not 100% sure I
> understood it
> (please correct me if so) but from what I understand, if you set your
> OO.ui.MenuOptionWidget items with their data as the value ('red' /
> 'yellow'
> / 'green' etc) and the label as the mw.msg that the user sees, then
> it
> should work out of the box.
> > So if you look at the example given in the docs for
> ComboBoxInputWidget (
> https://doc.wikimedia.org/oojs-ui/master/js/#!/api/OO.ui.ComboBoxInpu
> tWidget)
> you can set your item's data to the color (value) and the label to
> the word
> you want to display, and when the user picks an option, the **label**
> needs
> to show in the ComboBoxInputWidget.
> > Be aware, though, that if you listen to 'choose' or 'select' event
> from
> this input widget, you get the selected item, so if you're projecting
> that
> choice into some other input, you should ask for the label
> (item.getLabel()) and not the data.
> > I hope that helped...
> > Moriel
> > > > On Fri, Feb 24, 2017 at 12:04 AM, Robert Vogel 
> wrote:
> > > 
> > Hi everybody!
> > 
> > I'm working on some OOJS-UI components for an extension and I've
> > stumbled
> > across something:
> > 
> > The "OO.ui.ComboBoxInputWidget" allows to set an array of
> > "OO.ui.MenuOptionWidget" objects in its "menu.items" config field.
> > Such an item can have a "label" and a "data" field. The "data"
> > field can
> > be of type "object" [1].
> > 
> > Now, if I use a "data" field of type "object" the value of the
> &

Re: [Wikitech-l] OOJS-UI: label/data mechanism in "OO.ui.ComboBoxInputWidget"

[Robert Vogel]

Due to a request by a community member, this thread is now also
available on http://stackoverflow.com/questions/42502268/oojs-ui-label-
data-mechanism-in-oo-ui-comboboxinputwidget
--
Robert

On Fr, 2017-02-24 at 08:04 +, Robert Vogel wrote:
> Hi everybody!
> 
> I'm working on some OOJS-UI components for an extension and I've
> stumbled across something:
> 
> The "OO.ui.ComboBoxInputWidget" allows to set an array of
> "OO.ui.MenuOptionWidget" objects in its "menu.items" config field.
> Such an item can have a "label" and a "data" field. The "data" field
> can be of type "object" [1].
> 
> Now, if I use a "data" field of type "object" the value of
> the  "OO.ui.ComboBoxInputWidget" will be "[Object object]", as it
> tries to cast the "data" value to a string when a user selects an
> option item.
> So it looks like "OO.ui.ComboBoxInputWidget" allows only "data" of
> type "string" in its options. Is that correct?
> 
> That would also mean that there is no "label/data" mechanism of the
> input field itself. If I've got the following options
> 
> [
> { label: "Rot", data: "red" },
> { label: "Gelb", data: "yellow" },
> { label: "Grün", data: "green" }
> ]
> 
> and the user selects the option with label "Gelb" the input field
> shows "yellow", not "Gelb". Did I miss something? Is it possible to
> show a "label" to the user but retrieve the "data" (object) when
> calling "getValue" on such a field?
> 
> [1] https://doc.wikimedia.org/oojs-ui/master/js/#!/api/OO.ui.MenuOpti
> onWidget-cfg-data
> 
> --
> Robert
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] MediaWiki 1.28 is now LTS?

[Robert Vogel]

Hi!


according to [1] the MediaWiki 1.28.2 was a LTS release. On [2] I can not find 
a hint about this. Is that maybe a mistake?


[1] https://www.mediawiki.org/w/index.php?title=Download&oldid=2478392

[2] https://www.mediawiki.org/wiki/Version_lifecycle#Release_policy


--

Robert Vogel

(User:Osnard)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Extension:OATHAuth - breaking changes!

[Robert Vogel]

Hello everybody!

The extension "OATHAuth" has been refactored recently. As a dedicated
PHP namespace has been introduced for that extension, all full
qualified class names have changed.

It has been noticed that some external code relies on class names
(T228588 [1]) of that extension.

All classes are now in `MediaWiki\Extension\OATHAuth` namespace.

Most notably the former `TOTPAuthenticationRequest` is now called
`MediaWiki\Extension\OATHAuth\Auth\TOTPAuthenticationRequest`.

Also in `extension.json` 
`AuthManagerAutoConfig.secondaryauth.TOTPSecondaryAuthenticationProvider` has 
changed to
`AuthManagerAutoConfig.secondaryauth.OATHSecondaryAuthenticationProvider`.

If your code relies in any way on the internal structure of
`Extension:OATHAuth`, please check if it still works.

### The public Action API does not have breaking changes! ###

[1] https://phabricator.wikimedia.org/T228588

-- 
Robert Vogel
Teamlead Produkt- & Softwareentwicklung
 
Hallo Welt! GmbH
Postfach 11 02 09
93015 Regensburg
Germany
 
Telefon: +49 (0) 941 - 660 80-0
Fax: +49 (0) 941 - 660 80-189
 
hallowelt.com
vo...@hallowelt.com
 
Sitz: Regensburg
Amtsgericht: Regensburg
Handelsregister: HRB 10467
E.USt.Nr.: DE 253050833
Geschäftsführer: Anja Ebersbach, Markus Glaser, Dr. Richard Heigl
 
Besuchen Sie unsere aktuellen BlueSpice-Webinare:
https://de.bluespice.com/webinar
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] How to alter the Visual Editor configuration object for tool bar

[Robert Vogel]

Hi!

have you tried this?

https://www.mediawiki.org/wiki/VisualEditor/Gadgets/Add_a_tool

--
Robert

Von: Wikitech-l  im Auftrag von Egbe 
Eugene 
Gesendet: Montag, 13. Januar 2020 10:21
An: Wikimedia developers 
Betreff: [Wikitech-l] How to alter the Visual Editor configuration object for 
tool bar

Hi All,

How do I access the  configuration object for the main toolbar of
VisualEditor and add a new option to this to represent a new tool? below is
the image of the tool bar I am referring to.

 Thanks,
--
Eugene233
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] `Parser::getTitle` may return `null`, even though it is not allowed to

[Robert Vogel]

Hello!


In version 1.34 creating a `Parser` object without explicitly setting the 
`mTitle` value was
deprecated. But as it is just a deprecation yet, there are still cases where 
`mTitle` can be `null`
(it seems like this is even the case when calling the proper service with
`MediaWikiServices::getInstance()->getParser()`).

Unfortunately the `Parser::getTitle` method got changed, in a way that it 
_must_ return an instance
of `Title`. No `null` allowed. This leads to a `TypeError`.

I have found two Phabricator tasks, each with a proper patch for this:

- https://phabricator.wikimedia.org/T228881 / 
https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/533559/
- https://phabricator.wikimedia.org/T245129 / 
https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/571940/

It looks like a very small change. I'd very much appreciate if somebody could 
review and merge one
of these.

-- 
Robert Vogel
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Making breaking changes without deprecation?

[Robert Vogel]

Hi!


For the BlueSpice distribution ...


* we have got ~90 active repos hosted on WMF Gerrit and another ~10 in our 
internal Gitlab

* we want to develop as much as possible on the public infrastructure of the 
WMF, so the remaining internal repos will (hopefully) be published in the future

* we have hundreds of installations and a lot of them have a custom 
extension/skin maintained by us, that can not be published

* we mainly target MediaWiki core LTS branches with our code, therefore 
deprecations and breaking changes introduced by a non-LTS usually are no 
problem. But ...

* we try to keep up with the changes in the core `master` branch mainly for two 
reasons:

   1) CI tests of our codes `master` branch will fail whenever we cherry-pick a 
change from the LTS branch

   2) There is less work left for the time when a new LTS is about to be 
released (just happening with 1.35)


I believe the proposed process change will not affect us much. We will benefit 
more from a cleaner/modernized MediaWiki core codebase more than we will suffer 
from breaking changes. Especially as a lot of our code will be in the public 
available locations and therefore be visible for the WMF anyways. As long as we 
have a way to know about such breaking changes (mailin-list, mw.org pages, 
release notes, ...) - and how to handle them - we should be good.


--

Robert Vogel
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] VisualEditor inheriting from TransclusionNode in parser function extension?

[Robert Vogel]

Hi Luc!

>From my expierience inheritance of dialogs is rather hard to do and also 
>probably not meant to be done.
In the end it might be easier to actually implement a standalone dialog.

If you are interested in ways to modify existing dialogs and adding stuff to 
VisualEditor in general, you may want to have a look at the 
BlueSpiceVisualEditorConnector extension [1-5].

[1] 
https://github.com/wikimedia/mediawiki-extensions-BlueSpiceVisualEditorConnector/tree/3.1.12/resources
[2] 
https://github.com/wikimedia/mediawiki-extensions-BlueSpiceVisualEditorConnector/tree/3.1.12/resources/bs.vec/ui
[3] 
https://github.com/wikimedia/mediawiki-extensions-BlueSpiceVisualEditorConnector/blob/3.1.12/resources/bluespice.visualEditorConnector.overrides.js
[4] 
https://github.com/wikimedia/mediawiki-extensions-BlueSpiceVisualEditorConnector/blob/3.1.12/resources/bluespice.visualEditorConnector.styleInspector.js
[5] 
https://github.com/wikimedia/mediawiki-extensions-BlueSpiceVisualEditorConnector/blob/3.1.12/resources/bluespice.visualEditorConnector.tags.js


--
Robert

Von: Wikitech-l  im Auftrag von Lucien 
Anti-Spam via Wikitech-l 
Gesendet: Dienstag, 24. November 2020 16:21
An: wikitech-l@lists.wikimedia.org 
Cc: Lucien Anti-Spam 
Betreff: [Wikitech-l] VisualEditor inheriting from TransclusionNode in parser 
function extension?

Hi,

I am struggling to succeed with  inheriting from TransclusionNode in parser 
function extension?

Inheriting a dialog from "ve.ui.MWTransclusionDialog" contains the "Add 
Template" input and button,
what is the right level to inherit from if this is a supported flow?

As well as inheriting into the DM for MWTransclusion which works, but 
recognizes {{PAGEName}} that contains a  as a function parser node.

Any help would be greatly appreciated as the code is a little overwhelming.

Cheers,
Luc

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Installer override help

[Robert Vogel]

Hi Michael!

you will need to create a "/mw-config/overrides/" [1] directory where you can 
implement all kinds of stuff [2], like a "LocalSettingsGenerator" [3].

Here are some examples:
[1] https://github.com/hallowelt/mediawiki/tree/REL1_31/mw-config/overrides
[2] 
https://github.com/hallowelt/mediawiki/blob/REL1_31/mw-config/overrides/overrides.php
[3] 
https://github.com/hallowelt/mediawiki/blob/REL1_31/mw-config/overrides/includes/BsLocalSettingsGenerator.php

--
Robert

Von: Wikitech-l  im Auftrag von Michael 
Suddes 
Gesendet: Donnerstag, 14. Januar 2021 18:01
An: wikitech-l@lists.wikimedia.org 
Betreff: [Wikitech-l] Installer override help


Tl;dr

I’m looking for guidance on installer overrides and how to add to the web 
installer interface. Mainly to add SMW and other extensions to the end of 
LocalSettings.php automatically.


———-


Greetings. I manage a small semantic mediawiki. I have been told that other 
facilities similar to mine would find it useful. To facilitate this, I have 
created an Amazon machine image of the full installed wiki with SMW, Visual 
Editor, and such. Along with the SMW data structures and queries in place.


Originally, I was going to include instructions on changing the 
LocalSettings.php file manually, but ideally, I would like to modify the 
installer to include the needed config info for SMW and the other added 
extensions. Most of it will be straight appending of text to the end of 
LocalSettings.php, but the SecureHTML extension requires a bit of input that I 
would like to add to the web installer.


I noted the installer override README, and I know it should work for my needs, 
but I have a few questions:


•What installer step is ideal to trigger the override if I want to add text to 
the end of the file?


•Can I use an installer override to add a field to the web installer?


•I haven’t found much on Google about this, other than one project on GitHub, 
so any advice on a tutorial or notes would be greatly appreciated.


Thanks!

Michael
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Cascading HTMLForms

[Robert Vogel]

Hello everybody,



I am trying to write a SpecialPage with some kind of wizard functionality. On 
normal access a HTMLForm with a HTMLSelectField is presented. In the submit 
callback method of this HTMLForm object I create another HTMLForm with more 
HTMLFields. So far everything works fine. But when I submit this second 
HTMLForm the validation process breaks. Instead of running all validation- and 
filter-callbacks of the HTMLFormFields in the second HTMLForm the Framework 
renders the first HTMLForm with an error.



Does anybody know how to build a wizard with MediaWikis HTMLForm class? I'm a 
little stuck here. Help is very appreciated.



Best regards,

Robert Vogel
Social Web Technologien
Softwareentwicklung
Hallo Welt! - Medienwerkstatt GmbH

__

Untere Bachgasse 15
93047 Regensburg

Tel.  +49 (0) 941 - 66 0 80 - 198
Fax   +49 (0) 941 - 66 0 80 - 189

www.hallowelt.biz
vo...@hallowelt.biz


Sitz: Regensburg
Amtsgericht: Regensburg
Handelsregister: HRB 10467
E.USt.Nr.: DE 253050833
Geschäftsführer: Anja Ebersbach, Markus Glaser, Dr. Richard Heigl, Radovan 
Kubani

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] SQL: Stored Procedures and MediaWiki update.php

[Robert Vogel]

Hello everybody!

At my company we develop extensions for MediaWiki. We use the 
"LoadExtensionSchemaUpdates" hook to create tables with the 
"maintenance/update.php" script.
Recently we faced the question whether it is possible to have stored 
procedures/functions in an extensions SQL-File, or not. We tried it out and it 
didn't work for us. The update.php says we've got an error in the SQL syntax, 
but there isn't one.

Can anybody help us? Is it possible to provide stored procedures to the 
database using the update.php? Is there an example anywhere? Thx.

Greetings,

Robert Vogel
Social Web Technologien
Softwareentwicklung
Hallo Welt! - Medienwerkstatt GmbH

___

Untere Bachgasse 15
93047 Regensburg

Tel.  +49 (0) 941 - 56 95 94 98
Fax   +49 (0) 941 - 50 27 58 13

www.hallowelt.biz
vo...@hallowelt.biz


Sitz: Regensburg
Amtsgericht: Regensburg
Handelsregister: HRB 10467
E.USt.Nr.: DE 253050833
Geschäftsführer: Anja Ebersbach, Markus Glaser, Dr. Richard Heigl, Radovan 
Kubani


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] SQL: Stored Procedures and MediaWiki

[Robert Vogel]

Hi Roan,

thanks for the quick reply. This is (one of) the statement(s) we've got a 
problem with. 

--

DROP PROCEDURE IF EXISTS `insertfile_getFilePosition`;
DELIMITER $$
CREATE PROCEDURE `insertfile_getFilePosition`(filename VARCHAR(255))
BEGIN
SELECT tmp.rank FROM
(SELECT @row:=@row+1 rank, i.img_name
 FROM /*$wgDBprefix*/image i, (SELECT @row:=0) r
 WHERE (i.img_major_mime != 'image' AND i.img_minor_mime != 'tiff')
 ORDER BY i.img_name ASC) tmp
WHERE tmp.img_name = filename;
END
$$
DELIMITER ;

--

If provided to the SQL Database directly, it works. But the update.php throws a 
syntax error.
In general, is it possible to provide stored procedures this way?
Could there be a problem with the way the sql-file is read?

Greetings,

Robert Vogel
Social Web Technologien
Softwareentwicklung
Hallo Welt! - Medienwerkstatt GmbH


__

Untere Bachgasse 15
93047 Regensburg

Tel.  +49 (0) 941 - 56 95 94 98
Fax   +49 (0) 941 - 50 27 58 13

www.hallowelt.biz
vo...@hallowelt.biz


Sitz: Regensburg
Amtsgericht: Regensburg
Handelsregister: HRB 10467
E.USt.Nr.: DE 253050833
Geschäftsführer: Anja Ebersbach, Markus Glaser, Dr. Richard Heigl, Radovan 
Kubani

On Wed, 27 Jul 2011 at 22:16 PM, Roan Kattouw  wrote:
>On Wed, Jul 27, 2011 at 12:47 PM, Robert Vogel  wrote:
>> Hello everybody!
>>
>> At my company we develop extensions for MediaWiki. We use the 
>> "LoadExtensionSchemaUpdates" hook to create tables with the 
>> "maintenance/update.php" script.
>> Recently we faced the question whether it is possible to have stored 
>> procedures/functions in an extensions SQL-File, or not. We tried it out and 
>> it didn't work for us. The update.php says we've got an error in the SQL 
>> syntax, but there isn't one.
>>
>> Can anybody help us? Is it possible to provide stored procedures to the 
>> database using the update.php? Is there an example anywhere? Thx.
>>
>The SQL syntax error message comes from the database engine, not from 
>MediaWiki. So if it tells you there's an SQL syntax error, there's a syntax 
>error for sure. What you should look at:
>1. does the DB backend you connect to support the syntax you're using?
>Infamously, MySQL 4.0 will reject anything containing subqueries as a syntax 
>error, because subquery support wasn't introduced until 4.1 if memory serves 
>2. is MediaWiki connecting to the DB that you think it's connecting to? There 
>might be a version-triggered error like #1 above, but you might not notice if 
>you're connecting to a different version than MediaWiki is 3. are you using 
>magic phrases like /*_*/, /*$wgDBTablePrefix*/, /*i*/ or /*$wgDBTableOptions*/ 
>? MediaWiki substitutes these before sending the SQL to the DB backend, so 
>make sure you test your queries with these substitutions applied
>
>Roan Kattouw (Catrope)

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] SQL: Stored Procedures and MediaWiki

[Robert Vogel]

Hi Brion,

thanks for the hint. Is there a tutorial or documentation on how to use stored 
procedures in MediaWiki? Do you - or anybody else - know an extension that 
makes use of this feature? Something we can take a look at?

Greetings,

Robert Vogel
Hallo Welt! - Medienwerkstatt GmbH

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Re: Help +2 php 8.1 updates

[Robert Vogel via Wikitech-l]

Thanks Mark, that's just awesome!

I'd like to express my support for those changes and also kindly ask the core 
developers of MediaWiki to review those changes.

--
Robert

Von: Mark A. Hershberger via Wikitech-l 
Gesendet: Mittwoch, 6. Juli 2022 16:07
An: Wikitech 
Cc: Mark A. Hershberger 
Betreff: [Wikitech-l] Help +2 php 8.1 updates


MediaWiki devs,

I've been running the test suite using PHP 8.1 and providing patches in
Gerrit.  I've gotten some feedback but I am hoping that I can get the
requisite +2's to get these fixes incorporated into MediaWiki.

I have several patches outstanding with no comments.  If they could be
+2'd that would be awesome.

If they need more work before they're accepted, please let me know how
they are lacking so that I can update them.

Most of these can be found here:
https://gerrit.wikimedia.org/r/q/topic:change-809720

Thanks!

Mark.


--
http://hexmode.com/

I cannot remember the books I've read any more than the meals I have eaten;
even so, they have made me.
-- Ralph Waldo Emerson
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Re: How to specify version of MW that Jenkins should run?

[Robert Vogel via Wikitech-l]

The continous integration testing currently uses the same branch fot the 
"dependecies" as it tests. So if you create a change set on branch `master`, it 
will use `master` for all the other repos (like mw core, extensions, skins) it 
clones to build up the environment. I am not aware of any way to influence this 
on a per repo level.

The only way I am currently aware of is to commit against a branch called 
`REL1_35` of your extension and then cherry-pick the changes up to `master`, 
once the tests have passed. This will make the CI tests use the `REL1_35` 
branch of each dependency (including mw core).

--
Robert

Von: Sebastian Berlin 
Gesendet: Montag, 12. September 2022 12:20
An: Wikimedia developers 
Betreff: [Wikitech-l] How to specify version of MW that Jenkins should run?

I'm having some issues with Jenkins running the latest version of MW for an 
extension (Wikispeech). 
Jenkins run with the 1.40 alpha, but we want the extension to support the 
latest LTS (1.35 as of right now).

I tried changing in extension.json to:
"requires": {
 "MediaWiki": "1.35.*"
}
which caused an error for Jenkins:
12:44:09 A dependency error was encountered while installing the extension 
"Wikispeech": Wikispeech is not compatible with the current MediaWiki core 
(version 1.40.0-alpha), it requires: 1.35.*.
The whole log is here: https://phabricator.wikimedia.org/P34482.

How can I specify what version of MW to run with? I've looked at both the MW 
wiki and Wikitech, but hasn't found any instructions for this.

Best,

Sebastian Berlin
Utvecklare/Developer
Wikimedia Sverige (WMSE)

E-post/E-Mail: 
sebastian.ber...@wikimedia.se
Telefon/Phone: (+46) 0707 - 92 03 84
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Re: How to specify version of MW that Jenkins should run?

[Robert Vogel via Wikitech-l]

The "DonationInterface" has some "special handling" in the CI config: 
https://github.com/wikimedia/integration-config/blob/d2ef596ea8f697c0920270939c1bf967e0be/zuul/layout.yaml#L4464-L4480

They apparently use some dedicated Quibble test runner: 
https://github.com/wikimedia/integration-config/blob/d2ef596ea8f697c0920270939c1bf967e0be/jjb/wm-fundraising.yaml#L63-L76

I don't think this pattern can easily be re-used.

Von: Ostrzyciel 
Gesendet: Montag, 12. September 2022 16:42
An: wikitech-l@lists.wikimedia.org 
Betreff: [Wikitech-l] Re: How to specify version of MW that Jenkins should run?

Hi all,

I've been looking into a similar thing for a different extension, where I 
wanted it to be compatible with MW 1.37+ (see 
task<https://phabricator.wikimedia.org/T316479>). Basically, I want the tests 
to run both on REL1_37 and master to make sure that whatever I merge is 
compatible with 1.37. The cherry-picking approach is not a valid solution, as 
it's tedious, error-prone, and I can never be sure that the patch works with 
both branches.

I know of one extension that seemingly has something like this: 
DonationInterface. For example, this master 
patch<https://gerrit.wikimedia.org/r/c/mediawiki/extensions/DonationInterface/+/733965>
 had its tests run against REL1_35.

Can something like this be replicated in other extensions? I think it's a vital 
feature for extension developers, because compatibility with only master is 
next to useless. To be honest, it boggles my mind that this hasn't become 
common practice long ago.

--
The Slightly Mind-Boggled Ostrzyciel

On 12/09/2022 16:14, Robert Vogel via Wikitech-l wrote:
The continous integration testing currently uses the same branch fot the 
"dependecies" as it tests. So if you create a change set on branch `master`, it 
will use `master` for all the other repos (like mw core, extensions, skins) it 
clones to build up the environment. I am not aware of any way to influence this 
on a per repo level.

The only way I am currently aware of is to commit against a branch called 
`REL1_35` of your extension and then cherry-pick the changes up to `master`, 
once the tests have passed. This will make the CI tests use the `REL1_35` 
branch of each dependency (including mw core).

--
Robert

Von: Sebastian Berlin 
<mailto:sebastian.ber...@wikimedia.se>
Gesendet: Montag, 12. September 2022 12:20
An: Wikimedia developers 
<mailto:wikitech-l@lists.wikimedia.org>
Betreff: [Wikitech-l] How to specify version of MW that Jenkins should run?

I'm having some issues with Jenkins running the latest version of MW for an 
extension (Wikispeech<https://www.mediawiki.org/wiki/Extension:Wikispeech>). 
Jenkins run with the 1.40 alpha, but we want the extension to support the 
latest LTS (1.35 as of right now).

I tried changing in extension.json to:
"requires": {
 "MediaWiki": "1.35.*"
}
which caused an error for Jenkins:
12:44:09 A dependency error was encountered while installing the extension 
"Wikispeech": Wikispeech is not compatible with the current MediaWiki core 
(version 1.40.0-alpha), it requires: 1.35.*.
The whole log is here: https://phabricator.wikimedia.org/P34482.

How can I specify what version of MW to run with? I've looked at both the MW 
wiki and Wikitech, but hasn't found any instructions for this.

Best,

Sebastian Berlin
Utvecklare/Developer
Wikimedia Sverige (WMSE)

E-post/E-Mail: 
sebastian.ber...@wikimedia.se<mailto:sebastian.ber...@wikimedia.se>
Telefon/Phone: (+46) 0707 - 92 03 84



___
Wikitech-l mailing list -- 
wikitech-l@lists.wikimedia.org<mailto:wikitech-l@lists.wikimedia.org>
To unsubscribe send an email to 
wikitech-l-le...@lists.wikimedia.org<mailto:wikitech-l-le...@lists.wikimedia.org>
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Re: How to specify version of MW that Jenkins should run?

[Robert Vogel via Wikitech-l]

@Hashar: Just wondering, are there any plans to change CI configs after moving 
development/code-review from gerrit to gitlab [1]? Maybe some file living in 
the repo directly rather than using a centralized repo like 
`integration/config`?

[1] https://www.mediawiki.org/wiki/GitLab/Gerrit_to_GitLab

--
Robert

Von: Antoine Musso 
Gesendet: Dienstag, 13. September 2022 15:42
An: Wikitech-l ; Sebastian Berlin 

Betreff: [Wikitech-l] Re: How to specify version of MW that Jenkins should run?

Le 12/09/2022 à 12:20, Sebastian Berlin a écrit :
I'm having some issues with Jenkins running the latest version of MW for an 
extension (Wikispeech). 
Jenkins run with the 1.40 alpha, but we want the extension to support the 
latest LTS (1.35 as of right now).

I tried changing in extension.json to:
"requires": {
 "MediaWiki": "1.35.*"
}
which caused an error for Jenkins:
12:44:09 A dependency error was encountered while installing the extension 
"Wikispeech": Wikispeech is not compatible with the current MediaWiki core 
(version 1.40.0-alpha), it requires: 1.35.*.
The whole log is here: https://phabricator.wikimedia.org/P34482.

How can I specify what version of MW to run with? I've looked at both the MW 
wiki and Wikitech, but hasn't found any instructions for this.

Hello,

There are a lot of good answers and hints in this thread. I will complement the 
answers since I am the one that has introduced the CI system currently used for 
MediaWiki and I used to be in the Wikimedia Foundation team which was 
responsible for MediaWiki development (Platform Engineering, disbanded in 2015).

MediaWiki is primarily developed for the Wikimedia project and the focus on CI 
is to ensure that the master branch of MediaWiki core, extensions, skins and 
their composer dependencies are working well together.  The CI jobs prefixed 
"wmf-quibble" clone a few dozen of extensions and are triggered whenever one 
send a patch to one of those extensions or mediawiki/core. Hence we have more 
or less a guarantee that the master branches of the participating repositories 
are all working together.

For the deployment to the Wikimedia cluster, we cut a new deployment branch 
(wmf/XXX) directly from the master branch. Since a change could only have been 
merged in the master branch if all the CI jobs passed, we are pretty sure that 
the set of repositories with their wmf branches are passing tests. There are 
some caveats still but that is the rough idea.

The MediaWiki releases are generated from the REL* branches and CI follows the 
same logic. If one send a patch to their extensions REL1_35 branch, CI checkout 
the REL1_35 branch of mediawiki/core and any other repositories participating 
in the job.

Thus if you send a patch to WikiSpeech REL1_35 you would get mediawiki/core and 
Vector at REL1_35 as well ensuring everything works well together (and by 
everything, I mean what ever is covered by tests). But if you send a patch for 
the master branch, it is the master branch of all repositories being checked 
out. In all case the value(s) of the requires field in extension.json does not 
affect the branch used in CI. It is entirely based on the convention that all 
repos are using the same branch.

There are lot of use cases for developers ensuring the master branch is 
compatible with the current development version (master) AND keeping back 
compatibility all the way up to the latest LTS. But that is not enforced by CI. 
I know Translate does it, most probably through manual testing.


What we could potentially do is create a job which would inspect the extension 
requires field to get the target branch to test (so if one requires 1.35, 
target the REL1_35 branch) then invoke the testrunner with that branch override 
(--branch REL1_35). Then if you send a patch to WikiSpeech master branch, such 
a job would test its code against mediawiki/core / vector using REL1_35. I am 
not entirely sure how to implement it, but the best place would probably be 
https://gerrit.wikimedia.org/g/integration/quibble/  It is the code holding all 
the logic to clone/checkout repositories, setup MediaWiki and run the test 
suite.  I am guessing when a change is targeting an extension or skin, Quibble 
would clone it first, inspect the extension.json and then internally set the 
default branch (the `--branch` parameter). And we can have a Jenkins job using 
that feature and running along the rest of the jobs.

It will most probably be fine for extensions that do not have many other 
dependencies.

The relevant task would be https://phabricator.wikimedia.org/T196467 . I think 
the devil is defining the workflow that is needed, which is more or less the 
text above.


Antoine "hashar" Musso




___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://l

[Wikitech-l] Re: help mediawiki extension

[Robert Vogel via Wikitech-l]

Hi!

Change

use UrlUtils;

to

use MediaWiki\Utils\UrlUtils;

-
Robert

Von: Tim Moody 
Gesendet: Donnerstag, 12. Januar 2023 16:27
An: Wikitech-l 
Betreff: [Wikitech-l] Re: help mediawiki extension

I'm still a brick shy of a load:

in extension.json I have

"HookHandlers": {
"main": {
"class": "MediaWiki\\Extension\\OurWorldInData\\Hooks",
"services": [
"MainConfig",
"UrlUtils"
]
}
},

in Hooks.php I have

use Config;
use Html;
use UrlUtils;
use MediaWiki\Hook\ParserFirstCallInitHook;
use MWException;
use Parser;
use PPFrame;

class Hooks implements ParserFirstCallInitHook {
/** @var Config Main config */
private Config $config;
private UrlUtils $urlUtils;

/**
 * @param Config $config Main config
 */
public function __construct( Config $config, UrlUtils $urlUtils ) {
$this->config = $config;
$this->urlUtils = $urlUtils;
}


I get

TypeError: MediaWiki\Extension\OurWorldInData\Hooks::__construct(): Argument #2 
($urlUtils) must be of type UrlUtils, MediaWiki\Utils\UrlUtils given


On Wed, Jan 11, 2023 at 10:14 PM D 
mailto:dylss...@gmail.com>> wrote:
$urlUtils->parse() is not a static method.

Non-dependency injection way:

use MediaWiki\MediaWikiServices;

$urlUtils = MediaWikiServices::getInstance()->getUrlUtils()

$urlUtils->parse()

Otherwise inject the UrlUtils service. For example, if using HookHandlers[1], 
add the service to your extension registration extension.json:
{
"HookHandlers": {
"main": {
"class": "MediaWiki\\Extension\\Example\\Hooks",
"services": [ "UrlUtils" ]
}
},
"Hooks": {
"ParserFirstCallInit": "main"
}
}

Then the service will be injected into your __construct(UrlUtils $urlUtils) 
method as an argument.

[1] 
https://www.mediawiki.org/wiki/Manual:Hooks#Handling_hooks_in_MediaWiki_1.35_and_later

On Wed, Jan 11, 2023 at 6:36 PM Tim Moody 
mailto:t...@timmoody.com>> wrote:
On MW 1.39.0 and .1 and PHP 8.1.2-1ubuntu2.9,

I am trying to revise a parserhook extension to mediawiki that uses 
wfParseUrl(). 
https://doc.wikimedia.org/mediawiki-core/master/php/GlobalFunctions_8php.html#a178b2b51ef87926e5daa08f66fbae9b0
 says that is deprecated and I should use UrlUtils::parse().

The former looks like a function and the latter looks like a class, perhaps a 
subclass of Utils. My first question is what if any use statement do I need. 
The extension already has use Html, but use UrlUtils gives an error because it 
can't be found.

Do I need to instantiate Utils or UrlUtils and invoke the urlparser as 
$urlUtils -> parse()? When I invoke UrlUtils::parse I get a complaint about 
calling a non-static method statically.

The old code was
$url_parts = wfParseUrl( $graph_url );
and the new
$url_parts = UrlUtils::parse( $graph_url );

Any help would be appreciated.

Tim
___
Wikitech-l mailing list -- 
wikitech-l@lists.wikimedia.org
To unsubscribe send an email to 
wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
___
Wikitech-l mailing list -- 
wikitech-l@lists.wikimedia.org
To unsubscribe send an email to 
wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] VisualEditor inserting ``

[Robert Vogel via Wikitech-l]

Hi everyone!
Inspired by 
https://www.mediawiki.org/wiki/VisualEditor/Gadgets#Implementing_a_custom_command
 I was trying to add a `` into the VE using this command:

```
ve.init.target.getSurface().getModel().getFragment().insertContent( [ { type: 
'break' }, { type: '/break' } ] );
```

While it actually inserted the line break in visual edit mode, there was not 
`` in the wikitext after saving the page or switching to wikitext mode 
within the edit session.
I also tried to implement the whole "command/tool" in an extension, but the 
behavior was the same. The odd thing is that a `` inserted  in wikitext 
mode survives the round trip. The linear data model shows it as "alienInline" 
node then.

Any ideas why the official example didn't work for me?

Greetings,
Robert
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Inserting single line breaks in VisualEditor (from mediwiki-l)

[Robert Vogel via Wikitech-l]

HINT: This is a crossposting from mediawiki-l

Hello everyone!

With this message I am reaching out to the developers/maintainers of 
Extension:VisualEditor. I have already tried the mw.org support desk [1] and 
IRC without much success.

1. I was wondering if there were any technical reasons for 
Extension:VisualEditor not inserting a `` element on `SHIFT+ENTER`. This 
seems to be standard functionality in most other visual HTML editors, plus `` is supported by wikitext.
2. If there was no technical reason, I'd ask for support to implement a Gadget 
that allows for this behavior. I have already tried a couple of things, but it 
looks like the `SHIFT+ENTER` event can not be handeled easily. Apparently some 
core code handles the event and always creates a new paragraph. I did not 
succeed to stop propagation and override this behavior from my handler.

Maybe I am just missing something here. Any help would be much appreciated.

[1] https://www.mediawiki.org/wiki/Topic:Xhywmkd6b0mnwjk7

Greetings,
Robert Vogel


___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/