 Welcome to Wikipedia's extensions. This is part 2 of the 3 part series. In the first few minutes we'll cover what an extension is and how you can install one. After that, I'll walk through the list of extensions that are installed in Wikipedia. We'll get to see what an extension can do and how each of these extensions turns MediaWiki into what we know as Wikipedia. First off, what is an extension? An extension is additional code that you can download and install on your Wikipedia to either add or change some of its functionality. There are various different types of extensions, but rather than walk you through this list I'll actually show you some practical examples. You can find a list of extensions that are installed on your Wikipedia through the special version page. If you've just installed your fresh dev environment it'll most likely say that there are no extensions currently installed. If you compare this to the same page on the live Wikipedia site you'll find that there is a rather long list of extensions. And we'll go through some of those in just a moment. Let's start with an example, the wiki editor extension. This extension adds a toolbar on the edit page. On my local wiki when I read an article and I click edit the default for media wiki core is to show just a text box. Notice the absence of any editing tools. Now I should note here that the default behavior of media wiki core is not the same as the default that you get when you download media wiki as a released product. Media wiki is bundled by default with several recommended extensions including the wiki editor extension that I'm about to install. To install an extension there are generally just two steps. Number one is to download the extension and two is to enable it. Open the command line and move to the directory where you have cloned the media wiki core repository. Then open the sub directory for extensions. You then copy and paste one git clone command and paste it in there. This will download the full repository onto your local machine. Next open the media wiki folder in your preferred text editor and edit the local settings of PHP file. We'll then add this line to it and that's it. When you move back to our browser window now and refresh the extension is installed. We can verify this on the special version page once more where we should now see one extension listed and that is the wiki editor extension. Let's do one more. We'll install the visual editor. Again open the terminal to the extensions directory and copy and paste the git clone command. Next we'll enable it in our local settings file and that's it. We can now go back to our local wiki page and when we refresh we now have a second edit button. By default visual editor is promoted as the recommended editor and thus is what will open when we click on edit. We can now edit the page. With that in mind let's now walk through the extensions that are installed in wikipedia. We'll go to wikipedia and visit the special version page. There's a lot of things here. The first one we'll talk about is central off. Central off is the primary extension that we use for the authentication on wikipedia. It allows you to maintain a single account and login with it on any of over 900 wikis at the foundation hosts. You can use the special central off page to view information about your global account. Next let's talk about echo. Echo implements a notification system that we use in production. Its primary interface is exposed through the bell and inbox icons on the top of every page. For example if a fellow editor thanks you for one of your edits you'll receive a notification here. Next let's talk about OAuth. OAuth allows you to either login with your account or to perform actions with your account on other systems. For example you may have logged in to fabricator using your media wiki.org account. That is powered by OAuth. OAuth is also commonly used in the tool forge ecosystem. For example here I'm logging into the global search tool. It redirects me to meta wiki where I can then give it permission to login as me. The end result is that I'm now in a logged in experience with this tool without creating a separate username and password. Under the editor section we find several that we've already installed visual editor and wiki editor. Next let's look at the parser extensions. Parser extensions add additional functionality to the wiki text language. These can materialize in particular formatting of information as well as various multimedia features that are powered through parser extensions. To see which capabilities have been added you can reference the parser extensions tags section and you'll see a number of these listed here. If I compare these to my local wiki you'll see that there's far fewer of them. The ones that are listed here are the ones that are built into media wiki core. You can learn more about how these tags work on media wiki.org. The most well-known parser extension is probably the site extension. That's the references system that Wikipedia is known for. It exposes a ref tag that you can use to add a footnote to the end of the page. Like so. The tag also becomes active in the visual editor. In visual editor we can use site and then basic and we can write our reference. The easy timeline extension adds a timeline tag which allows you to create graphs. An example of this can be seen on the version lifecycle page on media wiki.org. Next is the input box extension. This extension adds a tag that allows you to generate various kinds of forms. This extension really demonstrates the way in which media wiki content isn't just meant to be static information but actually allows the community to develop its own workflows. For example you can create search forms as well as assisted ways of creating pages. An example of this can be seen on the incident status page on wikitech. And note how this content is generated purely through wikitech. Next let's look at the Scribuntube extension. Scribuntube provides more than a parser extension. It provides an entirely alternate way of developing templates by running Lua code on the server side. Lua is significantly more efficient at logic computations than for example wikitech's parser functions. As an example we can see the schema diagram Lua module. This is a page on media wiki.org in which a Lua program resides. This is real programming logic written and editable through a wiki page by anyone that has an executed server side in a limited sandbox manner to then render pieces of information or visualizations or other content. In this case it's the code I used to render the database diagram on media wiki.org. When Lua was first introduced as an alternate templating language for media wiki it had a significant performance impact. Before the introduction of Lua scripting through the Scribuntube extension logic was significantly more difficult to write for volunteers. It also took far more processing power. Before Lua, saving an edit to a biography article on wikipedia could take upwards of a minute to save during which the browser is just waiting for a server response just to see the result of your edit. After the most popular templates were converted to Lua the time to save edits was cut by more than half. Where in 2013 edits often took 30 seconds to process a year later that was down to six seconds. Through infrastructure improvements that have happened since then we've then cut it in half several more times. For example in 2014 when we introduced HHVM and later PHP7 editing time was cut in half yet again from six seconds to three seconds. In the work we've done in the year since and the hardware tuning that has taken place and additional PHP upgrades our save timing can now be found on performers that we can meet at org and these days it's actually downed by another order of magnitude. Our median save timing is now around 300 milliseconds or 0.3 seconds with our 75th percentile being well under a second. This is also in part due to moving of more work to the job queue. Under media handler I'll make mention of the time media handler extension and the 3D extension. The time media handler extension provides support for video and audio to MediaWiki. You can upload videos to comments and these are transcoded and they're playable inside articles. The 3D extension allows uploading of STL files which can be used for 3D modeling and 3D printing and these can be browsed interactively as well. The next few extensions are not as visible to individual readers and editors but they're no less important. Abuse filter is a highly configurable spam filter that automatically rejects edits that match certain patterns. Anti-spoof prevents the creation of certain accounts that are too similar to existing usernames and the title Blacklist extension enables administrators to disallow creation of certain pages or even user accounts. For example, this is used to prevent creation of accounts that look like they might be double math staff accounts. Lastly, I'll mention the gadgets extension. The gadgets extension allows the community to develop and deploy its own JavaScript and CSS code from within wiki pages. Unlike the Lua code which is executed server-side in a sandbox, this runs client-side in people's browsers. As such, it is restricted a lot more. Only so-called interface admins can create or modify gadgets. When installed, a gadget can be defined and its source code can be written in a wiki page. This gadget, as an example, adds a link to the sidebar and when clicked, shows a notification bubble. You can enable this gadget in the preferences and future page views for my account now execute this additional gadget on every single page view. And clicking it shows the notification bubble. Well, this is a trivial example. Let me show you two more gadgets to get a sense of the capabilities that are provided. On comments, there is a gadget called RTRC. What it does is it provides a real-time recent changes feed with a way to review, moderate, revert edits as they come in in real-time. And different users can collaborate on the same list of edits. So if I review this edit, it will disappear from the list for someone else. The second example of a gadget I'd like to show you is on Wikimedia Commons. There's actually two gadgets active on this page, even though I'm not logged in. They're both enabled by default on Wikimedia Commons. The first one is the language selector on the left side. This is functionality provided by a gadget and enabled by default on Wikimedia Commons. The second one are these buttons over here. These are provided by the stock photo gadget. This is also enabled by default. And it provides instructions for how to credit photos when using other websites. While these gadgets are enabled by default, you can still disable them through the same mechanism. They're enabled by default. Okay, and that was our walkthrough some of Wikimedia's extensions. See you in Part 3.