Wikitech-l August 2014

wikitech-l@lists.wikimedia.org

133 participants
137 discussions

Re: [Wikitech-l] [WikimediaMobile] need for an app? (was: Future platforms, devices, and consumers)
by svetlana 18 Aug '14

18 Aug '14

Dmitry Brant wrote: > The fact that you don't see the benefits of the native app over the mobile > website is simply an indication that we still have a lot of work to do with > the apps, which we are excited to do. Partly this is because you don't support my mobile platform. Dmitry Brant wrote: > But, is it a waste of effort to bring a truly integrated, seamless > Wikipedia experience to our users' mobile devices? I don't think so. Nor > is it a waste of effort for the WMF to be seen as a driving force in mobile > design and mobile user experience. I was assuming that integration and being seamless are easily doable from a web browser. Offline storage is hard in a browser, as you pointed out; that's too much detail for me to understand quickly, and I have no comment yet. In principle, such concern is valid. Documenting extra differences and shortcomings of web browsers could be a nice task. svetlana

2 1

Preparser: Comments after === became a part of a header in xml representation
by Nikolay Shaplov 18 Aug '14

18 Aug '14

When I do preparsing of the following text Some text === It gives me a level 1 header with = as a title (what is expected), but it also put a comment inside of <h></h> tags: <root>Some text <h level="1" i="1">===<comment></comment></h> </root> This is not a problem for web rendering since comments are simply removed, but if one will try to create some ObjModel from the result xml, it would be not exactly the result that person would expect. And there might be some other unexpected results. i.e. some code would expect to find = before </h> tag, and would be surprised when it does not find it there. Etc. This quite a minor problem, but I think it worth reporting.

2 1

Bugzilla Weekly Report
by reporter＠zirconium.wikimedia.org 18 Aug '14

18 Aug '14

1 0

Thoughts on sandboxed JS gadgets/tools/scripts
by Brion Vibber 18 Aug '14

18 Aug '14

There's been some recent controversy over access to & control over site JS which I'd prefer not to wade into... but it does remind me of some ideas I've been mulling over related to sandboxed JavaScript execution. Power users need to have an easy way to write, deploy, and use tools that integrate into the wikis: * custom editing tools * custom menu items * custom widgets for the sidebar * that can be enabled widely with a minimum of security worries (We can make separate tools on Tool Labs already but that provides no UI integration beyond putting links in sidebars or wiki pages.) JavaScript code can be isolated from the primary execution context by running scripts in an <iframe> based on a distinct domain, with a well-defined "safe" communication channel between it and the parent window over the window.postMessage interface. I've experimented with this previously in Extension:EmbedScript <https://www.mediawiki.org/wiki/Extension:EmbedScript>to try "interactive media"-like things such as graphs with dynamic components or graphical quizzes/games. But I think this could be generalized to utility scripts that hook up to a well-defined portion of the UI or a particular data pipeline. For instance, a custom citation editor tool might add a toolbar button in the editor (via defined API), then accept input data and be given a chance to display its own UI on activation in a floating iframe, just as if it were a 'native' lightbox-style dialog; on completion it would send the modified text back into the editor through the defined postMessage API, and the editor would save it into the page. Such a tool would be unable to, say, edit other pages on your behalf unexpectedly, and it would be unable to have side effects on the rest of the UI, but it could be safely selectable on-wiki through an interface like selecting Gadgets... And that limited integration means much better security and stability controls than gadgets and user scripts can provide today -- a broken or malicious sandboxed widget would only be able to do things you explicitly permit it to. This sort of clean/limited in-wiki script API might allow for a lot of the stuff that site scripts and auto-enabled Gadgets are used for today, without the related QA, security, and control/side-effect issues. If folks think this is an interesting idea I'll pick it back up in my research time as I get some of the video stuff I've been working on finished up. (Note I'm still in the UK for another week and a half, so I'll be reading/replying on lists intermittently until I get back to SF.) Thoughts on specific classes of tools that might be easy or hard to do with this technique are welcome. -- brion

2 1

Recommended viewing: talk on Cognitive Science and Design
by Derk-Jan Hartman 17 Aug '14

17 Aug '14

I just love this Google I/O 2013 talk on human perception and cognition, and its implications for interactive and visual design. It is accessible, but with a lot of information and applies very well to us I think. I'm sure that many designers know all about this and some have probably seen the clip before, but it is also very good for developers, because many of these things we know subconsciously, but it's not really part of our vocabulary. https://www.youtube.com/watch?v=z2exxj4COhU DJ

3 2

DB deadlock on Mediawiki 1.23.2 with VisualEditor and Parsoid
by Bjoern Kahl 17 Aug '14

17 Aug '14

