TPR7: There, I Fixed It: Leveraging WordPress to Build a Web Application on the Cheap

Glenn Rice: My name is Glenn Rice. I work at the University of Missouri in the Division of IT mostly building websites.

This morning I'm here to talk to you about how to use a relatively cheap or free tool, in this case WordPress, which many of you are surely familiar with, to do something that normally would be fairly expensive or a lot of work to do, hence the title, 'Leveraging WordPress to Build a Web Application on the Cheap'.

Now, I don't know if any of you went to the GTFO presentation yesterday afternoon. The theme of that was all the different things you can do with WordPress, and I was a little sort of dismayed to see this in the program because I thought they were going to totally steal my thunder.

But I'm actually glad that they went ahead of me because they gave a really good introduction to some of the many things you can use WordPress for. And what I'd like to do today is show a more concrete or more detailed example... a case study, if you will... of a specific example of how you can use WordPress to build an application.

Some of the stuff may be fairly technical, and I'm going to gloss over a lot of it because, of course, we don't have a whole lot of time. But if you have questions about any of it, I'll be here the rest of the conference, and I'll put my contact details and of course the presentation will be available online. I'll also have links at the end of it.

And I don't have a clicker, so I'm going to be moving through this kind of slowly.

I'm assuming most of you know how to use WordPress and have some familiarity with the installation and the administration of it. Just real quickly, I'm going to go through how we develop this application.

This application essentially was a tool for reporting and distributing, I guess, or notifying people of events in our IT systems, events being things like outages, scheduled maintenance, intermittent or degraded service, the kind of thing that a lot of people need to know about at a university but that it's sometimes hard to get this information out. Our support people need to know about it; in many cases, they don't know about it until someone tells them, especially if it's not in their particular area.

There's also information on messages, sometimes when we bring services online or when there's changes to services, when you need to let a lot of people know about it fairly quickly.

So this is the purpose of the application. We call it a 'system status update' system. I guess I got 'system' in there twice.

We did have an application. I put that in quotes because it was very crude and really underpowered. Actually, it wasn't powered at all.

It had a lot of shortcomings. We could only have one announcement or update or notification at any given time. Basically it was an on-and-off system. We had a single message, just a Web page that people could go to and look at and see if anything was going on. It was more like a complaint-driven thing.

People would notice that their email wasn't working and they might remember to go to this page or not. There was really no interactivity there. No archive. Once a message went away, it went away forever. There was no notification of any kind. Access control was done by a very rudimentary... just an htpasswd-type system for our managers. And it really was insufficient for our needs. So we started looking at some of the other things we could do.

This was project-managed. I'll get to that in a minute. But we started out looking at some of the requirements of such a system. And we had some required and desired features.

We wanted to be able to categorize by service type. For instance, things like networking, email, PeopleSoft, a BlackBoard learning system, learning management, things like that. We wanted to be able to have multiple types of events based on severity, in most cases such as complete outages or degraded service, scheduled maintenance, that sort of thing.

We wanted to be able to allow clients, any user, to subscribe to RSS feeds for all updates or only for those in the specific areas of their interests. It needed to be easy to use for our managers and on-duty ops people. We wanted to be able to archive these messages and alerts even after they were resolved.

And above all, it needed to be inexpensive, because most universities were... like all of you I'm sure are aware, things are tight right now.

Then we had some desired features as well. These are not essential, but we really wanted these to be part of this system. We needed a stability in the event of network problems. In other words, if we have a system that's reporting on problems, we don't want it to be subject to the same sorts of problems.

Automatic email notifications. We wanted to be able to send notifications to different groups of people depending on what's the type of notification or the type of event we're talking about. And we needed to be able to integrate it with Active Directory so that we could use our single sign-on in this system so our managers could just log in with their SSO ID and get in like that.

We started looking, then, at some of the ways we could do this, and at this time we still had not even considered WordPress. Our traditional applications development would go to our apps development group. That's the first option here. We'd develop a new purpose-built, in-house-built application from our enterprise applications group.

A big problem with that is the enterprise apps group generally works on enterprise applications and they don't really have a whole lot of time for relatively small-scale applications like this. They're working on system-wide stuff and generally their wait time is measured in months, if not years, to just get on their list.

So really, from a practical perspective, although that would've probably been less expensive... I don't even know about less expensive. It was not practical for us to pursue that route. 

