Transcription

ELLIOT TAYLOR:  Good morning everyone on second day of WordCamp London, did everyone have a good time at the party, stay up late, look at the enthusiasm!!  Some announcements to make, the acoustics are way better at the front, anyone at the back move forward you will have a much better audio experience, Happiness Bar open at 11.50, do go and ask questions, any question is a good question, don’t feel intimidated at all, go over there and have, have fun at the Happiness Bar.

The other important thing to note is the luggage is open for another ten minutes, you can then pick up your luggage between 3 and 5.  So, if you have got big bags on you, now is the time to head downstairs, once you come in the building it’s on your left.

I would also like to thank our sponsors, just to get the sponsors lined up here, box sponsors, Timpani, WooCommerce and JETPACK, HeartInternet, SiteGround, 34sP, GoDaddy and our dress circle, ground circle sponsors, the guys are around downstairs, do say hello, do take part in their competitions and take their swag, they do appreciate it they help make WordCamps happen.

We have two talks in the morning, the first talk of the day is by John Blackbourn, John has been working in WordPress for over 12 years and –

JOHN BLACKBOURN:  Something like that.

ELLIOT TAYLOR:  Something like that!  You have your lapel mic.  I’ll hand over to John now, thank you John.

JOHN BLACKBOURN:  Morning everyone, you are all raring to go after the after party.

Okay, can I switch over to the slides.

Morning my name is John Blackbourn, I’m one of the WordPress Core development team members, I’ve been working with WordPress for something like, yeah, 12 years maybe, sounds like quite a long time in web development.  I’m senior engineer at HumanMade, a WordPress development agency over here in UK, follow me on Twitter, I’m on there as @johnbillion.

So, I don’t have to say the word capability right every time, I’m going to say roles and caps, not the caps you wear on your head, that just saves me trying to get all the syllables in order.

I’m going to start by talking about the roles and capabilities in WordPress, then some technical detail about the API, hopefully most of you are aware of the default roles, administer role, author contributor and subscriber.

There are also two kind of pseudo roles that we have got in WordPress, one is Super Admin role, active when you are using WordPress Multisite, a Super Admin role is not actually a role, it’s a flag that gets set against the user account, the user meta field when you have got the flag on your account, what happens is that effectively means that all the capability checks in WordPress are completely by-passed, because a Super Admin can do anything on any site, right across the network, so Super Admin isn’t actually a role, it skips a lot of the capability system.

You can also actually have no role in WordPress, it doesn’t sound like something that is very useful, it can be handy for example, if you want to remove the user from your set without actually removing them.  You can do that from the user editing screen in WordPress, there is an option to click no user for the site, the user will be able to stay on the site, they won’t be able to do anything, the only thing they can do is login, they can edit their own profile but not the rest of the admin area.

Although they may seem it roles in WordPress aren’t actually hierarchical, this is the role and capability page on the WordPress codex, the default roles in WordPress they appear hierarchical, for the most part they are hierarchical from a technical point of view the roles and capabilities offer the API there is no hierarchy, it’s important to remember that.

I would like you to think of roles, capabilities and responsibilities.  What are the responsibilities of each of the roles in WordPress.

So, an administrator, the administrator has the responsibility of admin string the whole site.  The editor, their responsibility is editing the whole of the content across the site.

An author, the responsibility is to author their own content, they can’t edit anyone else’s content.

Contributors responsibility is contributing proposed content for the site, because the contributor can’t publish content, then a subscriber won’t have really any responsibilities.

WordPress, the user, can actually have multiple roles, now it doesn’t make a lot of sense, for example, for a user to have both the editor and author role, it doesn’t make a lot of sense because the capabilities of an author are just a subset of the capabilities of an editor, it doesn’t really make sense.

We start to make sense of custom user roles, here we have a comment moderator role whose responsibility is to moderate comments and there may be an HR manager role and their responsibility is to manage users, these are two distinct responsibilities and actually you can see how it might make sense for a user to have both of these roles at the same time on the same site, so they can moderate comments and manage users.

Let’s take a look at this, the example in a real plugin.

So bbPress is a forum, a discussion forum plugin for WordPress, it actually runs the WordPress.org support forums.  It provides some custom roles in the plugin.

So, the keymaster roles have the responsibility of managing the whole of the forums, it’s kind of like an administrator role but it’s, you know, it’s controlled just to the forums.