Dear All, I need some help tracking down a DB deadlock on a single-server, "private" Wiki installation running latest MediaWiki download from http://www.mediawiki.org/wiki/Download I have been referred to this mailing list from #mediawiki at irc.freenode.org, thanks for the pointer! Installed versions: ------------------- - MediaWiki: 1.23.2 - VisualEditor from Git, branch REL1_23, ID 9883566 - Parsoid from Git, branch REL1_23, ID 8da3673 - parsoid service from Git, branch master, ID df35443 - mysql: 5.5.35, Debian wheezy package - apache: 2.2.22, Debian wheezy package - PHP: 5.4.4, Debian wheezy package - OS: Linux 3.2.0-4-686-pae #1 SMP Debian 3.2.57-3 i686 GNU/Linux MediaWiki, Parsoid (nodejs) service and mysql database are all on the same server. Setup followed the instructions on https://www.mediawiki.org/wiki/Parsoid/Setup Problem description: -------------------- Logging in, reading and editing using the standard (not visual) edit works fine. Clicking "Edit", which starts the visual editor, results in no reaction at all for approx 5 seconds, then the page goes dim and a progress indicator appears at the top right corner. After another approx. 100 seconds, the page returns to normal state as if opened or reading. Directly accessing the Parsoid service, here running on port 8000, promptly delivers the page. Preliminary investigation: -------------------------- Enabling debugging in LocalSettings.php and tweaking wfDebugTimer() to get absolute millisecond timestamps and client address/port info in the log file showed the following sequences of activities (anonymized log files available if needed): Summarized: - client request page by calling "GET /wiki/api.php?format=json&action=visualeditor&paction=parse..." - MediaWiki starts processing and class the Parsoid service with "GET /testwiki/TestPage?oldid=4053 HTTP/1.0" - Parsoid service calls "GET /wiki/api.php?format=json&action=query&prop=revisions&..." - call from Parsoid server into MediaWiki API deadlocks with client call into API. The question is why is it deadlocking and how to prevent the deadlock. Detailed activities analysis: - (1) client accesses "GET /wiki/api.php?format=json&action=visualeditor&paction=parse..." - (2) MediaWiki starts some session bookkeeping, including opening a DB transaction with "BEGIN" and performing several queries in the transaction. - (3) MediaWiki/1.23.2 calls the parsoid service with "GET /testwiki/TestPage?oldid=4053 HTTP/1.0" - (4) Parsoid/0.1 calls "GET /wiki/api.php?format=json&action=query&prop=revisions&..." - (5) MediaWiki starts processing (in a new apache/PHP slave) and opens a new DB transaction with "BEGIN" performing the same initial "UPDATE `wiki_user` SET user_touched ..." query as first query in the transaction as in step (2). - (6) approx. 40 seconds pass - (7) Parsoid service drops connection from (4) to MediaWiki (TCP FIN packet observed by tcpdump while capturing the on-wire conversation between MediaWiki and the client / the Parsiod service) - (8) Parsoid/0.1 calls again "GET /wiki/api.php?format=json&action=query&prop=revisions&..." from a new connection (client port number changed) - (9) MediaWiki starts processing (in a new apache/PHP slave) and opens a new DB transaction with "BEGIN" performing the same initial "UPDATE `wiki_user` SET user_touched ..." query as first query in the transaction as in step (2) and (5). - (10) approx. 10 seconds pass - (11) MediaWiki receives a "SQL ERROR: Lock wait timeout exceeded; try restarting transaction" relating to transaction from step (5) - (12) MediaWiki attempts a ROLLBACK of (5) and tries to send a "HTTP 500" (content captured by tcpdump) but the connection is already dead. - (13) approx. 30 seconds pass - (14) Parsoid service drops connection from (8) to MediaWiki (TCP FIN packet observed by tcpdump while capturing the on-wire conversation between MediaWiki and the client / the Parsiod service) - (15) Parsoid/0.1 calls again "GET /wiki/api.php?format=json&action=query&prop=revisions&..." from a new connection (client port number changed) - (16) MediaWiki starts processing (in a new apache/PHP slave) and opens a new DB transaction with "BEGIN" performing the same initial "UPDATE `wiki_user` SET user_touched ..." query as first query in the transaction as in step (2), (5) and (9). - (17) approx. 10 seconds pass - (18) MediaWiki receives a "SQL ERROR: Lock wait timeout exceeded; try restarting transaction" relating to transaction from step (9) - (19) MediaWiki attempts a ROLLBACK of (9) and tries to send a "HTTP 500" (content captured by tcpdump) but the connection is already dead. - (20) approx. 10 seconds pass - (21) MediaWiki closes the connection to the Parsoid service from step (3), without any data exchange after receiving the initial "GET /testwiki/TestPage?oldid=4053 HTTP/1.0" - (22) MediaWiki performs a DB "COMMIT" in the original client session from step (2), after 104 seconds. - (23) MediaWiki continues processing the session from step (16), at least in part executing the same set of queries as in step (2). - (24) MediaWiki performs a DB "COMMIT" in the Parsoid client session from step (15), after 20 seconds. - (25) MediaWiki sends a "HTTP 200" with a JSON body to the Parsoid service as answer to request from step (15). - (26) Parsoid service logs messages "starting parsing", a parse tree and "completed parsing in 101234 ms". (Note: It is unclear when in the range (21) to (26) these messages are logged, but I think this position "(26)" is most logical.) At earlier times, Parsoid logs the two messages "Failed API request, 8 retries remaining." and "Failed API request, 7 retries remaining." and not precisely known time steps, probably between (7)/(8) and (14)/(15), respectively. Question: --------- What could cause this behavior and how should I configure my system to prevent the deadlocks? If this is a Bug in either MediWiki or the VisualEditor or Parsoid, how to further investigate and fix it? Best regards Björn -- | Bjoern Kahl +++ Siegburg +++ Germany | | "googlelogin@-my-domain-" +++ www.bjoern-kahl.de | | Languages: German, English, Ancient Latin (a bit :-)) |