Another option would be to get an off-the-shelf, like a turnkey application from a vender and purchase, evaluate and deploy such an application. This was a possibility. We didn't discount it completely, but it would be more expensive and would tend to cut into our limited budget requirement.

The third option would be to use one of our existing purchase applications such as our CMS... we use Cascade... or SharePoint, God forbid, or Remedy ARS, which is our ticket, and bug tracking, and help desk ticket system, and use those, somehow adapt those, to do what we wanted to do.

And then the fourth option was to find an open-source application that almost does what we need and then add the remaining requirements of our system.

And at this point, I started looking at our requirements and the things that we wanted to be able to do, and I started thinking, 'Well, there's something already out there that already does a lot of what we want.' And that's WordPress. And that's where we get to this.

Actually, one more slide about this. I did a survey of other institutions. I went and looked at probably about 20 different institutions, both in the Big 12 and elsewhere, to see how, when I could see what they were doing... in come cases it was password-protected or so forth... to figure out how they were handling the same sort of requirements, and did a bit of a survey, did a little bit of a grid here, a matrix, looked at the level of detail, the granularity of their categorization, how detailed they wanted to be able to report on things, how they did their time reporting, that sort of stuff.

So I did a survey, and some others are using WordPress, some are using various other homemade tools, and some are using things like ColdFusion or whatever. And we also looked at the designs, and at this point we started gathering ideas about how we wanted ours to look.

But eventually, we did choose WordPress because it natively supports most of our required features. I've listed in the red bullets some of the features that I talked about a couple of slides back. And we decided that WordPress will handle natively, just right out of the box, so to speak, many of the things we wanted, and particularly the most important ones which were the categories, the RSS feeds, and the archiving. And then also because of its ability to take plugins and use custom code, we could relatively easily add the additional features that we wanted to.

So this is the genesis of the actual development project was to look at what WordPress already did in regard to the features we wanted and then decide how we needed to get the rest of the way to everything else that we wanted. And the primary selling point, I guess, for WordPress was that it's free.

Feel free to jump in at any moment with questions, by the way. I'll have a little bit of time at the end.

I'm not really going to go through every point on this. I actually had taken this slide out, but I put it back in after yesterday's presentation by Dan Frommelt, which really does underscore the need to project-manage things like this. This is a one-off project. It's not routine maintenance. We followed many of the steps that he outlined.

In this case, it was pretty important because, at our university, we don't support MySQL, and it was sort of an uphill battle to actually get this project done because our administration was like, 'Well, we don't support that, so we shouldn't build anything that uses it.' So I had to lobby for it essentially. And I think that in the future, we're looking at starting to support MySQL for developers across campus, thanks in part to the success of this application. So that's something else positive that's come out of it.

I'm going to talk a little bit about development. I'm not going to hit every single one of these points. We don't need to talk about installing WordPress. This is the famous five-minute installation. We all know about this. And testing, I don't really need to talk about. I'm going to talk more about the details of how we implemented some of our desired features via plugin some custom code.

OK. The categories, pretty simple. We just used the built-in category taxonomy that's been part of WordPress since pretty much the beginning. Our taxonomy, we divided into types of systems, and also our business units, which are our four campuses, and system level.

So we have about 20 different service categories, things like email, PeopleSoft. There's also things like Web hosting, Communicator, and some other more obscure stuff that you won't recognize because it's on our campus only. But a lot of enterprise stuff.

The most heavily used categories are going to be email and the networking and PeopleSoft, so I listed them here. But about 20 in all, some of them we haven't even used yet.

The great thing about WordPress categories is they provide built-in RSS functionality. So I'm going to flip over actually to our site.

So this is how it ended up looking. Of course, this is dev. Since I'm messing around with it this morning, I'm not going to use the live site. But our services over here, these are just like WordPress categories. This isn't really earth-shaking stuff here. So email. By going to these categories, we've got a page that has faculty staff, email status updates, and of course, you can see that there's the RSS feed. So you can subscribe only to faculty staff, email status updates, or if you just go to the main page, you can subscribe to all of them.

Again, nothing really very original here. This is something that comes right out of the box with WordPress. This is nothing new here.

But we did need to do some stuff that is not out of the box, and this is where custom fields came into play. For some of our other information for the event, severity, as I mentioned, outage versus intermittent versus scheduled maintenance, that sort of thing, we used custom fields for that.