There is a moderator role and the role of the moderator is to moderate the discussion within the forums.

Then participant role, it’s given to anyone participating in the discussion on the site, replying to topics things like that.

Spectator role will, the spectator doesn’t really have any responsibilities either, you just get that role of you subscribe to a topic when you login.

bbPress enabled on our site we can kind of see how a user can have both the role of an author, so they can publish their own content and manage their own content, but also the role of a forum moderator so they can moderate the discussion on the forum.  So, it makes a lot more sense for a user to have both these roles at the same time.

You know, they are two completely distinct responsibilities.

You can do this in bbPress, this is the user editor screen if you have got bbPress, it’s a nice way of kind of separating the fact that these are the regular editorial roles in WordPress and these are the forum roles.  So, you can choose author, as the editorial role, you can choose moderator as the forum role, and this makes it nice and easy to manage because by default in WordPress there isn’t actually a UI for assigning multiple roles to a user, by default you just get this drop down so you can choose one for them, programmatically it’s entirely possible for a user to have multiple role.  There is also a plug-in, called members, this is a really good plugin for user capability roles and access on-site.  This overrides the false drop down menu on the user editor screen on WordPress, it turns in to check boxes instead of just a single select box, so you can easily assign, for example here, this user is both an author and events manager so they can publish their own posts and also the event list things on the site.

You can see as we start to introduce roles that have much more granular responsibilities it makes more sense to allow the user to have multiple roles at the same time.

So that’s roles, capabilities and responsibilities.

Let’s take a look at capabilities, most of you are probably family with the current user can, function, edit posts, manage options, upload files, fairly simple stuff, there is also a function called user can, it acts just like current user can it takes a user idea, the first parameter, you can use this ‘user can’ function if you want to check the capabilities of a user who isn’t currently a logged in user.

Don’t do this.  So, I’ve just talked about responsibilities of a user.  If you check for a role using this, the ‘current user can’, it’s not actually 100% reliable, it just happens to work, when you actually do this it performs a nasty regular expression check on the capabilities array of the user in the table.  So, most of the time it works but it’s kind of more luck than anything else, if you start introducing custom roles or capabilities on your site, there is a chance that this will break completely.

So, you should try to check capabilities, because as we’ve just found out, having user roles with distinct responsibilities means that you no longer care about the role as much, you really care about the capabilities of users who have that role.

In addition to this checking for roles actually breaks completely when it comes to Super Admin, a Super Admin, on WordPress Multisite can have access to everything right across the whole network, they might not actually have the administer role on any given site if you are checking for the administer role and Super Admin comes along it’s not going to work, don’t check for roles, check for capabilities.

A quick bit of history here, before WordPress 2.0, 11 years ago or something like that, WordPress actually just had a hierarchical user level system, it wasn’t very flexible because you know, you didn’t have this nice granular control over capabilities and things, so if you see mention of user levels in WordPress, then it’s referring to a really, really out of date system from 11 years ago, if you are still checking for user levels you are doing it wrong and you have been doing it wrong for the last 11 years.

Then of course, because WordPress is so committed to backwards compatibility, this does actually still work, it will just throw up like a doing it wrong warning.

So, let’s say you want to determine whether a user can edit a post.  This is fairly standard stuff, we do current user can, edit post and the post ID.  This capability here, this doesn’t actually exist, no user and no user role in WordPress actually has the edit post capability, the singular form of this capability.  So, how does this work?  Well, this is called a meta capability.  Meta capabilities map to primitive capabilities, which are actually assigned to users in user roles and it does this based on the context you are providing, in this case context is the post ID.

So, let’s see how this works.  Well, meta cap, map meta cap, I’m a huge geek and this is my favourite function in WordPress, it handles meta from edit post, it doesn’t exist and no user has this capability, it maps it to a primitive capability, such as edit others posts.

So, map meta cap is kind of a gatekeeper to your ability to actually do things in WordPress, it’s a really powerful function.

So, what happens inside this function?  So, we are going to do current user can, edit post, post ID.

The first things that happens is map meta cap checks to see if the post that you are trying to edit actually exists, if it doesn’t, what happens is this, this array here called caps, it’s an array of the required capabilities the required primitive capabilities that a user needs to actually perform the action of edit post.

