HomePhabricator
Minimal MediaWiki for frontend engineers
Local development with real world user generated content

I use OSX. Vagrant has not been kind to me, but I'm hopeful that Docker will make development a lot easier for me in future.
Until then, I use MAMP which provides a pretty easy LAMP setup. I wanted to share it with other frontend engineers as this minimal setup works well for me - it's fast, it minimises the extensions I need to update and most importantly brings me closer to problems with frontend end-users are experiencing.

MAMP replicating Wikimedia paths

In MAMP I have the web server set to apache and use a symlink to point the wiki folder to a git clone of mediawiki/core.

I setup the wiki via the web installer - which if you've never tried yourself, I urge you to give it a go! It's not that complicated really, and that's quite impressive!

I have the following defined in LocalSettings.php to match production wikis.

# this is is important as otherwise things like page previews will not work correctly when using the proxying tips I tell you below
# With this setup articles can be viewed on the path `/wiki/Main_Page`
$wgArticlePath = "/wiki/$1";

Extensions and proxying content

I am lucky to work with extensions that require minimum setup - most are simply git clone, configure and play e.g.

wfLoadExtension( 'Popups' );
wfLoadExtension( 'MobileFrontend' );
wfLoadSkin( 'MinervaNeue' );

I have no working instance of Wikidata or VisualEditor - these are black boxes to me. As a general rule I only install what I need. When I do need to test integrations with them, I seek configurations that can point to production.

For instance, the following config allows me to load production content into VisualEditor without setting up a REST base server:

wfLoadExtension( 'VisualEditor' );
// Enable by default for everybody
$wgDefaultUserOptions['visualeditor-enable'] = 1;
$wgVirtualRestConfig['modules']['parsoid'] = array(
    // URL to the Parsoid instance
    // Use port 8142 if you use the Debian package
    'url' => 'https://en.wikipedia.org',
    // Parsoid "domain", see below (optional)
    'domain' => 'en.wikipedia.org',
);
$wgVisualEditorFullRestbaseURL = 'https://en.wikipedia.org/api/rest_';

Note, that this will trigger CORs problems on your localhost, but that MediaWiki's API supports CORs for localhost for readonly requests provided you pass a query string parameter "origin=*".

The following code when placed in the right place (I usually throw this line into core or above the api request I want to proxy) gives me
content to feed from production into VisualEditor:

$.ajaxSetup({ data: {  origin: '*'  }  } );

Whenever my team needs to work with any kind of service of API, I've always found it much more useful to proxy content from production as otherwise I miss bugs and I find replication difficult. Using Special:Import is slow and broken. In particular, if you import pages linked to Wikidata, you also need to clone the Wikidata page for that article to be replicated locally.

User generated content is particularly important when working with content on mobile. We added support to MobileFrontend to proxy content and it can easily be enabled with the following config in LocalSettings.php:

$wgMFContentProviderClass = 'MobileFrontend\ContentProviders\MwApiContentProvider';
$wgMFMwApiContentProviderBaseUri = "https://en.wikipedia.org/w/api.php";

With these two changes, any pages I view in mobile will be proxied from production. This is currently available in the beta cluster - check out https://en.m.wikipedia.beta.wmflabs.org/wiki/Singapore for example. The pages 404 to avoid indexing, but will be live copies of the production equivalent.

Proxying content for desktop too!

In Popups (page previews feature), this is pretty easy to avoid installing Popups dependencies PageImages and TextExtracts I use 2 lines of config:

$wgPopupsGateway = "restbaseHTML";
$wgPopupsRestGatewayEndpoint = 'https://en.m.wikipedia.org/api/rest_v1/page/summary/';

This configures my localhost to make use of the production REST endpoint to source summaries. If I create a page "Popups test page" and create red links on a page "Dog" and create a page "Dog" with 2 lines of text, previewing the link Dog on "Popups test page" will show me the production preview for the Dog article. However, this doesn't fully work as I need links to those pages for page previews to work. Since page previews runs on desktop I can use the same proxying I use for mobile....

// Enable MobileFrontend's "content provider" for desktop too!
$wgMFAlwaysUseContentProvider = true;

Sometimes I need to make articles, so I provide an override to allow me to edit and view local pages that don't live on my production wiki:

// This will ensure that any local pages are served instead of production copies where available.
$wgMFContentProviderTryLocalContentFirst = true;

Proxying read-only APIs in mobile

Sometimes, I want to proxy JavaScript as well, which MobileFrontend also allows me to do. If I'm testing workflows with read-only (ie. no POSTs or authentication) I can proxy APIs. This is useful for testing pages like Special:Nearby without having to create lots of articles with coordinates near your current location.

// Redirect API requests to English Wikipedia
$wgMFContentProviderScriptPath = "https://en.wikipedia.org/w";

Cache!

I use memcached to cache. Without this your wiki might be a little on the slow side:

$wgMainCacheType = CACHE_MEMCACHED;
$wgMemCachedServers = array( '127.0.0.1:11211' );
$wgParserCacheType = CACHE_MEMCACHED; # optional
$wgMessageCacheType = CACHE_MEMCACHED; # optional

Conclusions

That's it.. that's my setup. All the extensions I work on tend to mirror production config as closely as they possibly can so shouldn't require any additional setup, so I urge you if you haven't... try setting up a minimal MediaWiki and see what's the minimal you can get away with to be productive.

Let me know in comments if you run into any problems or I've converted you into a more effective engineer :-).

Written by Jdlrobson on Feb 21 2019, 7:07 PM.
User
Projects
None
Subscribers
Zoranzoki21
Tokens
"Love" token, awarded by mmodell."Love" token, awarded by D3r1ck01.

Event Timeline

Thanks very much for this! When I install VisualEditor with your configuration and make edit and want to save page, why I get HTTP 404?

Hey @Zoranzoki21 if you are getting a 404 the URL is likely configured incorrectly. Can you open the developer console and share the URL that it's trying to fetch?

Hey @Zoranzoki21 if you are getting a 404 the URL is likely configured incorrectly. Can you open the developer console and share the URL that it's trying to fetch?

I will...

I now get error 404 when I want to open VE.. Configuration at LS.php

wfLoadExtension( 'WikiEditor' );
wfLoadExtension( 'VisualEditor' );
// Enable by default for everybody
$wgDefaultUserOptions['visualeditor-enable'] = 1;
$wgVirtualRestConfig['modules']['parsoid'] = array(
    // URL to the Parsoid instance
    // Use port 8142 if you use the Debian package
    'url' => 'https://en.wikipedia.org',
    // Parsoid "domain", see below (optional)
    'domain' => 'en.wikipedia.org',
);
$wgVisualEditorFullRestbaseURL = 'https://en.wikipedia.org/api/rest_v1';

# End of automatically generated settings.
# Add more configuration options below.