Oh, and the status would be 'active' or 'resolved'. So an active event is something that's ongoing. It's a situation that's happening right then... the outage is still happening, the scheduled maintenance isn't finished, that sort of thing. Resolved would be when it's finished and can then be archived.

We use custom field capability. This is built into WordPress. WordPress 3.0 has some stuff that makes this actually already obsolete, and I'll talk about that in a little bit.

In order to put in the event type and status, we use two different custom fields. Custom fields enable you to add additional... it's like a taxonomy but it actually can be used for almost anything.

You have to define and insert custom fields, and there are plugins that make this sort of thing easier to do. And I'll show you them in a minute.

The three plugins I'm using here. Custom field template will add custom fields in the UI, in the 'edit' and 'add post' sections to the admin area. Get custom field values provides functions to use custom fields easily within your theme files. And the custom field search will put an advanced search form which lets you look through the custom fields.

And the other thing is, on our front page, we wanted to show only active alerts. So you go to that page, you only see anything that is actively going on at that time. So much of the time it's actually got an empty page that says 'There's nothing going on right now. All systems go'. The archive contains all of our resolved events.

And the way that we can filter on the index page is simply the query post. You can add parameters to the query post in your index.php that says 'meta key' and you have the name of the custom field, and then you give the value that you want to filter on, and it will show only, in this case, posts with an event status field that has the value of active. So that's how you can use that to filter. There's other ways to filter with query post, but that's what we use here.

Oh, here's a thing. I don't know how well you can see that, but what we've got up top is... actually both of these are within the admin area. 

You can see some of our categories over here where it says 'event summary'. This box with status and type are added by these custom fields plugin. And the same thing on the quick list, which is in the illustration below, it actually can show 'event status', 'event type', and then there's drop-down, so a manager can go in there easily when something is fixed and change it from 'active' to 'resolved' and just update, and they don't have to do anything else.

Oh, yes, this is another... The code at the top shows how we can use some of these functions that use custom fields within the loop. This shows a div with event meta data, and I've got a function in there which is exposed by one of these plugins, c2c get custom, and you give the field name and it gets the event type and it plugs it in the loop. So down below that shows part of the actual blog page and it lists the event type current status, and then the category, which is in this case the student email.

Functions that are created by plugins can be used, then, to just add in custom fields or other data into the loop so they appear on your archive pages or your index page or wherever you want them to appear. It's very convenient.

The email notifications. This was a desired feature, and it was actually tricky to implement. The main problem in our case was that our iron port was very picky about the reply-to address and the return path, and there's a bunch of email headers that had to exactly match correctly in order to get these emails allowed to go through. I mean, our system's pretty picky. We had to white-list some stuff.

But that's really more of an administrative issue. You can deal with that. It just was a little tricky to get that set up and working right.

As far as how it actually works, this plugin allows you to apply an email address to all posts or to posts within a specified category. So what we did was we would set up DLs for, say, the networking support group, and then anytime an update was added to the networking category, notification would go out to that DL. And we used the DL alias as the address within post notification.

So, very convenient. Again, a little had to be tweaked somewhat to get it to work. And here's what it looks like. Boy, that's really hard to read. 

Up at the top, this is in the WordPress admin area on the edit post page. It says, "Send notification after publishing." There's 'yes', 'no' or 'add it to the queue'.

And then below is an example of the email that it produces, in this case PeopleSoft HR problems that gives the event details, types that status affected services and units, and it's got the message up at the top and a link to the actual post page, although this is really all the information. They don't even need to go there. So that's produced by this post notification plugin. Very, very useful plugin.

The authentication part. I mentioned this on Twitter, actually. We use the plugin called wpDirAuth, and it provides directory authentication for WordPress using LDAP and LDAP Secure.

There's several of these plugins available that are LDAP-related authentication plugins. We tried several of them and, really, it's kind of a 'Ford or Chevy decision' on that. It's whatever works for you.

In this case, I went with this one mainly because it's now maintained by Paul Gilzow, who, if any of you have been here before, he's won Best in Conference Presentation two years ago. Anyway, that's a shout-out to Paul. He's not here this time, unfortunately.

The way this works is we created a new Active Directory security group with the names... all the members were our managers who we wanted to allow access to this system, so we probably had about 15, 20 different managers in different areas. And we created a security group in Active Directory and then used the name of this security group within the plugin.