A do not allow here, it’s a very special capability, it’s a capability that no user and no user role has in WordPress and it is a capability that no user can have.  So, if you want to deny the ability for a user to edit a post, because the post doesn’t exist, then we add do not allow, to the array of required capabilities for that capability check.  Which means that the user can’t perform that action.

So, this lump of code here, just because the post doesn’t exist it effectively runs a false or edit post, the post doesn’t exist, it prevents the user being able to edit a non-existent post.

Secondly map meta cap checks to see if the current user is the author of the post.  If they are then the actual required primitive capability to edit the post, becomes edit published posts.  This is the capability that editors have and administrators have and authors have, it’s the draft though, then you just need the regular edit posts capability.  Then it behaviours a little bit differently if you are trying to edit someone else’s posts than your own.

You require the edit others post, primitive capability, for trying to edit another user’s post.  Here’s where it gets a bit difference, an administrator or editor in WordPress has this capability and an author doesn’t, an author can only edit their own posts.  It means if an author is trying to edit someone else’s post they will not have the edit others post primitive capability and they won’t be able to edit that post.

In addition, if the post was published, then the user needs the edit published posts capability, so for example, a contributor doesn’t have this capability, so he can’t edit posts that have already been published.

If not — sorry, if it’s a private post they also need edit private posts.  Ooh, actually, I’ve just forgotten, I’m not sure which roles have this capability, administrators, editors have it, not sure about what… so what’s the result of this.

So, if we’re trying to edit another user’s published post, then the edit post meta capability, actually results in the user requiring the edit published posts and edit others posts primitive capabilities.

If you are trying to edit your own draft post then it just maps to edit posts.  So that’s map meta cap.  Map meta cap doesn’t just deal with posts is deals with anything you throat, it here we’re going to delete the user with a user ID.  If we have WordPress multi-site enabled, if you’re a regular administrator you can’t delete users you need to be a super admin on WordPress multi-site to delete users.  If we’re using multi-site and the user is not a super admin then again we will add ‘do not allow’ to that array of required capabilities it will prevent that user from being able to delete another user.  If not, if we’re on a regular single site then the required capability becomes delete users, and that capability is usually just granted to administrators on single site WordPress.

So that’s map meta cap.  Meta capabilities, typically they are not ever assigned to user roles or users typically they come in the single form such as edit primitive capabilities are assigned to users and user roles.  The best thing about this map meta cap function is the last line in it there’s a filter on the end of it called map meta cap, this opens up a whole world of possibilities you can basically change pretty much everything about the way user access works in WordPress, through this filter.  It’s really, really powerful.  It’s probably the most powerful filter in WordPress.

It parses the array of required capabilities for the current capability check, the capability that you are actually checking such as edit post, parses the user ID and whichever arguments have a provided such as the post ID or user ID.  Let’s take a look and see what we can do with the this.  Hopefully you can see this ok we’re adding a filter to map meta cap, we have got our callback function here so in this case if delete term is the capability that is being checked, what we can do is do something such as preventing a protected term from being deleted.  So we’ll look at the term metadata if there’s a protected flag on, it you know through some plugin we have written, then again we’re going to ad this special do not allow capability to the required capabilities.  What that means is a user can no longer delete this protected term, but the advantage of this it means this is all we need to do to prevent that term from being deleted.  We don’t need to deal with hiding edit links in the admin area, we don’t need to override form handlers or link handlers, we don’t need to worry about any of that we just need to deny the user the capability of editing or deleting that term through the map meta cap filter, and all of the user interface in WordPress is handled for us because throughout the admin area in WordPress there are lots of calls to current user can delete term before it actually happens.  So you don’t need to hide things with CSS.  You just use this.

Then right at the bottom don’t forget to return your required caps because if you don’t, suddenly, everyone on your entire site can do everything and that’s not, probably not desirable.

Second example here, again just a call back on the map meta cap filter, we’re going to introduce some lady luck into the WordPress admin area so there’s a roll of a virtual dice here, if it lands on three or rather if it doesn’t land on three then again we’re going to add this do not allow capability to required caps.  So if the user is, not having much luck and doesn’t land on three, sorry, you can’t publish your post (laughter) try again.

Probably drive the users a bit crazy, and again just return the required caps.  Again we can have a lot of control over the ability of WordPress users to do things through, you know a hand full of lines of code.

By the way if the user does roll a virtual three here we have not got any handling, just means it falls back to the regular primitive capabilities in WordPress.