4 10

need for an app? (was: Future platforms, devices, and consumers)
by svetlana 17 Aug '14

17 Aug '14

(Duplicating this mail, as I wasn't subscribed to mobile-l a minute ago.) On Sat, 16 Aug 2014, at 12:45, Nkansah Rexford wrote: > [...] > The Wikipedia app is currently under good development and I think its doing > great. We don't need apps. We need mobile websites which work as good as an app does. Oh, the waste of effort. I truly pledge you to work together to make a website which is so good that an 'app' is redundant. svetlana

4 8

Re: [Wikitech-l] need for an app? (was: Future platforms, devices, and consumers)
by Nkansah Rexford 16 Aug '14

16 Aug '14

I agree with you too on that. apps are redundant, unless one has the resources to support. 'Nativity' is great and can unleash some potentials, which are hard to accomplish via browsers. I personally find the mobile site for Wikipedia great enough and I use it for editing instead of the native app. rexford | google.com/+Nkansahrexford | sent from smartphone On Aug 16, 2014 9:28 AM, "svetlana" <svetlana(a)fastmail.com.au> wrote: On Sat, 16 Aug 2014, at 12:45, Nkansah Rexford wrote: > [...] > The Wikipedia app is currently under good development and I think its doing > great. We don't need apps. We need mobile websites which work as good as an app does. Oh, the waste of effort. I truly pledge you to work together to make a website which is so good that an 'app' is redundant. svetlana _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

2 1

Roadmap and deployment highlights - week of August 18th
by Greg Grossmeier 15 Aug '14

15 Aug '14

Hello and welcome to the latest edition of the WMF Engineering Roadmap and Deployment update. The full log of planned deployments next week can be found at: <https://wikitech.wikimedia.org/wiki/Deployments#Week_of_Aug_18th> A quick list of notable items... == Tuesday == * MediaWiki deploy ** group1 to 1.24wmf17: All non-Wikipedia sites (Wiktionary, Wikisource, Wikinews, Wikibooks, Wikiquote, Wikiversity, and a few other sites) ** <https://www.mediawiki.org/wiki/MediaWiki_1.24/wmf17> * Wikidata ** Badges support will be rolled out, see: *** <https://lists.wikimedia.org/pipermail/wikidata-l/2014-August/004331.html> ** Wikinews will get sitelinks via Wikidata (aka "Wikidata phase 1") == Wednesday == * Weekly fundraising banner test == Thursday == * MediaWiki deploy ** group2 to 1.24wmf17 (all Wikipedias) ** group0 to 1.24wmf18 (test/test2/testwikidata/mediawiki) Thanks and as always, questions and comments welcome, Greg -- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |

1 0

PHPUnit tests in MediaWiki
by Jon Robson 15 Aug '14

15 Aug '14

Suddenly I cannot run PHPUnit tests on vagrant > cd /vagrant/mediawiki/tests/phpunit && /usr/bin/php5 phpunit.php --configuration /vagrant/mediawiki/extensions/Echo/tests/echo.suite.xml --group=Echo No MWMultiVersion instance initialized! MWScript.php wrapper not used? The documentation doesn't seem up to date... https://www.mediawiki.org/wiki/Manual:PHP_unit_testing/Running_the_unit_tes…

2 1

← Newer
1
...
5
6
7
8
9
10
11
...
14
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l August 2014