 Welcome to the April Developer General Hangout. We've reverted back to the old Google Hangout method for now until we can find a better alternative. Big blue button is 95% there, but still letting us down on the screen sharing and things like that. So unfortunately, we can't use it. And we have this mix of video and Hangouts and the chat on developer chat with associated lag. So there will be some lag. It can be up to 30 seconds or a minute from experience. So hang in there. And hopefully it'll be usable enough. So the schedule for today is laid out on the web page. And with that much further ado, I'm going to hand over to those people talking about facets of 2.7, which is under two weeks away from release. And I'd say overall it's looking good. But let's hear from some of those on the agenda. So who's up first? Yeah, I thought we'd ask Sam to go first. By the way, if it seems disjointed, it's because Martin can't hear us. First up, Sam Marshall is going to talk about conditional activity conditions, which he brought in. Congratulations, Sam. So are you around, Sam? No, he's not. That's an embarrassment. He's on a dovetail. I'm not seeing him in the Google Hangout here. I shall write. Yeah. So let's skip to the next one. And the next one is Damien Weas to talk about ATO and what ended up getting into 2.7 for that. So over to Damien. Everyone, I hope you can hear. All right. So we briefly talked about the text editors at the last meeting, and that's when we were still running the prototypes and getting feedback and making a decision. But we decided to go with ATO and have been working really hard on polishing it and adding all the features so it would be ready for 2.7. So it is now ready to go. It's been integrated. And it's got its final version. And just some quick history, it initially came out of some playing around with the HTML file feature, which is content-editable divs. The general idea behind those content-editable divs is that the browser is the one that implements the text editor, and you just add some supporting functions. But that's kind of the idea behind ATO is that it's more lightweight. It's not trying to be super restrictive about how everything works, but the browser's supposed to provide their own implementation of content-editable. And because it's from the browser, it's more reliable and more robust, and works better on things like mobile phones where running a whole bunch of JavaScript slows things down. So that's been integrated now. The TinyMT is still available. It's still installed, but it's not the default. So any user in Mertl can change what text that they prefer in their user profile. So anyone can go in and change back to TinyMT if they prefer that one. But at an end-in level, you can enable and disable text editors, which will prevent someone from being able to change one. So they still have that choice. And if there are any plugins that they're relying on in TinyMT, they still have the option to go back to it. But TinyMT that we're shipping with Mertl is still the 2.x version of TinyMT, which is unsupported by Moxito because it's so old. And over time, it's probably likely that as new browsers come out, that version will be less stable. It's pretty good at the moment. There's no issues. But I imagine IE12 and things like that are going to create issues which are not going to be worked on because it's out of support. So Atobe will be the one going forward that we will be working heavily on. I don't think we would still fix any TinyMT bugs that were critical. We don't have any plans to do that upgrade to 2.5, 2.10 for 2.7, but we could do that for 2.8 if we had to. There was critical bugs. TinyMT plugins 100% incompatible with Atobe. It's a completely different plugin system. The Atobe plugin system is very much more of a Mertl plugin system. Whereas TinyMT is a plugin system with a bunch of extra changes required to make it integrate with Mertl. And so it's quite a lot more complicated. Whereas when you write a plugin for Atobe, it follows all the standard version.h and language. All those things are easily in our database tables, if you want to. And the way that we load the JavaScript is compatible with all the other JavaScript that we have in Mertl. All of the dialogues use the standard Mertl dialogues. And the benefits of that is that any accessibility work we do on dialogues will be reflected in Atobe and it will be consistent when we use Atobe dialogues and the file could get around all those other things. They all look the same, which is a good thing. We have a lot of docs on Atobe. So let me do a screen share. Do a screen share from here. Yeah. Second one up. OK, so this is the developer docs for Atobe. I started days and Andrew Nichols has done a lot of updating on them, which is really good. Really quite well documented. And I love the refactoring we did in the JavaScript, and doing that really well. And so it's quite a neat system for writing plugins. Basically, I won't show you all of this because you can read it yourself, but this is just saying, these are all the standard Mertl settings.php files, version.php. They all work the same as any other Mertl plugin. There's a way to load your strings for JavaScript in an Atobe plugin by implementing this callback function in your lib.php. And that just lets you call this the standard strings for JS function. And the benefit of doing this is that you get all the strings loaded all at once when the page loads instead of being loaded later by a callback. So it's much faster. The content editable itself is a standard browser feature. And basically what it lets you do is call this document.exec command, which will do various browser features. And just to show you an example of the simplest type of Ato plugin, this is the Mertl core plugin that puts a line through the text in the page. It's very simple and small. There are some supporting files which aren't shown here, but this is all of the JavaScript that you can see. So basically you create a class that inherits from this editor plugin class. And everything is pretty much set up for you. And in the initializer of the class, it calls this.addBasic button. So by extending this class, you get a whole bunch of basic functionality for adding buttons, toggling this state, and simple things like that. The exec is the document.exec command to run when the button is clicked. The icon is just the icon to show. And it's a standard MoodlePix icon. So it supports SVT, all those other things. And the tags is we've built in support. So if you want to have the button highlighted when the cursor is within certain tags in the HTML, that's what that tags will do. It will automatically search for you. So as you move the cursor in and out of us, drag through. They want to zoom in a bit, they can't fit. They can zoom. It's the other end of the place. Ooh. I think I'm way spinning, maybe. So that is the most simple plugin that you can write. There are more complicated ones. All of these examples are linked from that DevDocs page. So if you find it hard to read, you can just go there and read it in your other browser window. But that's basically what we've got it down to, is this object-oriented system. And you extend the class. And you have all of this built-in functionality. And it's all as simple as possible. So yeah. All right, is that all? Is there any, I think, if people have got questions, they'll come up in the chat. And there have been a few questions coming through that you've been. Thanks for that, Damian. If we can go back to my sharing, I've got screen sharing showing the agenda at the moment. We had Sam up first. Sam, are you ready to present now? Just a minute. I hope so. Yes, sounds like it. Yeah, we can hear you. Brilliant. Well, I mean, to be honest, the conditional activity changes are in Moodle 2.7. There's a new user interface, which to be honest, I think most people are probably seeing it by now. So I'm not sure if it's relevant so much for developers to demonstrate if people really want that. The relevant thing for developers is actually not that much, except there's a new plug-in type you can write. So just to sort of review, the conditional activities basically lets you control access based on date, user profile fields, whether or not you've completed another activity, a grade in another activity, also groups and grouping. But you can now add plug-ins. So if you have a particular local need, maybe there's some kind of institutional thing that you want to be able to give people access based on that instead of a standard Moodle user profile or something. So essentially, you can do that now. It's quite easy. And there's documentation in the Moodle Docs page. Something's already written one, although I think it may have been a slightly tongue-in-cheek one, not quite sure. Have you got anything you can share to show us, Sam? OK, so I could show, well, let me try doing screen sharing. And I'll see if I can find a button. Let's look at this one. OK, I'm screen sharing a completely relevant window at the moment. But if I go to right, so I'm just going to log into my developer site. And I'll just show you the user interface for this. This is basically just the surveillance settings for, well, I should have edited a different one. It doesn't matter. Apart from the Atto Unlink plugin. So all of this stuff is down under Restrict Access on the, I'm hoping you can see this, by the way, down under Restrict Access on the activity settings page. You can do Add Restriction. You can click a button for which type of restriction you want, like, say, a date. You can set up the restriction, change the day, et cetera. So that's pretty much it. So I'll just do a group one. So for group, we could have, I think that's all belongs to any group, or belongs to the group called SSS, apparently. And you can see I'll switch it from and to all. You can also do nested restrictions. So there we go. We've got a nested gray restriction. You can make it quite complicated, although normally you probably only have one restriction or something. So as for developers, if you want to build a new plugin, I don't really want to show you the code, but maybe if I can find the mood of Docs page. I'm not super prepared about this, sorry. I'll see if I can find the page on mood of Docs. But I'm not entirely convinced that I'm going to. Sorry, it doesn't seem like I am. So basically, there is a page on mood of Docs, which describes, oh, here we go. No, that's the other one. OK, I'm going to give up doing that and stop the screen sharing, possibly. So yeah, so basically, it's possible to write plugins. It's not very difficult. You have to write some JavaScript, which controls the stuff that gets added to the form, basically, and a couple of small PHP classes. And some people really have to do it. So you can also use the group or the group in one. It's quite simple. So you can use those as a base to create a new plugin. I'll just do a quick look at any questions that don't seem to be in question at the moment. So yeah, I think that's probably roughly all I know. I should say about the rest of it in terms of the API changes. Generally, developers don't need to do anything. There is stuff in the upgrade.txt that tells you which API has changed. But normally, most of those are just called by core. If you do get affected by it, all the common ones probably should still work. And you'll get a deprecation warning that tells you what function you should be using. Basically, it's going to be the namespace of class. Pretty much it, I think. Let's see if it has any questions. All right. Thanks, Sam. There hasn't been too many questions that have come across. And I think you've answered the questions that I was thinking of in relation to what developers would have to do. So there's a lot of action. OK, man. It's gone. Has there been any other plugins mentioned by anybody? Or do you have any on your roadmap? Or have you thought of any other possible ones or heard of any? Well, one of the ones that people actually ask for, which is actually in this release, is there's a group one. So I don't know if you remember. Basically, it used to be a restrict access with grouping, but not with an introvert group. So you could do sort of to show it to people in a group only, but you couldn't choose like a single group and show it only to those. So that's in release already. To be honest, I'm not really aware of any other general plugins. I think it's maybe more going to be useful for sort of third parties. Like I know at the OU, we're going to want some custom plugins to do with things like which qualification people are on, which is some information that isn't really in the mood at the moment, but we're probably going to get that in and then maybe do conditions on that. But it'll do custom field checking, right? Like custom use? Yeah, it can already do custom user field. So if we put qualification as a custom user field, then we don't need to do a new plugin, yes. All right. Going back to the agenda, which is the screen that I'm sharing. The third item we had up was the theme cleanup. And the more theme is Fred, ready? Yes, I am. What did you have to share? Share your video or something? Let's share this screen. Well, there's not much to say about that, because I guess you would mostly already know what happened. But for do's and then clean is the default now, the theme clean for 2.7. We also, at the same time, removed all of those old themes that were in there for a while. So you don't even have standard anymore. The only thing that you can select are clean and more, which I'll talk about in a minute. We kept the base, though. So Bootstrap base and Canvas, which can't be selected, but can be used for the theme development, are still there. So you can still use them, and you can still use the previous themes that you had if they were extending those base. All the themes that have been removed from core are now on the plugins database on Moodle.org for 2.7 versions. So if you were using them, you can download them from there. And you can read the upgrade process. If you are using one of those at the moment, then you should read the upgrade process, because we recommend you to put them back there before you run the upgrade process. So the new theme more essentially is targeting people who don't have the resource or the skills to develop their own theme. It's a theme with more settings than clean has, where you can actually change the color of the text or the background, set a background image. A few settings like this, you can't do many things. We can do enough to change completely the look and feel of Moodle, which is something that small schools and this kind of stuff would probably do. Under the hood, it actually uses less to compile two CSS on the fly. But it does not affect performance, because it's cached as soon as it's compiled, except if you've got theme designer mode on. But obviously, it's not recommended for production mode. It's not, we don't recommend theme developers to actually use this compiling of less if they want to develop themes. The purpose was really only to be able to inject variables in less before we compile it. And so the only reason you would use it is if you wanted to provide a theme that has many settings that you would want to use to do less functions and less variables in the CSS that you're providing, in the less you're providing. But otherwise, if you don't really want to play with settings, then you should keep on developing the themes you were doing them before, the way you were doing them before without having to interfere with that. Yeah, I don't know if I had anything to say about it. No, I don't think so. It's pretty brief. I don't know if you guys think I missed something. Can you briefly talk about what someone should do if they're using a theme and they have to upgrade? Yeah. So basically, once you check out the new code of Moodle 2.7, the previous themes will disappear. But then before you run the upgrade process, you should download the theme from Moodle or extract the Zip into the theme folder, having everything ready. And then you can run the upgrade process. If you don't do that, then the default, say you had set the default thing with standard, and you upgrade, and you haven't put standard back there, then the default thing would be clean. If you had put standard back, then the default theme would still be standard. There's not much to read about us or anything. It's just that it's more convenient to put the theme before the upgrade than after. I don't know if I'm in the sense. No. Well, although I thought this afternoon we'd agree to leave the old settings in there. Anyway, the settings of the theme, so if you set a logo in Afterburner, or if you set a custom CSS in something, it will not be lost. I'm just talking about the theme selector page. If you set the theme, that will not exist anymore when you upgrade. Then it will be replaced by clean. That's the only thing. But it passed only three clicks to restore it afterwards. But all the settings that you had actually set for that theme specifically are not lost. They're still there. We kept them. And we're planning on removing those eventually in 2.8, when we're sure that everyone has gone through all these steps and cleaned up a bit of that. But it's worth reiterating that generally most theme designers, if they're making a custom theme for a site, would start with maybe by cloning clean and working with that and doing their own less compilation because it's actually much easier to do it that way. Because you can use your own command line tools, your own system that you're using now. And it's pretty efficient. So it's good you mentioned that. I was going to suggest. All right. There's discussion going on at the moment about the performance of conditional activities. And that's being answered in dev chat. But I don't see any theme-related questions there. So we might continue on when moving on at breakneck speed. This is good. Task scheduling back in. OK. So there has been an old tracker issue, which is mbl25499, which is a matter for a bunch of issues, which is all about being able to change all the schedules for all the tasks in Chrome, makes Chrome running parallel and make Chrome scalable and be able to run it on different cluster nodes and do lots of stuff. And that is in 2.7. So what this basically means is that you can do two things. One is you can create a scheduled task in your plugin, which is just any task that extends, which implements the scheduled task call slash task slash scheduled task class. And then in your plugin, in your dv slash tasks.php file, you define the default schedule for that task. And that default schedule is set up in like a standard Unix Chrome syntax. So you can say on every Tuesday at 9 and 12, I want to run this particular scheduled task. And then it will be run automatically by Chrome. The second thing is that you can create ad hoc tasks, which will basically run at the next opportunity in the background. So they don't have to be scheduled. And to do those, you extend the ad hoc task class. And you tell the task manager to queue that task to run. And then it will just be run as soon as possible by the scheduler. So I'll just link to the Docs page for that. Obviously, this is what you mentioned, command line execution and disabling of tasks. Yeah, I'll mention that. While you're looking for that, can I say something? Yeah. Tim, you were saying something about it takes more clicks if you set course themes or user themes. Yes, but we don't lose the settings, so even if you upgrade without putting back the theme that was there, the user and call settings remain. Once the theme is set back there, then you will go back. It will use that theme for the course of the user or the category, whatever. Yeah. OK, and this is the task API Docs, which tell you exactly how to set up these scaling tasks for developers. Do you share it? Yes. Sorry. Yeah. So I'll let you go through and read that. But some of the benefits of doing these scheduled tasks versus using the old Chrome syntax is that the scheduled tasks can run in parallel. So what you should do when you upgrade to 2.7 is you should increase the frequency that you run your Chrome scripts. I recommend you run it once a minute now. There's automatic locking built into there, so it will never run the same task twice. But if you run it more often, if there's no work to do, it will just exit really quickly and not give you any performance loss. But if there's lots of work to do, the first task will start running. And then if that's still running after a minute, the second one will skip that task and start running the next ones in the queue. So basically, the more things that are holding Chrome up, the more parallel tasks will run. And everything will scale a lot better than it did before. So you can run all those on a different cluster node and you're using clusters, just like you could before. But you can do some more complicated things as well. So for example, you can go into the admin page for the scheduled tasks and disable one of the tasks because you want that particular task to run on some specific node, which is not your normal cluster node. So maybe it's the LWAP sync task that only one machine has access to the LWAP server and it has to run from that node. So you disable that in the admin interface and then there's a CLI program that Peter added, which you can tell it from the CLI to just run one task immediately. So that way you can, if there's specific tasks, you want to run on specific nodes, you can run them via the CLI and do it manually and sort of really have very fine-grained control over what tasks run. Sometimes there was a requirement to run the synchronization of users, for example, only once or twice a year. And this way you just tell the model to not touch this thing and just you can explicitly say when it's getting run. Yeah, or you may want to just run it right now because something important must happen. Or if you do unit testing, it's a handy tool because you write a new Chrome task and then you execute that one and you don't have to wait for 20 minutes to get it executed again. You can run it over and over again and it always gets executed. Yeah, and the other thing is about failures. So the way that the whole Chrome work is that if one thing was causing a PHP exception, that would block the rest of Chrome, which is no good. But the way this new one works is if something fails, it will be given a back-off time and it will get rerun again. And if it fails again, the back-off time will double and it will keep doubling until it gets to 24 hours. So basically any tasks that are failing the fails will still be in the log but that task will not be run again and again and keep blocking everything. It'll get skipped and backed off until it starts working again. It's pretty much all the command line tools we had before should be migrated to the Chrome tasks and they might be even disabled by default. So it's like all the time is scripted. Unfortunately, we didn't manage to convert authentication and enrollments, but all the things lying there which were supposed to be executed by admins manually should be migrated to the new Chrome infrastructure and it should be used from there because it gives the admins better controls and when it's executed. Yeah, so for 2.7, we've done all of the core, the different Chrome things that we're in core like running the enrollment plugins and setting up a new user passwords and all those things. They've all been converted to schedule tasks but most of the plugin tasks, plugin crumbs haven't. So if you don't convert your Chrome stuff, it will still run. And the way that it runs is there's a single legacy Chrome schedule task which goes through and runs all the crumbs for all plugins. But that means if your code is still using the old Chrome syntax, it won't run in parallel because there can only be one instance of that legacy Chrome task running at one time. So it will still be queued along with all the other legacy Chrome things. So really, if you have those Chrome things, it's best to convert them as soon as you can. That is a question there. How many tasks can run simultaneously? What is there an upper limit? No, there's no upper limit. But there'll only ever be one instance of the same type of task running at one time. So with the number of plugins, the number of tasks. You can't set up dependencies between tasks. You can set up their scheduling so that one of them will start roughly when another one finishes. There is one level of control that you can do. If you have a particular task that needs to run on its own, it can say that I'm a blocking task and that will prevent all the other tasks from running while that critical task runs. So an example of that might be the enrollments. So authentication. Yeah, if you want dependencies, you could set up one task which does the individual things that you want to be done in order and schedule that instead. Yeah. Can it still be extended in the future if necessary? Yeah, if there is anything that is critical that people need, we can add to it. But I think it's really good. I'm happy with it for 2.7. And when we convert all of the cons from all of the plugins, it will run really well, I think. So it's pretty much just defining one file which sets the default when it is executed and one class with one method which tells you what is going to execute it. So the migration is pretty trivial. Yeah, all I did is just move the code into this new class for all of those different things, basically. So there's a bit of discussion going on in Dev Chat, but too many questions coming through there. It's nice to see Martin one hope again with his ideas. It's run under Moodles. So the same CLI that ran Moodles Chrome and the same admin page that ran Moodles Chrome, now it doesn't run Chrome. It runs all the scheduled tasks. And the old legacy Chrome stuff is one of those tasks. So you don't have to change anything and everything will still keep working. Except increasing the frequency. Yeah, you should increase the frequency and you'll get better performance and emails will go out sooner and things will run in parallel. Yes, the CLI runner, you can tell it to run an individual task right now. Damian, anyway, so one more 2.7 item. There is the logging stuff and Pet is gonna lead that discussion. Over to Petta. Yes, screen share. Okay, you can see me. So we have discussed the new logging a few times before. Most of the things which are done in add-ons were already present in 2.6. So it's just a quick overview what you are supposed to do as an add-on developer. So first thing, we have finally managed to convert all add-to-logs calls, the original ones, into new events. So this method add-to-log was completely deprecated. So you shouldn't be calling in your add-ons. Well, you will get defining messages if you do. The same goes for all events. So all the old logging and all events should be replaced by new events. There should be quite a lot of examples in the 2.7 release. I think the best one at the moment is Modest Sign, which is using the latest coding style that we invented, well, just like two weeks ago. Two, three weeks ago. And it was just like during the time where we were converting so many things and we just saw what's being repeated and what's not. And what works, what doesn't work. And I think you've added quite a lot of validations and all the nice things that help you during the conversions. So it should be relatively easy. So if you are an add-on developer, first thing you should try to do is to convert all the old add-to-log calls and events to the new system. Hopefully it will be relatively easy. It's quite a lot of code, but it seems to be beneficial. So there's really a lot of built-in validation. So if you start writing the code that if you do something very wrong, you should get either the bugging message or a coding exception. So that should be pretty straightforward. And don't forget to write unit tests. It's really, really good. If you upgrade to 2.7 as an administrator, you will have two login systems available, the old one and the new one. Both of them can be working at the same time, but by default during upgrade or installation only the new ring system is enabled for performance reasons. But you can still enable the old login system because the new events contain backwards compatibility for old events and old login. So both old observers and old log table can still work, but you need to enable it. This is a good thing for you, especially if you have some old reports which were using the log table. You don't need to convert them right now, but if you have them, you have to tell your users or administrators that they need to enable the legacy login. The cost of legacy login is a few writes a page. So there are performance costs, but it shouldn't be that bad because the new system is using just from one write query page because we have the new system for writing multiple things into database in one query. We have updated all the reports. We have a standard distribution. They should be working both with the old data and the new data. So if you have some historical data like on the last year, the reports should be using the legacy log table. If you have the new data coming from the new login system, it should automatically switch to the new login system. It's a bit messy in sight, but, well, yeah, it works. So for our users, it should be good enough. If you want to create some new creative reporting plugins, now it's the right time, I suppose. You need to decide if you want to support the old system and the new system. We have decided to make a solution where we actually emulate the old log data to appear in the new system. The data is not that rich. We are just guessing sometimes, well, most of the time, but it kind of appears to work and gives you some view and historical data. So if you write new report, you should be probably using only the new APIs for reading from the new event logging source. So we have kind of written an emulation layer for the old log data. So if you write a new report, it should show the old data without much problems. So what you can do now, what you can plan for later release is the task number one is to convert the add to log calls and old event triggers. The second task or the second thing you can start thinking about is writing new reports. We have so much more data, so much more information in the new log table. You can write new statistics reports. You can try to do some special reports on the data, special research on the data. And the next thing what you can do is you can try to write your own specialized work store, which stores the event. If you use the standard interfaces we have in core, the reports are going to where the standard reports are going to work. If you invent your own special thing like no SQL, then you will probably have to write your own reports. But you can submit those new interfaces for integration into core, which would mean that if you define or create some fancy interfaces for no SQL databases, and if you make it work with the standard reports, we can accept it into core. And it should be working fine in the future. All the interfaces are pretty open. The center part is the work manager, which actually returns you all the information through PHP interfaces. So it should be pretty free to define it in any way you like. The only trick that part is how to define some way, how to request information from those external systems. At the moment we are using SQL. We didn't define any interfaces for no SQL or anything else, just plain text files. But you can still do it. And it's easy to do it as your custom add-ons. And those interfaces could be integrated in the core in the future. There are a few questions there. Oh, yeah, question. Peter, could you share the transition docs? Oh, if I remember the URL, I probably could. It's all jelling from the real stuff. I think, yeah, just open the event to maybe end. I think everything else is on there. So the migration for the events, you create a new file for each event in the causes directory in a new PHP namespace event. And that's one thing. Then we have API for reports. So we have a new document for migration of reports. And then you can write your own store, which is yet another. It's mostly API. So it's basically each of the interfaces you just implement and then it should work. Let's go ahead and do this, OK? What's the stuff you control it? I don't know. Just type it all. If you do this, then I cannot finish the page. OK, I'll be it. Can I see it? I'm still seeing a figure on your screen. Yeah. Are there any other questions? Yeah, well, one more thing. You were discussing quite a lot of hooks because the old events were doing many, many things, but they didn't do it well. So we kind of created the new events and chartering only the half of the things that the old events were doing. So there was quite a lot of discussion about hooks. So I hope that in 2.8 we will progress further and just return that functionality that we have in all the events, which was like a communication wave for aliens or general plug-ins to talk together, which is completely outside of the reporting and logging and the thing being implemented here. So something which is a lot more relaxed, where you can communicate between two parts and anything you like. So yeah. There's a question from Eric here. If the old log is disabled, when you back up with logs, will the logs from before 2.7 upgrade will be included in the backup? Well, the restore will not change. It's one of the things that it will be probably continued in 2.8. At the moment, the old logs are restored the same way as before. So your legacy logging is still failed during restore, even if it's disabled, because there are low-level rights into the database. So that thing restores it. And if you use the legacy log reading, you will see the data, the history, the data the same way as before. But the new logging system is actually triggering events during the restore, extended events with the current timestamp. So you actually see in the log what's created in the course during the restore process. There is a special flag origin, which tells you if it's coming from a web service, standard upgrade request, restore, or command line. So you know the difference which actions are coming from the restore. And there, we will have to write a new hook for both backup and restore. And let the individual stores, logging stores, put the data into the backup file, and then give them a chance to restore it back into their own tables. Because we can't trigger the event with past time or do some other things. So this will have to be implemented in the log stores, the backup and restore. So there is another question here. We also have a lot of custom SQL reports. So what should be done in our bottomers just? Your custom repository using MDL log is going to work the same way for the historical data. And if you enable the legacy logging in your 2.7 installation, they will still continue working. So everything that was logged in 2.6 would be also logged in 2.7, and your reports will continue to work. If you want to migrate them, then you need to decide if you have both type of interfaces or both type of the log stores are going to support. And you have pretty much two choices. One of them is using fetching of individual events. And the other one is slow access to database table, which is probably what you are going to be using. So you will be pretty much only updating the names of the columns. And the rest should be working just fine. One example where we do a participation report. Outline report participation at 2.7 converted. It's quite easy if you want to just continue using joins. So you just switch from the old MDL log to the standard legacy default table that is produced by log store standard. But if you want to move on to a better way of doing it and just do selections or something, you can do that as well. So it depends. It's a choice for you, which way you want to go. Well, the old log table is kind of a subset of the new standard logging system. So it pretty much maps very well. There's more information than you said. There's just more information. So the migration, how long did it take a few days to do the initial conversion of reports? Surprisingly, the conversion of reports was not that difficult. We were mostly discussing the interfaces and some recommended coding practices. So I suppose it took the guys about one day for each report to show something that was working. And then we started discussing how to improve the interfaces and how to do the coding style. So the conversion of reports was surprisingly easy. There is one more thing. With the new event, there is a feature called anonymous events. So you can mark an event as anonymous. It's not used much in the core at the moment. I think only feedback is using it at the moment. So when an event is marked as anonymous, all the reports are supposed to ignore those events. And in future, we can decide exactly what is the scope of these things. And maybe we can show it based on a capability or something. But yeah, we have put in a place, a framework, so that we can work on this more in future. And what else? There was one quick comment from Tim about how hard it is to log one action. Petter did some work on the assignment events. Basically, he added some functions to the events in the assignment-based events so that he could go, whatever event type it was, create from submission and trigger all in one line. So the whole analog is, well, the equivalent analog is one line once you add those helpers to the base class in your event. We invented quite a lot of tricks there. And we had long discussions if it's the good way or bad way. And I really believe that you should probably study more assigned, because that's the best example. How to convert some complex things if it's something simple, well, you would probably do an easier way. Is there anything to answer? I'm not sure what this question is. It's about the hooks, it looks like. This one is about the hook, and the other side. Anyway, Marina is our hooks expert. So if you have questions about hooks or ideas, well, maybe you should contact her. We're scrolling down to read a little bit behind. Yeah. The number of lines is not really what the matter is. Anyway, we are close to the release, but at the moment we are working on some final cleanup of event commands. And we will be working on the documentation and guides. So we will try to put there more information for you guys. One more thing which we forgot. There is a new events list report. So there is a new report when you can go into your report static tree, and there is an events list report which lists all the events that are presented in your install. And it lists some basic information about what is the object table, what this event does, what is the component, and other kind of things. And it gives you a basic summary of the event and other similar things. And it also tests the event. If you can't get the information from it, then probably there is something wrong with your event. It's probably worth the point that if there are developers out there who are working in institutions with researchers or people who are wanting to do analytics that those events can now be listed, and then you can go through the logs and filter out the ones you want, or create your own report that does that for you. So a lot of the information that is buried in the code is now made quite obvious to people who are looking for it. So there's a lot of good stuff coming out. And that was the original goal to make it easier for people who are wanting to run complex reports and to do analytics and to be getting this sort of information in real time. OK, I think it's one great benefit. Another one is that obviously you can listen to those events and act upon them. So you don't have to write reports. You can just do a plugin that does something whenever someone does something. It's also another option, something that's good. Well, everything there is fully pluggable. So if you don't like the new login, you can uninstall a few plugins and it's all gone. And you can add your own login system. You can add your own report. Nothing is there hard-coded. It's just like one configuration variable which tells you what is the login manager. And from there, everything is just constructed on the fly. So everything is fully pluggable and nothing is hard-coded in code except the events. Event list. Are we sharing? Yeah. We can make the windows smaller. There's something there. Good work to make on getting this done. It's also great that multiple people are involved in the events, cleanup, documentation. So pretty much everybody from the back-end team should have a full understanding of the whole logging system and reporting on events. To increase the font size. It's the view, I think. That's too much. OK, a question from Nadav. There. Do you mean, is the logging happening in the same database? I assume that's what he means. OK, so by default, we are shipping three lockstores. One is the legacy one, which is happening on the same database as before, which is the MDL log table. Another one, which is the main one, is the lockstores standard. And that's happening also in the same database table. And we created another one for people who want to write to external database, which is disabled by default. It's called external lockstores underscore database. So you can use that and write to a different database. But again, some reports might not work if you just use an external database and disable internal logings. It depends on the report. The report decides which kind of store it works with and which kind of store it doesn't work with. Yeah, so just a correction there that it's going into a different table, standard logging, different table in the same database. Database, yeah. If you want to write your own logging, you should probably start with a standard store. There's probably a code inside because we have started using PHP traits. So it's very easy to create your own specialized database store, which might be using multiple database table or separate database for reading, writing, might be doing magic with clusters. So it's really fully flexible. And I suppose that all the big installations are going to create their own lockstores of leggings that are doing the fastest way possible for their actual setup and database type because writing something which works for all the supported databases, well, it's not easy to make it fast because you need to go on a really low level. All right, I'm wanting to sort of keep this moving on. I think we've talked a fair bit about logging here. There might be some more questions that come through in chat, but I think we should probably move on to the next item. So Man, so a few people have been asking what LTS means. It's been mentioned a few times. Do you want to go through the rules for 2.7? Yes, pretty simple. A lot of people have been asking for some sort of locking term support. I guess they look at a few other open source projects and they want the same familiar stability, mostly that people are doing a lot of hosting. And so we're trying to keep them happy. And we have finally won that 2.7 to be a long-term support release. What we've decided that means is that, whereas before, we were doing security and made urgent bug fixes, sort of data loss kind of security bug fixes for one and a half years. So that's been the case for the last two point X releases. We will now go for three years. So we'll backport things to 2.7 way up until June 2017 for the next three years. What that means is if anyone is submitting an issue that is a bug fix for any future mood over for the next three years, they also need to backport 2.7. The kind of things that should be backported in that period are minor fixes, sorry, maybe more clear. Any minor fixes get backported for the one-year period. So any small ordinary little bug fixes for one years. But the three-year period is for those security and data loss bugs. So if there's anything more serious that gets fixed in 2.9 or 2.10, they must be backported to 2.7 as well to be integrated. And we'll be sticking to that HQ. And I guess most sub-native bugs will be the same. That's it by the time. So the main thing I'm hoping we get out of it is a lot of people who are currently stuck on 1.9 because they see it as a long-term support release that is no longer supported will find the impetus to jump into the 2.0-point-something series, hopefully onto 2.7 in the near future. That's the main reason for it. From my point of view, I would still recommend people keep upgrading to 2.8, 2.9, 2.10, et cetera. Of course, we're not working on all this stuff or nothing. But hopefully it will put more people forward. So that's the main reason behind all that. Any questions on that? It's pretty obvious, I think. I don't anticipate another long-term support release for quite a long time because it is expensive to make to do this. There seems to be. Oh, am I having bad audio? Yeah, well, it might be a bit much on your connection. Yeah, I don't see any other questions coming across in relation to LTS. So maybe you could quickly give a rundown on, you mentioned it earlier today, the sort of roadmap after 2.7. Have you added that to the roadmap document yet? Well, not really. Some of it's still a bit up in the air. So I wasn't going to talk about it much here. I'm going to talk about some of the major things. We're going to be looking at outcomes again, outcomes didn't get into 2.7. I'd like to push that into 2.8, as most of the code is written already for that. But once we have them fully done and it fits in with the other bits, we should go in. Slightly improved forums, also for Moodle rooms, they already have improved forums for accessibility and so on. We'll be looking at that to see if we're getting that into the Moodle core. The element library, which has been talked about for a long time. That's about making a library of patterns very clearly documented so that we have building blocks to build up more pages, and we'll be encouraging all developers to use that all the time. And we can also then help themers because we'll have nice little components of elements that we're using pages as we already do. But it'll be better than it is now. There's been a lot of talk about it, and there's a lot of work was done on it at the recent hack. So I guess, Michael, you talk about that. You can mention that. There'll be more logging events we're working on. So that's, as we said before, there is an epic already for adding more logging events to flesh out the logging in Moodle to fulfill its promise, which is currently only really replicating the old login. We have to make it log everything. And there's a big one, which is to work on the gradebook again. The gradebook is something I've really wanted to work on, very hard to work on for developers because we don't understand how it's used in all those many ways. There are a lot of people in the community who've been working on gradebook. And there is a meeting happening in, it's almost becoming gradebook conference in early June, where people interested in gradebook will be meeting in California to basically work on a stack. We're interested in that, getting in touch with me probably, and I can get in touch with everyone else. We'll probably be announcing it very soon. We're going to be doing some preparation work for that, doing some surveys, gathering all of the tracker things, all of the community work, and trying to bring it all together into a roadmap for gradebook. And then Moodle Core teams will be working on that for a while during the 2.7 cycle, 2.8 cycle, to actually improve gradebook. So the two major areas in gradebook are about the usability of it on all devices, including accessibility. And also the making grades more plugable, work with plugins, so that ideally, Moodle doesn't need to reinvent a grading interface every time. It just says, I have some stuff to be graded. Here we go, those kinds of things. There's lots of documentation everywhere about it. We have to pull it together, and that's what we can do. What's kind of the roadmap we're looking at? All these things are in flux, and hopefully it will happen. If not 2.8, it'd be 2.9. That's about it for me. Sorry, the sound quality is so bad. I don't know why that is. It was coming and going there, Martin. I told you Google Plus is jumping the shark. Yeah. All right. So yes, going back to the agenda, the last item on here, and then there's a couple of questions that people have asked, and we might throw it from the floor at the end. Just briefly mentioning what happened at the Hackfest in the UK, which was about a week and a half ago now, I'll just take it to the page, which is linked from the agenda if you're interested in that. So there were quite a number of people there. It was only a one-day event, but there was still a lot of activity that went on, a lot of brainstorming. And hopefully that enthusiasm will continue now over the next few months. It's my task sometime before the end of this week to get back to all the attendees who were there and trying to encourage them to take some of their notes and start turning them into specs and so forth. So you can see there on my screen that I'm sharing, and hopefully that's big enough for you, the various topics that were discussed. There were four sessions, and the fourth was kind of like a continuation of some of the earlier ones. So the element library, which has sort of been mentioned by Martin as a target for work. The potential for analytics, obviously there is a need to get the sort of information we can get out of events now from the static data tables. I don't know what went. Some of these groups I wasn't obviously involved in myself, so I don't know exactly what went on in all of them. So some talk about LTI. The lesson module came up, and there was a fair bit of discussion about simplifying that to allow people to use it more easily. Maybe rethinking its purpose for assessment and so on. Some administrative type oversight over emails, so being able to see within Myrtles what messages were successfully sent, which weren't. So there's a fair bit of talk about themes, particularly Bootstrap, and some people were interested in Bootstrap 3 there. Some people were looking at fallback to HTML5 and so on and doing that consistently and making it look good. There was a bit of discussion about add-ons. This wouldn't affect middle call, but there was a number of suggestions made that hopefully would allow us to improve the add-on, the plug-ins directory, and the trust model that's used there, and how we can encourage people to provide their opinions fairly. Honestly, on plug-ins that have been contributed as add-ons. And there was a very fresh idea from Davo Smith about having some sort of block or perhaps something that floats on course pages that would allow people to design courses just by dragging elements into the page and then perhaps providing some minimal details each time they do so. All right. I'm just looking at the chat log now and I see that there's a fair bit of discussion going on. But some talk about long-term support and so on, still continuing in the background there. I mean there's potential for themes to be based on Bootstrap 3. We've sort of made the decision with clean not to go down the Bootstrap 3 road just yet. But I suspect it'll happen at some stage in the future. Yeah, it is certainly non-trivial. Doesn't seem like designers are too interested in backwards compatibility. So yeah, there's been a fair bit of clean-up in clean and themes in general and how they're then applied throughout Moodle. And so that should be easier work to do in the future. Also yes, the element library will help people bring those things together more successfully. All right, back to the agenda. We finished the items that were suggested and there were a couple of questions down the bottom and I'm probably not the best person to answer all of them. But the first one, a status on adventures in LTI. Not quite sure, but there are some people who are responsible for LTI probably here in the meeting. TINCAN is easy. One of the things that was done with the new logging and events work was to make sure that all the TINCAN actions were covered in the events system. So if someone wanted to create a TINCAN plug-in that logged things to a TINCAN system, they could do that very easily by just creating a logging plug-in which observes events and farms off the ones that's interested in off to a TINCAN. So I mean, I don't know that much more about TINCAN, but it was certainly one of the considerations that went into the design of the event system. Does anyone see Dan Marsden? Is he here? Yep, Dan Marsden is here. So perhaps he can answer if there's anything going into SCORM, maybe some from the Google Summer of Code work. If anyone's got any news about LTI or SCORM, please feel free to type that into the text chat on devchat. Everyone's rushing to do that, I can tell. Yeah, well, so while that might be going on in the background, perhaps it's worth considering this final question, since the event system got overhauled in Moodle 2.7, what is the future of the messaging system and API? Well, at this stage, I don't think we're necessarily planning any changes to that system. It's worth perhaps tweaking a few usability parts of it, but I don't think the two systems are necessarily interlinked, that is the event system and the messaging system. I don't think there's any plan to make them the same. But it may be worth considering. I don't see that there's necessarily any advantage in merging them, but maybe there is. We're getting some feedback on LTI. So there's a potential upgrade from LTI 1.2 to LTI 2 coming in from Jason Harden there. Thanks, Jason. Just about the events and the messaging, each message is an event already. Just wanted to clarify that. I don't know if that's different to what people are expecting. Yeah. It always was. I mean, certainly the messaging system does do events, but I don't think it's the case that the messaging system will be based around the events API. It's got its own API. I haven't seen any improvements to the messaging pop-up. I wish there was. Is that really the case? Anyway, all right. Well, if there are any last questions that you have, please start typing them into text in the Dev Chat now. We'll hang on for a minute or two, and hopefully that will be enough for people to overcome the lag. And, well, anyone got any good jokes while we were in the meantime? An hour and a half is not so bad, I suppose, better than two hours. Thanks, Chris. Bit of chat about LTI still going on in the background. All right. Well, thanks to everyone who was involved in bringing us to this point and getting us to 2.7 in the state that it is. It's been a pretty serious piece of work. I think we can be more confident about this release than we have been in any previous release. There's more unit testing, automated functional testing, and there's been a heavier policing of various processes that we've been following. So yes, I think we're going to come out with the strongest version of Moodle ever. And it's all thanks to the hard work of everybody involved. So it's not just Moodle HQ. It never is always Moodle HQ. Most of the work that goes on happens outside of Moodle HQ. A lot of development goes on. But that's not the whole story. So thanks to everybody. And we really appreciate everybody showing up today. So hopefully 2.7 will be the release to make everybody happy and it will last them for as long as we need it, as long as they need it. Any last comments from anybody? I think you covered it well, Michael. Thanks, everyone. Have a good day or night. All right. I'll have a transcript and notes up and recording and everything up on this sometime tomorrow, hopefully. OK, thanks, everyone.