Hi there,
I'm the primary developer of the VIKI
<https://www.mediawiki.org/wiki/Extension:VIKI> extension and its two
companion extensions, VikiSemanticTitle
<https://www.mediawiki.org/wiki/Extension:VikiSemanticTitle> and
VikiTitleIcon <https://www.mediawiki.org/wiki/Extension:VikiTitleIcon>.
I thought I'd take a look at converting these three extensions to the new
extension registration
<https://www.mediawiki.org/wiki/Manual:Extension_registration> format, but
I ran into a problem. According to the documentation, the new extension
registration does not support PHP constants
<https://www.mediawiki.org/wiki/Manual:Extension_registration/Limitations>.
I use a PHP constant to declare an explicit dependency on VIKI for
VikiSemanticTitle and VikiTitleIcon. In my VIKI.php file, I declare:
*define( 'VIKIJS_VERSION', '1.3');*
And then in VikiSemanticTitle and VikiTitleIcon, I have a check that looks
something like:
*if( !defined( 'VIKIJS_VERSION' ) ) {*
* die('Error: The extension VikiSemanticTitle requires VIKI to be
installed first.');*
*}*
(As an aside, I also happen to use VIKIJS_VERSION as my version number,
which I increment as I release new versions. But that's not as important.)
Because the new extension registration format doesn't support PHP
constants, this no longer works, and I can't run VikiSemanticTitle and
VikiTitleIcon alongside VIKI - the VIKIJS_VERSION constant is seemingly no
longer defined, so any page load dies with the error message above.
If I can't use PHP constants anymore, does anyone have a better
recommendation for declaring explicit dependencies? Or should I just avoid
migrating the VIKI extensions to the new registration format?
Thanks,
--
Jason Ji
jason.y.ji(a)gmail.com
Hello web devs! There was a pretty neat article trending on Hacker News
recently that gave some pointers on Chrome Devtools. Check it out!
https://news.ycombinator.com/item?id=10416062
Stephen
Occasionally its useful to pass trusted data to javascript using data
attributes on elements that you know is not from the user. In the
past, there has been security issues from using the data attribute for
information that is assumed to be trusted, but in reality could be
messed with by the user. (T58699, T105413)
We already reserve data-ooui (by reserve, I mean blacklist in the
sanitizer). But it feels wrong to use that for parts of mw that are
not ooui. I would like to propose that we reserve data-mw- prefix as
well for general usage by mediawiki/extensions (By which I mean that
any attribute starting with data-mw-, would be blocked by the
sanitizer. Thus if a user writes on a wikipage <span
data-mw-foo="bar"></span>, the data-mw-foo attribute would be
stripped). Thus if javascript sees such an attribute, it can know for
sure that the value is not direct untrusted user-input.
Anyone have any objections to doing this?
Bikeshed now about the choice of name for the prefix, or forever hold
your peace ;)
--
-bawolff
Hey all,
OOjs UI 0.13.0 was released last week. It will be in MW from 1.27.0-wmf.5+,
which will be deployed to production in the regular train starting
tomorrow. As there are a couple of nominal breaking changes and a
deprecation, please look carefully over them to determine if they affect
your code.
*Breaking changes since last release:*
- [BREAKING CHANGE] Remove aliases for OO.ui.mixins (C. Scott Ananian)
We deprecated the old names of the mixins system in v0.11.4 in June,
when we adopted the new naming system. We believe we have remedied all
known users of the deprecated code (VisualEditor, Echo, Flow,
MobileFrontend, Graph and Citoid all have had changes made to compensate).
- [BREAKING CHANGE] Turn Element#gatherPreInfuseState into a static
method (Bartosz Dziewoński)
This is a nominal breaking change; there are no known users of this
feature, which we are improving for performance, cleanliness and usability;
expect more soon.
*Deprecating change since last release:*
- [DEPRECATING CHANGE] SelectFileWidget: Rename dragDropUI option to
showDropTarget (Ed Sanders)
We renamed the option `dragDropUI`, a boolean which controlled whether
the SelectFileWidget would display a drag-and-drop target UI element,
has been renamed to `showDropTarget`. The old option name still works
for now, but will be removed in v0.15.0.
- [DEPRECATING CHANGE] TextInputWidget: Add getValidity function,
deprecate isValid (Prateek Saxena)
Despite the naming of this function, it returned a Promise, not a
boolean. The new getValidity function works better and is named sanely.
The isValid() function still works for now, but will be removed in v0.15.0.
Additional details are in the full change log
<https://phabricator.wikimedia.org/diffusion/GOJU/browse/master/History.md;v…>
. This is the first breaking change since v0.12.0 was released in July;
since then there have been 252 code changes to the library by 22
developers; my thanks to all of them. If you have any further questions or
need help dealing with deprecations, please let me know. As always, general
library documentation is available at <http://goog_969668313/>mediawiki.org
<https://www.mediawiki.org/wiki/OOjs_UI> and generated code-level documentation
and interactive demos at doc.mediawiki.org
<https://doc.wikimedia.org/oojs-ui/master/#!/api>.
Yours,
--
James D. Forrester
Lead Product Manager, Editing
Wikimedia Foundation, Inc.
jforrester(a)wikimedia.org | @jdforrester
Hi Everyone --
A bit late but I wanted to let you know that the Engineering goals for the
2d quarter (October to December) of this current Fiscal year are posted on
Mediawiki.org.
https://www.mediawiki.org/wiki/Wikimedia_Engineering/2015-16_Q2_Goals
We'll be more timely in the future. Please reach out to the respective goal
owner identified in the wiki page for more information.
-Toby
Hi, I'd like to present a new RFC for your consideration:
https://www.mediawiki.org/wiki/Requests_for_comment/Minifier
It is about how we can shave 10-15% off the size if JavaScript
delivered to users.
Your comments are highly welcome!:)
--
Best regards,
Max Semenik ([[User:MaxSem]])
Hi Community Metrics team,
this is your automatic monthly Phabricator statistics mail.
Number of accounts created in (2015-10): 348
Number of active users (any activity) in (2015-10): 885
Number of task authors in (2015-10): 507
Number of users who have closed tasks in (2015-10): 243
Number of projects which had at least one task moved from one column
to another on their workboard in (2015-10): 182
Number of tasks created in (2015-10): 3009
Number of tasks closed in (2015-10): 2286
Number of open and stalled tasks in total: 26627
Median age in days of open tasks by priority:
Unbreak now: 17
Needs Triage: 128
High: 171
Normal: 322
Low: 681
Lowest: 536
(How long tasks have been open, not how long they have had that priority)
TODO: Numbers which refer to closed tasks might not be correct, as described in T1003.
Yours sincerely,
Fab Rick Aytor
(via community_metrics.sh on iridium at Sun Nov 1 00:00:07 UTC 2015)