So the way it works is they would log in using their single sign-on, there's a call to LDAP using TLS, I think, and if it authenticates, then fine. Well, first, it checks their ID and checks if they're in the system, and then it also checks them against membership in the security group. And if either of these things fail, then it goes back to the local database, the WordPress database, and sees if the user is entered there. That's how we can include the administrator user. They're not in Active Directory, but they are in WordPress so they can still log in as admin. In fact, it's required, actually, to have an admin user.

Again, I had to tweak that quite a bit to get it to work right, mainly for reasons of security. But eventually we got it working fine. And I don't think I have a slide for that, but I can show that to you later if you like.

Some other modifications. We had problems initially with managers when we were doing testing. They were making type a different font or a different color or a different size.

Shelley Keith talked about this in her workshop on Sunday. Sometimes you need to control what your users are actually allowed to do. In this case, I used the same solution that she did, Tiny MCE Advanced, to plug in. It allows you to customize the WYSIWYG editor and remove things that you don't want people to use.

I find it easier, than telling people not to use something, to just take away their ability to do it. That way, there's no questions asked. If they don't know that they're able to change font size or they don't see a button for it, they'll never be tempted to do it, things like block quotes and even images.

Another add-on here was something called Post Snippets. This is very convenient. Because of the nature of this application, much of the wording of these different updates is very similar. It's almost always 'The such-and-such system is offline for maintenance and will be back on such-and-such a date'. Boilerplate text. It's always the same.

This plugin enables us to create templates for those commonly used expressions that are spelled correctly and have good grammar so that we don't have to worry about... for one thing, our managers don't have to type it in every time, and for another thing, it makes it easier to enforce our editorial style and correct spelling and that kind of stuff and maintain consistency in our reporting.

A couple of other things. Custom code. The functions.php file, which is in every theme an extremely useful file. You can modify WordPress behavior in the functions.php very easily just by adding stuff to it.

In our case, we used it to, among many other things, hide functions on the admin side of WordPress that we didn't want our managers seeing or using, such as commenting. We didn't use commenting on this at all, so we basically hid anything that had to do with commenting from our managers, things like trackbacks, blog-related stuff that we really didn't want to use.

So I used custom code to hide that. In WordPress 3.0, you can use custom post types to do similar type functions. You can create a custom post type and, in that post type, hide capabilities for commenting, that sort of stuff. I haven't implemented that yet; I plan to.

Menus, I'm not going to really talk about that.

OK, here's an example of Tiny MCEs. Tiny MCE buttons arrangement. Tiny MCE Advanced is the name of the plugin. And it's hard to see those bars, but basically those gray bars represent the rows of buttons within the WYSIWYG editor. And you can simply drag and drop.

In our case, I didn't want to use any of the alignments or outdents or indents, images, font family, font size. So those that are at the bottom, you can drag them up to the top and you can see the bottom image shows the result on the editor. There's only one row of buttons, the kitchen sink, completely gone.

All I'm giving them the opportunity to use is bold, italic, underline, lists, and links basically, and spellcheck. So we're taking away the temptation to hang ornaments from the Christmas tree, so to speak.

The Post Snippets. Again, gosh... I'm really sorry about the small image. The Post Snippets. This is the plugin for adding boilerplate, our templated text. At the top is the plugin set-up. You've got the title and the variables... in many cases, just one variable. And the snippet includes a token.

So here's the text, 'Advisory Service' and this is the token for the service variable. 'Is currently unavailable. Technicians are working to resolve the issue'. You edit the text in here. Make sure it's how you want it. And then down here is where you are actually editing the post. And you click the button. It's actually this little button over here that appears in the toolbar. And you've got a set of options here that correspond with the different snippets you have, and in this case, 'intermittent'.

And I put in email, and then you insert it, and it just sticks it right into the editor with the correct spelling and it replaces the variable token with whatever you've selected as your service. So it plugs it in with the correct spelling and the standardized text.

Very convenient for this sort of thing where you've got a fairly limited group of messages or post text blocks that you're going to use a lot. It worked out quite well for us.

And then... this is not so much WordPress. This is actually related to how we notify people or how we expose this information to other services.  

