Hello,
This is just a friendly reminder that the page metadata end points
mentioned below will be completely removed on 2017-05-08. Please update
your clients if you are still using any of them.
Cheers,
Marko Obrovac, PhD
Senior Services Engineer
Wikimedia Foundation
On 23 February 2017 at 18:28, Petr Pchelko <ppchelko(a)wikimedia.org> wrote:
> Hello,
>
> Since the early days of REST API it provides two features that haven’t
> been widely used neither internally in the WMF nor by the community. Today
> in a clean-up pass over the API we have decided to deprecate and eventually
> remove those features to allow some long-needed refactorings and stability
> improvements of other, more important, endpoints.
>
> The first one is the ability to query metadata about the page via the
> `/page/title/{title}`~[1] endpoint. The metadata includes properties like
> the latest revision number of the page, user who have made the last edit,
> whether the page is a redirect and similar. The backend storage model used
> to power the feature is quite unique in the system and has a significant
> maintenance cost without providing a clear benefit to users.
>
> Another feature that’s never found it’s audience is the ability to get
> listings of revisions, titles and renders stored in RESTBase. These
> listings suffer from scaling issues and cannot work reliably with the data
> model we have.
>
> We have, hence, opted to remove these unused and complex endpoints until
> there is some actual need for this data in the REST API when we can design
> and implement them better. Here’s the list of endpoints that are now
> deprecated and will be removed on May, 1st 2017:
>
> • /page/title/
> • /page/title/{title}
> • /page/title/{title}/
> • /page/revision/
> • /page/revision/{revision}
>
> In case you are using them please switch to using the MediaWiki Action
> API. In case you need assistance or have questions, feel free to reply to
> this e-mail or contact the Wikimedia Services team~[2].
>
> Best regards,
> Petr Pchelko
> Software Engineer
> Wikimedia Foundation
>
> [1] https://en.wikipedia.org/api/rest_v1/#!/Page_content/get_
> page_title_title
> [2] https://www.mediawiki.org/wiki/Wikimedia_Services
>
>
> _______________________________________________
> Mediawiki-api-announce mailing list
> Mediawiki-api-announce(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
>
Mark your calendars! Friday, May 12th has been designated MediaWiki
Documentation Day. This is a day to put aside normal development work and
focus on improving MediaWiki documentation. This includes documentation for
users, wiki administrators, and developers.
Anyone with a good understanding of any particular area of MediaWiki
software (broadly construed to include gadgets, bots, libraries, API
frameworks, etc.) is encouraged to add or update on-wiki documentation,
in-code documentation, READMEs, etc. And even if you don't feel like you
know enough to improve the documentation, you can also participate by
flagging out-dated documentation or creating documentation requests on the
wiki page.
Coordination for Documentation Day is happening at:
* https://www.mediawiki.org/wiki/MediaWiki_Documentation_Day_2017
* https://phabricator.wikimedia.org/T126500
For more details, please refer to the wiki page above. This is a completely
ad hoc event, so feel free to adapt it, evolve it, expand it, hijack it,
promote it, or ignore it. Cheers!
I'm running into a weird problem, which made me reset my whole vagrant.
I assume this is not strictly a MediaWiki issue, but probably an HHVM
problem, but maybe someone can help me here.
So, if I start a fresh MediaWiki Vagrant installation, and the vagrant ssh
into the virtual machine, the fastest way to reproduce the issue is to
start hhvmsh and type
function f():int { return 1; };
=f()
I get:
Hit fatal : Value returned from function f() must be of type int, int given
#0 at [:1]
#1 f(), called at [:1]
#2 include(), called at [:1]
Any way to circumvent this (besides getting rid of the type hint,
obviously)? Update to a new HHVM version (According to Special:Version, the
HHMV version is 3.12.14 (srv)?
Hi all,
I seem to recall that a long, long time ago MediaWiki was using UTF-8
internally but storing the data in 'latin1' fields in MySQL.
I notice that there is now the option to use either 'utf8' or 'binary'
columns (via the $wgDBmysql5 setting), and the default appears to be
'binary'.[1]
I've come across an old project which followed MediaWiki's lead (literally -
it cites MediaWiki as the reason) and stores its UTF-8 data in latin1
tables. I need to upgrade it to a more modern data infrastructure, but I'm
hesitant to simply switch to 'utf8' without understanding the reasons for
this initial implementation decision.
Can anyone confirm that MediaWiki used to behave in this manner, and if so
why?
If it was due to MySQL bugs, does anyone know in what version these were
fixed?
Finally, is current best-practice to use 'binary' or 'utf-8' for this? Why
does MediaWiki make this configurable?
I have a very good understanding of character encodings and have no problems
with performing whatever migrations are necessary - and the code itself is
fully utf-8 compliant except for the database layer - but I'm just trying to
understand the design choices (or technical limitations) that resulted in
MediaWiki handling character encodings in this manner.
- Mark Clements (HappyDog)
[1] https://www.mediawiki.org/wiki/Manual:$wgDBmysql5
A stored XSS vulnerability was discovered when Kartographer is configured
to receive map data from wiki pages via JsonConfig. Unless your wiki has
both extensions installed and JsonConfig is configured to provide map data,
it is safe. Otherwise, you're encouraged to upgrade both extensions
IMMEDIATELY.
Affected versions:
* Versions for latest MediaWiki release, 1.28, don't support the
aforementioned functionality and therefore are not vulnerable.
* Versions for pre-release 1.29 and alpha 1.30 are affected and have fixes
applied in source control.
Upgrading:
You can download latest sources from Git[1] or ExtensionDistributor[2]
See this ticket for more information:
https://phabricator.wikimedia.org/T163166
----
[1]
https://www.mediawiki.org/wiki/Download_from_Git#Using_Git_to_download_Medi…
[2] https://www.mediawiki.org/wiki/Special:ExtensionDistributor
--
Best regards,
Max Semenik ([[User:MaxSem]])
Hi Community Metrics team,
This is your automatic monthly Phabricator statistics mail.
Accounts created in (2017-04): 345
Active users (any activity) in (2017-04): 879
Task authors in (2017-04): 476
Users who have closed tasks in (2017-04): 274
Projects which had at least one task moved from one column to another on
their workboard in (2017-04): 278
Tasks created in (2017-04): 2239
Tasks closed in (2017-04): 2391
Open and stalled tasks in total: 34180
Median age in days of open tasks by priority:
Unbreak now: 22
Needs Triage: 271
High: 462
Normal: 659
Low: 932
Lowest: 868
(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 https://phabricator.wikimedia.org/T1003 .
Yours sincerely,
Fab Rick Aytor
(via community_metrics.sh on iridium at Mon May 1 00:00:17 UTC 2017)