For this filter can actually be used to grant capabilities and not just take them away.  Typically you will be adding the do not allow to deny capabilities but you can add capabilities as well.  A contributor user in WordPress, although they can submit posts they can write draft posts and submit them for review, they can’t actually upload files.  Sometimes that a bit awkward if they want to put images or files in their article they can’t do it natively through WordPress.  We can hook into map meta cap if the upload files is the capability we’re checking we can actually override the complete required capabilities array instead of just adding an element to it, we’ll override it completely with edit posts.  This means that any user who has got the edit posts capability can now also upload files it means contributors can upload files because they have got the edit posts capability.

So this is actually a fairly common thing you see quite often people ask in support forums how can they allow contributor to upload files, this is probably the safest way to do it and best way to do it.

So, the map meta cap very powerful filter it can be used to alter the required caps for an action at run time, but there’s another filter that is just as powerful called user has cap.  With this filter we can control whether or not the user actually has the required capabilities for an action, so with map meta cap we’re determining which capabilities are required, with user has cap we’re determining whether or not the user actually has those capabilities and D capabilities that have been mapped in map meta cap.  I have got a plugin called user switching which allows you to instantly switch between user accounts in WordPress, and the capability check I use there is switch to user.  So if the current user can’t switch to a given user ID I just do a wp die in there.  How this works in user switch plugin I use the user has cap filter here if the switch to user is the current capability we’re checking, my clicker is going a bit wonky … then what we can do here is grant the switch to user capability based on whether or not the user can edit the user that they are attempting to switch to, so if user switching you have to have the capability to edit the user if you’re trying to switch to user in addition to that you can’t switch to your own user account, so these arguments here this the current user ID the parameter you have parsed in, if you are trying to switch to yourself it denies it.  This logic here all ends up in the switch to user element of the user caps array.  This is how you grant or deny an actual capability to the user.  Map meta cap users filter to alter the required capabilities for an action, in the user has cap filter to grant or deny the actual capability to user on the fly.  So if any of you know how roles and capabilities are stored in WordPress, is one of the few things that are actually stored in the database like custom post types and taxonomies these are all generated on the ply, roles and capabilities are actually stored in the database it’s one of the shortcomings of the role and capabilities API.  Using these filters, means that you get around those restrictions nicely, you don’t have to worry about updating options in the database and things like that.  Filters are always better idea.

So recap.  Roles including multiple roles, no roles, responsibilities and how they help you define any custom roles you might want to add to your site.  Meta capabilities how they map to primitive capabilities that are actual lie signed to meta roles, map meta cap and user cap filters.  Just going to close out with a bit of trivia about the roles and capabilities API.  So non-logged in users if you are using a current user can function you might expect if a user is not logged in this would kind of short circuit the checks and return false if the user is not logged in surely they shouldn’t be able to do anything.  It’s not actually the case, although this some code in there that looks like it should be doing that it doesn’t.  This actually always returns true.  Current user can, exists.  So, exist is another special capability in WordPress.  So where we have the do not allow capability that is not assigned to any user or role and cannot be, the exist capability has special handling and it’s always is assigned to any user even if the user is not log in.  Sounds like it doesn’t make much sense, and actually the doesn’t make much sense (laughter) but that’s how it is.  What it means I buddy press plugin actually makes use of this functionality through some hacky code.  If you front-end code if you put the admin area aside for a minute and you add a bunch of functionality to front-end of you site, and you want to know where the user is logged in your use current user can exist it will return true for anyone who hits your site so you always need to ad an is user logged in check as overwhelm.  Otherwise you are potentially making some functionality available to non-locked logged in users when they shouldn’t have that functionality.  We did look at changing that to remove the functionality for non-logged in users it just broke BuddyPress and another bunch of plugins that relied on it.  There’s a bit of forward at the moment introduce slight more granular capability controls in WordPress core and the moment you can do something like edit user with the user ID and delete user with the user ID, but you can’t do that for things like plugins.  So with plugins you just have the edit plugins the plural form, you can’t do edit plugin with the plugin name and activate plugin.  Hopefully in WordPress 4.8 a lot more of these granular capabilities will introduced.  Look for them.  Also the same for themes and widgets, we’re making a lot more of this more granular so you had a lot more control over the granularity of capabilities.  If you are interested in the difference between, or rather if you – I will say that again if you are interested in the primitive capabilities that users and user roles have in WordPress there’s a class called test user capabilities that in the WordPress unit test street it has a great big array like this and lists all the primitive capabilities in WordPress at which roles have capabilities, it does it for the meta capabilities that are used in core as well as the primitive capabilities.  So, so the roles and capabilities page on the codex sometimes get a bit out of date, if you’re if you really need some good control over that go and have a look at this class and it’s got it all in there, and this test class ensures that all the different capability function in WordPress works as expected and we’re not accidentally granting capabilities to user roles who it shouldn’t have it.  That’s it from me.  Any questions?  Have we got yeah there’s a lady just here.