I created several Web services or mini-Web apps to feed or make available structured data for external sites. These are just two small scripts that sit on the same servers as WordPress that will, when queried, load a portion of WordPress using WP... I can't remember now, but it will be on a later slide... load a portion of the WordPress core, therefore exposing the query post method. And there's two of them: one returns XML and one returns HTML.

And the XML is a very simplified schema. It's custom schema, basically. I've got updates as the root, and then for each update there is a node, and within each node we've got the title, machine-readable date, human-readable date, categories, status, type, description, and other stuff.

And then what you can do with something like that is just use XSLT on whatever page is requesting this information, and therefore style it.

The bottom shows this is on our email log-in splash page. So basically I'm taking the XML styling with XSLT, adding little icons for the event type unavailable versus whatever exclamation mark is. Intermittent, I think. And it styles it and inserts it into the page. Very basic stuff. You could probably also use this with any CMS that uses XSLT to style XML such as Cascade.

Oh, this shows an example of our IT homepage. And over here, this is another example. I believe this also uses XSLT. It goes and grabs the XML feed from the service, which pulls it straight out of the WordPress database, and it looks up all active updates, gets the XML back, uses XSLT to style it, and then just inserts it into the page. There's one PHP script on each end, plus an XSLT file to do the styling. Very basic stuff.

As far as the training and documentation, we did need to do some training. Although WordPress is very easy to use, we still needed to have a little bit of training.

Most of our managers had never used it. It's not very widespread yet on our campus. We don't use it so much for faculty pages or any of the other stuff that you guys were talking about yesterday. Yet. But I'm hoping that this application will actually open some eyes.

Since we didn't have that many managers, in most cases, just one-on-one demonstration, a walkthrough was all we needed, and just a quick cheat sheet that provided just a simple step-by-step, 'here's how you add and update', 'here's how you market resolve when it's done'.

And then I also created a 14-page documentation with screenshots and technical information for our other, more advanced users.

Deployment and use. I'm going to pretty much skip this. Basically, the point here was that we did locate it on two different campuses, mainly for emergency. If there's a problem at one, we could roll over to the other.

Just a little bit about future development. I mentioned WordPress 3.0. We actually are running WordPress 3.0 but I haven't yet updated the system to use some of the new WordPress 3.0 features. 

The most exciting one that has come up in our case is the custom taxonomies. This is where you can actually add new taxonomies. There are, I think, four in the old version of WordPress. There are four built-in taxonomies, including categories, which is hierarchical, and tags, which is non-hierarchical.

What you can do with custom taxonomies is add new either tag-like or category-like taxonomies of your own. So in this case, instead of using custom fields for our type and status, we could actually set them up as categories in such a way that it makes it much easier to then filter using native WordPress functions rather than using plugins or custom code. So easier searching and filtering and no need for additional plugins.

It's something that I'd really like to do. The main reason I haven't done it yet is that I would have to make changes in a lot of places at this point to get out of how we've done it before and into the new and easier way to do it.

We'd also like to integrate it with our change management system in a way that if we have scheduled maintenance, for instance, we could just click a button on our change management ticket and have it automatically put an entry for scheduled maintenance, and then maybe even close it out when it's done.

And then caching and optimization. This is very important and it's something that there's a need for to make this work a little faster. Especially with our Web services, with the XML feed, it has to load much of WordPress every time that feed is hit, so we'd like to optimize that. There's several ways. You can use APC. There are some caching plugins for WordPress. I have tinkered with those a little bit but so far haven't really gotten any to work yet the way we want it to.

Now, they told us before with our presentations, "They always like to hear about lessons learned." So I've got a couple slides in here for that.

Well, WordPress core features can really save you a lot of time and effort. And here's just a few of them.

Basically with WordPress, you have a fully developed application right out of the box that includes things like identity management, authentication, content management, the RSS feeds... very, very useful... database management and querying... that stuff alone really makes things a lot easier from a development perspective when you don't have to write a bunch of SQL statements and that sort of thing... security, and the ability to theme and customize.

Now, caveat is if you're developing an application that's not a straight blog, it won't do everything you want right out of the box. In most cases, you will at least require plugins, if not custom code.

Also, plugins can be badly coded. If you look closely at them, there's a lot of them that are kind of iffy. You need to review them before you actually use them. And in some cases, I've found it necessary to even go in and modify them.

