[Wikitech-l] Latest Snowden docs MediaWiki
The latest Snowden docs have some great screenshots of the NSA-internal MediaWiki installation Snowden is alleged to have obtained a lot of his material from: https://firstlook.org/theintercept/article/2014/02/18/snowden-docs-reveal-covert-surveillance-and-pressure-tactics-aimed-at-wikileaks-and-its-supporters/ Looks like a static HTML dump, as a few of the external extension images haven't loaded. The last details on their technical infrastructure indicated that Snowden used web crawler (love the quotes) software to obtain information from their internal wiki: http://www.nytimes.com/2014/02/09/us/snowden-used-low-cost-tool-to-best-nsa.html?hp What's not mentioned in the NYT piece is that their MediaWiki instance likely didn't have any read-only ACLs set up, or if they did they were buggy (are any of the third-party ACL extensions good?) -- which was perhaps one reason why Snowden was able to access the entire site once he had any access at all? If you actually need fancy read restrictions to keep some of your own people from reading each others' writing, MediaWiki is not the right software for you. -brion. ..like, if you're a nation-state's intelligence agency, or something :P I think it's fascinating that this technical decision[1] by the MediaWiki team long ago may have had such an impact on the world! And much more fascinating that the NSA folks may not have read the docs. -Philip 1. http://www.mediawiki.org/wiki/Manual:Preventing_access#Restrict_viewing_of_certain_specific_pages ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] LocalWiki released
{%%} syntax looks really wiki-like. That's a kind of reverse logic,
comparing to MediaWiki, where parser functions are converted to HTML
output, not opposite. What's really important, parser functions can be
nested (and by using proper parser frame parser tags probably can be
nested as well - I haven't tried that yet but might try soon). Can
LocalWiki template tags be nested as well?
The template tags can be nested, yeah. Chaining in templates is
usually achived using template filters, though, a'la
https://docs.djangoproject.com/en/dev/ref/templates/builtins/?from=olddocs#safeseq.
Our goal with the template representation stuff was to leverage as
much of the existing Django ecosystem as possible. For instance, we
were able to use a common thumbnailing template tag library without
modification. But in general, if you want dynamic bits in pieces
inside of a serializable/cachable mostly-HTML document, a Django
template kinda makes sense.
We'll likely kill off the explicit {% .. %} syntax and build the
template tree manually in order to simplify the process of writing
page plugins.
--Philip
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] LocalWiki released
Page-content plugins will need editor plugins, yeah (like our include
page plugin). But I think that's a good thing.
How do these plugin work when there is no XML injection into page
content? How the final layout is being build?
We take the HTML5 that's stored and, before rendering it, transform
certain bits into functions. Right now we go HTML5 - Django
template, and turn certain specially-registered HTML bits into Django
template tags (functions). We can then cache the Django template.
We're going to make registering a new page plugin easier (no HTML
traversal) soon.
Here's the docstring describing how we've got inside-page plugins working:
Conversion of HTML into template with dynamic parts.
We want to allow some dynamic content that gets inserted as the HTML is
rendered. This is done by converting certain HTML tags into template tags.
There are two mechanisms to do this: plugin handlers and tag handlers.
Plugins are meant for inserting bits of dynamic content at specific places on
the final rendered page marked by a placeholder element. The output can be
whatever you like: widgets, bits of JavaScript, anything. Tag handlers, on the
other hand, are meant for fixing up the HTML slightly and transparently, i.e.,
fixing links and adding helpful visual styles and the like. When in doubt, use
plugins.
Plugin handlers work with HTML elements that have the class plugin. When
an element has the class plugin, it will be passed to registered handlers
based on the other classes it has.
For example, the following element will be passed to the handler registered for
the includepage class:
a href=Navigation class=plugin includepageInclude Navigation/a
which will convert it to this:
{% include_page Navigation %}
to be rendered by the include_page template tag.
Tag handlers work similarly, but they are applied by element tag instead of by
class. They are best used for routine processing of content, such as styling.
For example, to mark links to non-existant pages with a different style, this:
a href=My PageMy Page/a
gets converted to this:
{% link My Page %}My Page{% endlink %}
and rendered as appropriate by the LinkNode class.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] LocalWiki released
On Wed, Dec 14, 2011 at 9:41 PM, Dmitriy Sintsov ques...@rambler.ru wrote: * Philip Neustrom phi...@localwiki.org [Wed, 14 Dec 2011 12:40:55 -0800]: Realized I never sent an announcement here. I think you folks'd be really interested in checking out what we've been working on: http://localwiki.org We just did our first general-public software release. There's lots of cool stuff going on. Having worked on the DavisWiki (http://daviswiki.org) code for many, many years [which was a fork of MoinMoin], we really relished the opportunity to design a new, modern wiki engine without the burden of legacy support. Cool bits: * Everything is stored as HTML5. We threw out wiki markup. I am not so sure that threwing out wiki markup is so good thing. It's more compact (takes less storage space) and allows to format text quite fast to everyone who is familiar to wiki markup. If you are using HTML5, that means the extensions (parser functions) has to be implemented as XML tags, which are quite tiresome to input directly, so the extensions will probably require visual editor addons. Raw text editing simplifies implementation of markup extensions, some developers might do not have enough free time to develop their own visual editor extensions. That's why raw wikitext can be useful and time-saving. Keep in mind that with our generic versioning framework we can version and diff any structured data, independent of wiki page content. So there's probably no need to stuff extension invocation inside of page content. Page-content plugins will need editor plugins, yeah (like our include page plugin). But I think that's a good thing. The concerns you raise are probably valid for Wikipedia. We're working with new communities, for the most part. (and our work isn't based on MediaWiki - not sure if I made that clear in my original message). --Philip Dmitriy ___ 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] Visual editor collaboration
On Wed, Dec 14, 2011 at 6:48 PM, Neil Kandalgaonkar ne...@wikimedia.org wrote: On 12/14/11 4:03 PM, Brion Vibber wrote: On Wed, Dec 14, 2011 at 3:00 PM, Philip Neustromphi...@localwiki.orgwrote: Update: We hacked around and got the edit surface working inside LocalWiki: http://farm8.staticflickr.com/7146/6512865959_6140e1deac_b.jpg Awesome! It's not just awesome! It's epic! I don't see a commit to your github, can you share it? I'm using git locally myself, maybe I can pull from you somehow. Mike threw it up here: https://github.com/localwiki/localwiki/tree/editsurface/sapling/editsurface (full branch browsable here: https://github.com/localwiki/localwiki/tree/editsurface/) --Philip I wanted to start promoting this to other wiki-engines, glad to see it's happening already. MediaWiki is a superset of pretty much every wiki syntax you would want, so we'll be churning on that for a while. but we can probably deploy on formats like Markdown or plain old HTML much faster. Over the holidays I will be working a bit on round-tripping to different formats, and to MediaWiki itself of course, now that Gabriel has cleared the way there. -- Neil Kandalgaonkar (| ne...@wikimedia.org ___ 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] Visual editor collaboration
Folks- Big congrats on the first general-public visual editor demo. We've been hoping for a while that someone would work on a non-designMode/contentEditable editor. This looks -great-! We're interested in using the editor in LocalWiki. We're currently using a highly-modified CKeditor, which will probably keep working well for a year or so, but beyond that it's not very future-proof. We've done a lot of work to make our editing experience consistent and fun, but it's a real pain to hack on new editor-specific functionality because CKeditor is so fickle. We'd love nothing more than to throw it in a trashbin and set it afire. But such is technology. The first question I have is: how much trouble will we encounter if we're not using wiki markup? We store everything as HTML5 everywhere, and we're converting our old sites to HTML5 on import. We should hang out and have a little show-and-tell! Maybe early Jan? Best, Philip LocalWiki http://localwiki.org (Apologies if you're seeing this email twice. My first send was seemingly silently rejected) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] LocalWiki released
Realized I never sent an announcement here. I think you folks'd be really interested in checking out what we've been working on: http://localwiki.org We just did our first general-public software release. There's lots of cool stuff going on. Having worked on the DavisWiki (http://daviswiki.org) code for many, many years [which was a fork of MoinMoin], we really relished the opportunity to design a new, modern wiki engine without the burden of legacy support. Cool bits: * Everything is stored as HTML5. We threw out wiki markup. * Visual editing! And it's consistent and fun! * .. Using a highly-hacked ckeditor. We're hoping to work on the new visualeditor ya'll have been working on. Exciting! * The basis of our work was creating a flexible versioning, diffing and merging framework for Django, called django-versionutils. With this, we can easily version any Django model, diff any Django fields, and create new, custom diff handlers (for, say, GeometryFields or ImageFields :) This allows us to wiki-fy any sort of structured data, too. * this lets us make things like versioned, diffable comments a'la liquidthreads really easily. * Really cool map stuff / really-easy map editing :) I made this code walkthrough screencast a few months back which you might find interesting: http://vimeo.com/25385510 (though it's a bit long -- sorry!) we've got a dev site here: https://dev.localwiki.org Anyway, would love to work together on anything and everything we can! (WMF folks: we're in SF, too) -Philip (Apologies if you're seeing this email twice. My first send was apparently silently rejected) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Visual editor collaboration
Update: We hacked around and got the edit surface working inside LocalWiki: http://farm8.staticflickr.com/7146/6512865959_6140e1deac_b.jpg Works with saving re-editing, too. --philip ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