FROM THE FLOOR:  Hi, great presentation thank you.  Is it ok to remove the native roles if you’re not going to use them, such as editor, contributor?

JOHN BLACKBOURN:  Sure yes you can remove a role in WordPress, there’s nothing like fundamentally in WordPress that is tied to the roles, specifically.  You know everything is done through the capability checks that the user roles has.

Maybe if you remove the administrator role, I can’t think of anything off the top of my head… if you do remove all the roles there, there is a setting screen which specifies the role that new users get assigned, by default, if you have user registration on your site and users are signing up by default they will get the curb role you need to make sure you plate that with an appropriate role, if you remove all the default ones, I’m 99% sure you can delete the default roles in WordPress and replace them with your own and be good to go

FROM THE FLOOR:  Will your slides be available?

JOHN BLACKBOURN:  I will put them on-line, on slide deck or something right after this and tweet the link, I’ll tweet the link out and also links to a couple of other presentations about the roles and capabilities.  Any other questions.  Rob at the front here.  Go easy on me Rob!

FROM THE FLOOR:  All right, it’s just is there a plan to get rid of the database requirement?

JOHN BLACKBOURN:  Kind of.

FROM THE FLOOR:  I basically run into that issue.

JOHN BLACKBOURN:  So maybe one of the old architected parts of WordPress, roles and capabilities are stored in the database, there is probably someone somewhere with a plan to change that, off the top of my head I’m not sure if anyone is actively working on it there is a lot to consider there, you don’t want to break custom users’ capabilities.  Interesting thing you may not know actually, you can assign a capability directly to a user as well as a user’s role, where we are saying about an editor, being able to edit people’s posts you can actually sign that directly to an individual user not just a role, so there are considerations there as well in the database.

ELLIOT TAYLOR:  Did I see a hand?

FROM THE FLOOR:  Just a follow-up to the question the lady asked before about deleting the basic roles in core WordPress you shouldn’t have a problem at all, it’s worth noting that some plugins do actually check current user can role, instead of a particular capability, so some plugins might break without a standard role, because they have been written wrong it would be great that we could all write them right, that’s not the case, it’s just something to bear in mind, I’ve been caught by that, a plug-in checked for a role that I didn’t write because I didn’t need it and a plug-in stopped working.

JOHN BLACKBOURN:  That’s a good point, if you have wp debug enabled you should see a ‘doing it wrong’ warning come up, when you activate a plug-in like that and it checks for a role instead of a capability, you should get a php notice come up.  Yep.  Over there.

FROM THE FLOOR:  When you have custom post types and custom taxonomy in your site, it’s a good way to have like, like five or four custom post types and different kinds of people edit different kinds of stuff in the site, do you, like map it when you register those custom posts or when do you do it?

JOHN BLACKBOURN:  It depends how much granular control you need over the post types.  So, quite often information reality you might find when you build client sites the client will ask for all these different kinds of levels of control over post types and taxonomy, quite often there are three people who manage everybody and quite often that granular control isn’t needed, things about the responsibilities, if you think about a custom post called events, you could think of a role called events manager and that role can only edit the events post type and the same thing for other post types and taxonomies that you have got, you can use custom code or something like the members’ plugin by Justin Tadlock to assign multiple roles to a user who does need to access all the post types.  I really like thinking about this idea of responsibilities, not just what can a user access but what is their responsibility, this person is responsible for managing events, this person is responsible for managing a video post type.  Maybe think about building up some small roles like that, some, you know, targeted roles and then assigning multiple roles to the user, yep.  Chap just here.

FROM THE FLOOR:  Hi, I always use, well I usual use when a plug-in is activated to add capabilities and add roles and stuff, is there a way you can do it with a theme, or should you not do it with a theme?  Can you, or should you not?