Use plugins as a starting point or a way to help you get as far as you can towards your goals. But they're not going to get you all the way in most cases unless you've got something very simple. Use custom code, theme functions and editing plugins to extend WordPress capabilities.

I would say that WordPress' native functions, plus add-on plugin functions, got us about 75% or 80% of the way to our desired goals. But the rest was all custom code.

And the converse of that is WordPress will probably do more than you want right out of the box. And by 'more than you want' I mean it's got a lot of features that are centered around blogging. Now WordPress 3.0 has somewhat moved away from the blogging paradigm and you can get around that a little bit with custom post types, but it's still a fairly heavyweight application and it can cause memory and CPU issues.

WP-blog-header is the include that you use to bring in WordPress functionality into other applications, but it actually loads most of the WordPress core and can really slow things down sometimes.

Some WordPress blog-related features you're not even ever going to use. So that's one thing. You've got to think about that. You don't want to build an application that has almost nothing to do with WordPress' core just so you can use a couple of the features.

And that is that. I do have a slide after this with links to all these plugins, but I'm happy to talk about any of the code we used, and like I said, feel free to contact me afterwards if you want to get any more specifics.

Thanks for listening. Any questions? Yeah.

Audience 1: Are most of the entries that you're making, then, are those posts or pages?

Glenn Rice: They're posts. They're all posts. We do have a couple pages that are mainly for help. We've got a help page and then we've got a feed page. These are mostly information and it explains how to subscribe to feeds.

The updates are all done with posts. You can actually use a future date for publishing and do scheduled publishing. You can put it in and mark it in as scheduled publishing. Now, I'm not sure how exactly that works with the cron. There is a cron feature in WordPress, but it's based on people... it's triggered by people hitting the blog. So you can't always depend on that.

But, yes, you can schedule maintenance, you could schedule the post or the update to appear at a certain time so it doesn't have to be up for a week. Now, this is more of an administrative question. Do we want to have something...

Audience 1: ... you guys are doing it. Like you've got something coming up Friday, you would post that... have date and time on there?

Glenn Rice: Yeah, yeah. And then mark it 'resolved' when it's done. But, yeah, we could do it to where it only appears during the maintenance window, and I don't think that's really being done right now. But it could be.

Audience 2: [40:09 Unintelligible]

Glenn Rice: Our main university site? No, not yet. But, again, we could very easily do that using the structured data feeds that we're talking about.

A lot of this information is fairly technical. And our university's main site, it's a marketing tool. I guess they don't want people seeing that our email's down, so maybe it's more of a political question than anything.

Technically, there is nothing stopping it. The main site is on Cascade CMS, so it actually already has the capability of taking that XML stream and doing something with it. I don't think they really want to yet. This is also new, so they may just be waiting. I doubt that they'll use it, though.

Yeah.

Audience 1: Any integration with Twitter at all?

Glenn Rice: Oh, no. Not yet.

Audience 1: ... email updates?

Glenn Rice: Yeah.

Audience 1: [41:03 Unintelligible]

Glenn Rice: I tell you, I use Twitter plugins on other WordPress sites, freelance stuff that I do, and there are many Twitter-related plugins that can automatically tweet an update. I'm sure that it could be easily done; we just don't do it.

Yeah.

Audience 3: Do you plan to migrate, use post to [41:27 Unintelligible]?

Glenn Rice: Oh, yes, I'd like to. The custom post type, an example would be just call it 'updates'. And how to do that? Well, I mean, I'm going to work on it on dev and there may be...

In that case, I'll probably end up just going on using a database client tool, just going right in the database and just changing in the post type column, just changing all those from post to whatever the custom type is. So set up the type in WordPress settings, then go into the database with PHP, my admin, or something like that, and change all of those.

Anyone else? I think we're about done.

Audience 1: Is your main... the site for this then that we're looking at here?

Glenn Rice: Yeah.

Audience 1: Is that open to the world, then, or do you require...

Glenn Rice: It is open to the world. We're just looking at the dev version. If you look at status.missouri.edu...

Audience 1: Would you require a campus log-in for people to go and see what your statuses are?

Glenn Rice: No. No, no, no. We thought about that, but we have... And we also have things we can do with the network that allow only people that are within the domain to look at it. We could do that stuff, but it's not... There's no security-level information here, no Social Security Numbers or student IDs or anything, so we don't worry about that.

Anyone else?

OK. Well, thanks. Thank you.

[Applause]