 Ike, it's much easier and much easier to spell. If you'd like me to spell out the first one, I can. Anybody need it? Okay, we'll go with IKE. That's much easier. Alright, so I am the lead project manager for WikiWorks. Let me show you. This mouse thing is not working. And there's my user page. You can pull it up. I got involved in MediaWiki around March 2006. We can skip the rest. I have written a lot of extensions. We're going on 30 now. So, and V for all actually, I wrote with your own yesterday at the collab camp. We're almost there. So, most of those you haven't heard of because the reason I write extensions is not because there are lots and lots of users who think they're going to be useful or that I think are useful. It's because people pay me to write them because they think they're useful. So, you probably haven't used too many of mine, but I've written a whole bunch of them. I was wondering with all those numbers, what's the number of extensions that one human being can possibly maintain at the same time? I think I'm way past that. But people pay me, I still write them. So, I took over as project manager for WikiWorks, which basically means that I'm running stuff since Yaron went to Genesis, so he's still involved. So, I'm doing less development and more stuff that nobody really wants to do. I set up a Wiki to kind of show you when we go in and there's a client who says, okay, make me a Wiki. So, how do we set it up? These are things I've learned over the years. It's going to be tips and tricks. You got the Wiki. It's all installed. Hopefully it works. And now what? So, it's, I think, important to set it up in a way that you can use it and maintain it and track it. Now, one pet peeve of mine, I don't like the way the media Wiki structure, the file structure works at all. I don't know if this has been discussed, but you've got, like, see, you got your W directory. Okay, that's, there's tip number one. Don't put media Wiki in the root. Put it in a directory. We'll talk more about that maybe later. You have your W directory. It's got all your Wiki files. Where's your setting files? So, you'll start looking. Okay, I got API. I got this one. I got that one. Eventually you'll hit L and that's your local settings.php. Why is it there? You want extensions. Oh, it's in the extensions directory. Images, they're in the images directory. How about you have one directory for media Wiki and everything in there is media Wiki and nothing in there changes, right? You've got a sibling directory for extensions, a sibling directory for images and you've got your local settings either in the root or in its own config directory with anything else. Do we have support for that? Yeah. Okay. I would note that those directory locations are configurable and you can actually just do that. Okay. Minus local settings.php at the very least, you have to have a small thing that could require a file from somewhere else. Otherwise, you can move image directory, extensions directory. You could do all that, right. And I'll show you some of that myself. But out of the box, if you look at other platforms, you'll see you've got the stuff that you don't change and the stuff that you do change and they're very separate and you don't have to move things around and set configs and stuff like that. All right. There's one little pet peeve of mine. So one of the first things I do when I set up a Wiki is I move local settings. So actually what I do is I create an extension. I go into the extensions folder and I create an extension like the one that you saw. This is the emwcon extension. So let's say emwcon was the name of a company and they came to me and said, make a Wiki. So that's what I do. I create an extension. I hit get init. We've got to get repository. This is going to hold all of the settings and everything for the Wiki. It's all in one extensions directory here and we'll go through it step by step. So the first thing we do is you've got your local settings. All right. This will look a little familiar. It's everything in the standard local settings that was generated by your installer. I take out passwords. All right. Some people say it's not a good idea to store it in a Git repo. All right. I put that somewhere else. Let me see if I can get it for you. If you want to see... I did my security talk but I also agree that storing passwords publicly is bad for security. Yeah? Yeah. Can you explain? Yeah. This is called Google. Okay. Hi. There you go. I guess I was not talking to it. Okay. So let me show you the... Let's see if I can move this over. Here is your directory structure. Here's your local settings for your benefit. Local settings with fake passwords. Not that I suspect that anybody here would actually try to hack into this server while I'm talking and change things around but actually that is exactly what I'm worried about. Here's the local settings with fake passwords. All right. This is what it would look like. All right. You're welcome to try and break in. They really are fake passwords. All right. This is an interesting little bit of code. It's a little bit outdated but it's basically if you want to debug your wiki very quickly you just uncomment that. You go into debug mode. All right. Then we've got the dvpass for the secret key, the upgrade key and it require basically it says look for the emwcon local settings. All right. And that's where all the settings of the wiki are. That makes things nice, easy, tidy and hopefully you never even have to look at this at all. All right. Any questions so far? Go back here. All right. So you've set up your wiki and it's basically blank. You'll see in this one, even though semantic media wiki was not included in local settings since it's installed by Composer, it's there and there's no way to turn it off short of uninstalling. All right. Cindy you're shaking your head. Yeah. I don't like it either. The fact that, okay, there's got to be a way to turn off vendor extensions, right? Okay. All right. So next step, go back to our repo. I actually discovered that even though it's very easy to take a get repo and go back, there's no easy way to go forward. All right. So I'd like to kind of show you the results of each one of these. It's just going to take me a little bit of time to set everything up here because I'm going to have to manually check out each one of these commits. All right. Second commit, we add a configuration blank shell. This actually doesn't do anything. Okay. But there's a few things here. So first, just keep things simple, separate them into sections. I like these sections. I have my core configuration in one spot, extension inclusion in another spot, and I like my extension configuration later. Some people like the inclusion with the configuration. I really don't like it. It makes everything very messy. So here you'll see the very interesting extension inclusion thingy where I don't want to have to worry about if this extension writer decided to make an extension.json or is still using the old way. So there's a slight performance hit, but I stick everything in one array and I do a little foreach. I go through each one. If there's a JSON file, use it. And if there's no JSON file, just use the old way. So it's a little nifty little piece of code. Install semantic media wiki, even though you already saw it installed, but this is the way it would look for installing semantic media wiki. Now, I added composer.local.json. So what is that? If you look at pretty much any extension on media wiki.org, it will tell you how to install an extension using composer. I don't want to pick on Elastica. It's just an example. You can find that on pretty much any extension on media wiki.org. In fact, the official extension install template will tell you to do this. If you want to install with composer, run composer install. What will that do? It's going to put everything into your standard composer.json, right? What happens when you upgrade? Your composer.json has been overwritten. So that's why the very wise people who made the media wiki core, they put in a merge plugin. So you can have a composer.local.json, which doesn't get overwritten and will automatically be included. So what I do is I take that composer.local and you probably guessed it. I do nothing other than use the merge plugin to merge another composer.local.json, which is in our Git repo. So again, everything is in one place. Nice and easy. So there it is. Instead of doing it from the command line, which is going to put it into your composer.json, you put it into your composer.local.json and you can track it and it won't get overwritten. All right. Have I lost anybody? Any questions? Anybody too afraid to speak up? But it seems it does not say install media wiki extension. It assumes that you have already updated. I'm a little confused. You said it messes up your... Yeah, it's not going to overwrite it. It's going to stick this into composer.json. In other words... Oh, I'm sorry. You're right. You're right. It's the wrong extension. If you look at another one. The standard extension install is going to stick it into composer.json on the bottom. What happens when you overwrite? When you upgrade media wiki? No, no. This doesn't overwrite it. I'm sorry. Okay. Let's do that again. When you do composer install, what you're going to do is it's going to take this... I'm doing the wrong extension here. But usually... Let's say you're doing... Right. Exactly. Let's say you were on... Semantic media wiki actually has a note about this. Okay. So here's what you did. If you do this, then it's going to stick this on the bottom of your composer.json with the version. Right? Right. Which is great for now. When you upgrade media wiki, then it's going to overwrite your composer.json. Right? And from now on, when you want to update semantic media wiki, it's not going to pick up that it's there or which version you want it to or anything because it's gone. And that's why they have this little note here. All right. So let's go back to this install parser functions. Very simple. If you want to add an extension, you just put it in your extension array. Done. Google Analytics. Same idea but with configuration. That's fake. And you want to add your logo. Another tip. A lot of people will take this and overwrite resorts assets wiki.png with their own logo. Great idea. Until you... Update. Is it gone? So instead you put it where? In this exact extension. And then it's there. It doesn't go anywhere. Let's actually check this out. No security breach here, right? All right. Let's do that again. Okay. We're logged in as root. Let's change that. Okay. Now we'll check out this commit. You can see what this looks like. Commit something to get itself. That allows you to go forward. One commit. That would be nice. Okay. So this is where the extension is. Okay. And we've added our logo. So instead of this... vanilla version page... Ta-da! Okay. All right. Now we actually create... put it into an actual extension. We put it a blank extension. I don't usually do it like in a gazillion steps like this. But just for demonstration purposes, this is a blank extension.json. It's customizations for the EMW con wiki. It would make my life a lot easier if I called this extension my wiki or something like that and just used the same one for everybody. But companies usually like to see their names and lights on the special version page. So we called it EMW con. You include it in your extension array. Now we can use it for stuff. So a common thing... you want to add custom CSS and you don't want to stick it into the actual wiki. There may be a number of reasons you don't want to do that. So we put it into our little extension here. Instead of trying to stick a hook or something into the local settings, we just do it the real way. We'll add it to the resource loader and there's actually nothing in this file yet. Empty file added on bottom. But it's there and you'll notice that the directory structure of this extension I usually follow the same structure as media wiki. Same way media wiki has a skins folder. This extension also has a skins folder and instead of having like one global CSS file I understand that a lot of this CSS is only going to be relevant to the vector skin. So we put it in the vector directory and then we'll actually use it to change the background. So here the background color has been changed to something nice and nifty. We'll check it out. Nice and nifty. All right. Convert it to a wiki farm. Everybody's been talking about wiki farms. The way we do wiki farms is what's been referenced with Simlinks. So if you look on media wiki.org we do. We've had a lot of success with it. It's really really easy if you're an advanced user. It's just very quick. This is not something for everybody but if you're familiar with this you basically just set up like Simlinks. This is a Simlink and very important that Simlink does not point to this w directory. It has its own w directory which is a Simlink. Why is that important? Because you want to be able to store something for each wiki that might be relevant for that wiki. The same way you don't have a wiki in the wiki route you don't want individual wikis on your wiki farm in the root directory either. You need a robot's dot text for each particular wiki. You need maybe Google site verification. All kinds of interesting things that might be specific to each wiki. So again this is going to be a Simlink to each little wiki. This is going to be the main wiki that's already there. This is going to be a QA wiki which I'll talk about in a minute. I wrote a little extension that's not for public consumption because it's not very good but it's essentially this just with a few extra a little bit of extra functionality so when we load our wiki farm it looks like this. Convert to wiki farm. It's the same thing but with a slightly different URL. So we take out all the path stuff and we put it into this directory here Sites. So this is again all in the same extension. This is a Sites directory which has individual settings for each wiki on the farm. This is going to be the EMW con wiki. Settings for that specific one. I have global configuration overrides and I am going to include this minimalist farm extension. That's that extension that I was speaking about before which basically does that minimalist solution. And we tell it here the name of the wiki so because it says look for emwcon.com it knows to follow that and that's for emwcon.com So that's it. Basically just put in the name of the file and include the extension. We've got ourselves a farm. Of course we have to change for this example we have to change the script path. Usually the script path is going to change slash w because the sim link has a slash w inside. We're not using our own domain name so it changed a little bit but it's the same and you've got yourself a farm. How long does that take? Not very long. You may be thinking I'm setting up a single wiki why do I need a farm? So you saw the answer already. QA site. Ideally you've got a whole different QA server with a whole very fancy system for keeping them in sync and everything is beautiful. But most of us don't live in an ideal world and we don't have a QA server either because we don't need it or we're too lazy. This addresses at least the too lazy part. It's not going to give you a bigger budget but if you're too lazy to set up a different one this takes 30 seconds because all you have to do now to set up the QA site this commit right here at QA site which is not very complex that's it. Now you can test out all your settings whatever you want to change on your local settings. We've all changed things that crashed the wiki. It's not a good idea. Do it on the QA first and then move it over. There's all kinds of fancy stuff you could do with Git with the QA site and the main site. I kept things very linear for the presentation. Any questions on this so far? I know there's a lot of stuff to take in. Alright. Now you can have first site customization you can kind of just detect which site we're on here. This is the EMWCon site variable. So we're going to set this in each individual site's settings. This is the QA site's settings so we're adding this global here we're sending it to QA the main site setting we're sending it to production. What does that allow us to do? This is just in the config where we added the variable and now different styles. So we have a totally separate file this is of course you can do whatever you want you can have the production site CSS plus this CSS load the way I did it here this QA site I want everybody to know they're on the QA site when they're making their changes so I changed the background color to a very nifty very red color and it's going to load its own QA CSS file which is on the bottom. This is how we decide which file needs to be loaded. Well if we're on production then add that module if we're in QA then add the QA module let's actually check this out let's do that again. Since we made this into a farm so our main site is actually here in the QA site there we go so as you can see you got a different background color very clear to you when you're on QA and when you're on production you'll want to keep that straight okay and that's pretty much it here I got lazy, add a few extensions add visual editor add page forms add V for all so V for all I'll just talk for a minute about it we're trying to get visual editor more easily added by different extensions particularly common streams and page forms instead of customizing it for each one like Flow did an adapter extension that is going to service the middle to connect the new extension with visual editor and hopefully the new extension is just going to have to add a line or two and visual editor will be enabled so we're working on that I think that's pretty much it any questions here on okay so the answer is every time every single change it goes immediately into the Git repo practically sometimes it looks like that add a few extensions but really everything should go in there and especially for consultants this is actually very important to be tracking settings with the Git repo because your client calls up you know we've all had this it's not working what's not working it how do you figure out what went wrong so if you have a Git repo there then you'll see immediately either they made a change and committed it to Git and you see immediately what the change was and who committed it or more likely they made a change and didn't commit it to Git in which case you do a Git diff and you see what went wrong and you just roll it back so very important really in all settings in corporate environment anything you have to be able to track your settings on your wiki so that's the way to do it yes this extension it's an idea the answer is because it's really easy and fast for me lots and lots of times it's an idea in the right time part of the reason it's harder like I said I like to customize the name of it for everybody although that could also be made easy anybody ever use when you're developing extensions anyone use the cookie cutter template I didn't put it on there's a really cool cookie cutter template where you can insert the name of the extension and it just puts all the stuff in with all the internationalization prefixes into the internationalization directory it gives you a hooks file it gives you a parser function it gives you a sample special page it's like boilerplate but you don't have to go into boilerplate afterwards and change everything it's really good okay I'm at 30 minutes and 6 seconds let the record show alright thank you very much everybody