JOHN BLACKBOURN:  Yeah you can do it with a theme.

FROM THE FLOOR:  So what would be the right hook for that?

JOHN BLACKBOURN:  Yeah, so… so for plug-ins you have got the plugin activation hook and you can use that to add your custom roles or custom capabilities, it’s not actually 100% reliable because, well for example, wpCLI, had a bug where the activation hook wasn’t fired, a better way to approach it, which applies to plugins and themes, is to have what’s called an upgrade routine, so you have some code that hooks into something like admin ini, so ini files on the admin screens it looks for the version number in the database corresponds to the plug anyone, plugin one you introduce some roles, you have a new version you can have an upgrade routine that looks for a version number in the database if it’s lower than the current version number you can run the upgrade and add a remove roles and capabilities, at the end of that you update that in the database with the new plugin or version number.  So, that means that you haven’t got to worry about the activation hooks because, you are probably asking because themes don’t have activation hooks, so having a kind of upgrade routine is actually quite a common pattern in upgrades and themes these days, I’ll find a good example and tweet out a link so you can have a look at that.  Yeah.

FROM THE FLOOR:  Just one more, quick one again following on from the previous question, the other time that, the activation hooks aren’t called is on Multisite when you are network activated, so as you create new sites all the plugins are instantly activated but the activation hooks aren’t called, so it’s always best to look at something that checking a version number, checking an installation flag.

JOHN BLACKBOURN:  Yeah, great point, network activated plug-ins don’t get the activation hook.

FROM THE FLOOR:  Hi, not particularly practical question maybe, but I’m just wondering what the original use of the exist capability was and if it still has a particularly good use case then?

JOHN BLACKBOURN:  Yeah… umm… so, unless Mike wants to correct me again, because you probably know a bit more, you were around then, there is actually some code in the function, I don’t know, let’s see if we can take a look at this.  Umm… what are we looking at… current user can… can’t see that… okay.  So, I don’t know if you can see this very well, this is the current user can function and there is this piece of code here that populates the current user, wp get current user and then it does actually returns false if current user is empty, it looks on the surface like it should return false if we haven’t got a user, but since the day that this slide of code was introduced, it doesn’t actually work as intended — [Laughter] — the code when you call wp get current user it will always return a wp user object even if the user isn’t logged in, it will be a wp user with no attributes, an ID of zero, this variable will never be empty it will have an empty wp user object in it, but the actual variable won’t be empty, so this line of code doesn’t do anything.  So, it’s most likely that, that the exists capability was introduced, so you can do current user can exist to see if they were logged in, but it was buggy from the day it was introduced.

As I said BuddyPress and probably a few other plugins too make use of it through some funky — I can’t remember off the top of my head, but there are a hand full of plugins that make use of that weird piece of behaviour, yeah.

Felix…

ELLIOT TAYLOR:  I’m afraid this will have to be the last question.

JOHN BLACKBOURN:  Okay, last question and then we are time up.  Felix now.

FROM THE FLOOR:  Related a bit to Robert’s question from before, so I know that there is, there is a way to programmatically define roles, like wp user roles global, then I think you can’t add roles through the function, do you have any background why that exists, why that’s not writable for plugins, for example.

JOHN BLACKBOURN:  Yeah, so there is a weird piece of functionality, I’ve not actually used it, so you can — I’m not sure of the exact name, I think it might be wp user roles, you can specific a global array called wp user roles, in it you can have a key that defines the roles and the values that define the capabilities of those roles.  If you have got that in place, then all of the kind of pluggable user roles and capabilities kind of get over ridden although the map meta cap is there, the super global array you define just overrides everything, I think it was introduced for WordPress Multisite in order to have a kind of unified set of roles across all of the sites, there is similar functionality for super admins in WordPress as well, you can define super admins in a similar way.  I’ll have a look and see if I can find out, I’m pretty sure it was a Multisite functionality.  We’re out of time I think.

ELLIOT TAYLOR:  Thank you very much John, that’s a very good talk.  [Applause].  We’ll be back in fifteen minutes, we’ve gone a bit over, we’ll be back in fifteen minutes, for a talk on Agile, there are some T-shirts than graduate centre, if you haven’t got your T-shirts do head over there and pick one up.  See you in fifteen.