Transcript: Django Admin

In this episode, we're going to be talking about the Django admin, what it is and how to use it.

I'm Will Vincent and joined as always by Carlton Gibson.

Hi Carlton.

Hello, Will.

So let's get into it.

So maybe since you're the Django fellow, what's the history?

Why does Django have an this beautiful admin app that many other web frameworks do not have?

It predates my use of Django.

So I got into Django in the early days and it's always had the Angot the admin.

And the Ang, the admin was like this just the the hang the Angmin.

What's that?

The admin was all it's like Django admin squashed into one word.

The admin was always like this super killer feature.

It was like you so you define some model classes, and then with like about four lines of code, you had this beautiful um crud interface where you get a form, you could edit the instances, you could create things in the database.

It was just amazing.

So I I guess it's been there from the birth of Django.

And from the Lawrence World Journal, I guess the the story is they needed an interface for the back end or for the news team to be able to create news articles themselves.

And so the admin was born from that, I suppose.

And I think the thing is that now, because a lot of times people will ask, well, can I can I can or should I use the admin in that capacity going forward?

So let's say you built a newspaper site today.

And I would say you could, but you probably shouldn't.

So generally speaking, the admin is abused and asked to do too much.

And we'll talk about, you know, there is a point where you should just make your own custom pages.

But the admin is, you know, super helpful, I think, especially to beginners, because there's two ways to go in and do cred stuff.

You can go to the Django shell, which I think a lot of experienced Django developers maybe find faster.

Like a Python, you just command line, do you know exactly what you're doing.

Um but for beginners, having a graphical interface is fantastic.

And so I I always recommend people play around with the admin first rather than the shell, though eventually you'll you'll use both.

Like to be honest, and there's all these

you say beginners.

There isn't a single project that I work on where I don't create a model and then immediately create an admin for it.

And I may not use that admin for the whole life of the project because it the model might get too complicated or whatever.

But I always, when I'm creating a model, create an admin because it's so little work, and then you've got this interface.

And to be honest, yeah, I can go in the shell, but if I have to create a date time or something like that, it's much easier to use the you know, the little JavaScript gooey thing where I can select the date from the calendar picker than it is to import date time, date time, date time.

What was the format?

Wow uh yeah.

I mean, occasionally I'll use the shell if I'm feeling, you know, like I want to flex my developer muscles, but I almost always use the admin.

So that's so that's the first thing to mention.

So if you're brand new to Django, uh there's an admin.py file that is created whenever you run start app command to create a new app.

And with three or four lines of code, it's in the docs.

We'll link to it.

So in the same way, you have to add the apps to the installed app setting and settings.py file.

If you want them in the admin, which you do, you should add them to the admin.py file.

And then you can do lots of stuff from there.

There's lots of ways you can customize it.

Um, I was just looking through last night.

I mean, the docs per usual cover it all, but it's just an overwhelming amount of stuff.

So at every almost at every point in the history of Django, it seems, um, somebody's come along with a good idea to say, oh, let's add this model option to you know, this option to model admin.

And it's been added and it's been added and it's been added until it's overwhelming.

And, you know, I'm very much of the opinion that we we need a kind of a moratorium on new features in the admin.

We need to kind of hold off, close down some of the bugs, maybe even simplify and deprecate some of the existing features, and then maybe we can make the admin more powerful than it is.

But it's super powerful.

It's just that it's so hard to remember the API.

You have to go to the docs and look it up.

Yeah, yeah, I do.

I think actually in 2.1, there's there's a new option around permissions, right?

Because you can add action level permissions settings.

I believe that was added in 2.1.

There's so this um for all for um the whole history of the project, um, it's it you've always had change at least change permissions.

Um if you could if you could view a model in the admin and you could change it, you might not being able to add or delete, but you could you could alter.

But now there's a view-only permission.

Um you could be like a read-only user of the admin.

So why might that be useful?

Well, maybe I don't know, you've got um a board of stakeholders who they want to be able to look at the data in the database, but you don't really want them to be able to edit anything because, well, they have no idea what they're doing.

Well, you can give them view-only permission so that they can they can look at it, but they can't break anything, they can't hurt anything.

I mean, even with those permissions, for me to give someone non-technical access to the admin, I feel a little squirrely about that.

But yeah, you just baby step along, and then when you feel like you need to do too much with the admin, you should make your own pages.

Yeah, basically.

Don't replace them, override them.

So if you get go down this path, then you you need to be looking at the source, you need to be looking at the docs, you need to be going into the templates and seeing where the the extension points are.

That could be much better documented.

It could be, you know, a series of blog posts or something like that.

But you when you find yourself um what's the her making a Herculean effort, you know, when you're doing far too much, that you know it's much easier then to just create a plain vanilla Django view that does your thing rather than try to force it into the admin.

What was that particular case where you were fighting with the admin?

And that was because we'd moved from using jQuery to vanilla um JavaScript, and there was some reason why the event handlers weren't copied across in the new wave as they were in the old way.

Anyway, it doesn't really matter.

I had to write a unit test for this.

And in the end, I got the unit test going using Selenium, and it was all very fine and good, but it took a long time and a lot of effort, and you you know, I my tweet was about how the Django admin had won again because if you do try and get into the gnarlies and you do try and customize it too much, or you do try and write unit tests for the JavaScript on it, you will find that it it's it's complicated, it's super powerful, it's super mature, um, it's it's experienced over its lifetime l

ots of feature growth that perhaps a little bit too much, and that means it's complex.

And any software which is complex takes time to tackle.

Do I have that right?

I think maybe there's a blog post on that.

Because you know it is a perpetual thing.

Well, people say, Well, why can't we just do it differently?

And it's like, well, because it's it's a beast.

I mean, there was an admin to effort and they did really well and they got really far, but in the end, you you're never gonna reach feature parity because it's got 10 years of edge cases worked in, and it's super right, that's what it's super good and it's super powerful, and it's and you can do a lot with it.

And it has got extension points.

It's not that you can't you know do anything to extend it, but you're never gonna replace that effort in an open source project.

So unless you know AM Big Mega Court comes along and says we're gonna fund it to the tune of a million bucks, which they're never gonna do, yeah, it won't be replaced.

But let's start so some specifics when you're working with the admin, it has search, and actually, if you go in the source code, that's an interesting place you can see a basic search implementation.

So it's got filters, right?

So that you can have filters down the side which enable you to filter by models.

It's a great source of like, oh, they had here's how I'd implement implement a filter.

Yeah.

Well, and it also there are things you can do around speeding up the admin.

Um so uh Jacinda Kelly, who I think will have on as a guest soon, who's the CTO of Doctor and Demand, gave a talk at PyCon I attended talking about ways to speed up the admin.

Because if you have a big, big project, you're gonna be waiting on your admin.

And that's a thing where you go, a case where you go, well, is it the admin?

Is it my queries?

Um, but it can can and is used in very powerful ways when you have massive, massive data sets.

Um, and there's a whole bunch of talks too, if you look at past DjangoCon PyCons about customizing the admin.

So actually, one thing I want to ask you, Carlton, is so there's an option to do an admin documentation generator that I have never done myself.

Yeah.

What's the what's the use case for that?

I mean, it sounds nice, but uh the fact that I haven't heard about it makes me think maybe it's not widely used.

I have to like, okay, so I've half played with this years ago, didn't really get very far with it, and never looked at it again.

And every so often, every every six months, I go through the docs.

I'm not, oh yeah, admin docs.

I should really take the the time to work that out.

I think that's quite powerful.

And all you've got to do is install documents.

Squag or something.

I don't mean like API in terms of something that um another computer would call over a remote service, not that kind of API.

I mean API is in the software API, as in what you program against.

Um it's a good distinction to make.

Yeah, API.

Okay, so you also are aware of it, but not I I haven't heard of someone going nuts with it.

But I to be honest, in all my time, I've never really looked at it more than half a thing where I didn't know what I was doing and I didn't get it working very well, and I never tried again.

Perhaps I'll try again over the next few weeks and come back to you.

Um so one thing we should mention is hardening the admin.

So there's um there's articles on this, we'll link to a couple, but there are some, it is a security concern because so here's a number of things you should do.

And actually, um uh Andrew Pinkham, who wrote Django Unleashed, um, someone I've talked with at length about the admin, um, he actually just removes it entirely on new projects.

Now he's knows what he's doing, so I'm not sure if I recommend that approach, but to deal with these security things, he doesn't even use the admin at all.

He's pure Django shell, he's hardcore.

What I would suggest regular people do is uh in order at a minimum, change the URL so go you can go into the path.

Don't have it be slash admin because people can and will search and try to force their way into your Django project.

You can make it use even more powerful passwords.

There's a number of uh ways in third-party packages to force greater level of password protection.

You can do two-factor auth.

You can get have fun with it and use um Django Admin Honeypot, which is a third-party package, which will let you track and see who is trying to get into slash admin on your site.

Um, of course, you should use SSL.

Um that's really the basics.

The the top thing is don't have it at slash admin.

You know, take take a second and don't have it at slash admin um before you put it out in the wild.

The thing I don't know what you want to add to that.

So normally I use Nginx.

Um I configure it to only allow um access to the admin from logohost or from 127.00 from the loopback address.

And then I and then I use that's a good idea.

So you have to have SSH access to the server, and then um you can only act you access the um the admin via a um an SSH tunnel.

And it means essentially the only people who can access the admin are those with SSH access to the server.

So I do that.

Um that yeah, that wouldn't work in like a newspaper context if you're using the admin for

But then you could what might work in that context is doing it something like something like via an intranet, so you only have access from a host which is exposed on the intranet.

So, you know, presumably um and people use um VPNs now, don't they?

Um so you you might have to VPN into the the luck the the internal network and then you can access the act the admin from there.

But some kind of network level controls where it's I can you know the the the the SHH tunnel example is not very complicated.

If you nag me, I can put that into a gist or something.

I mean the point is is on a large app you need to think about security and the admin is is one of those.

Um but fundamentally it shouldn't feel that hard.

You know, you should basically you should add it for all your apps, do a little bit of customization, you can control the layout.

When you're really fighting with it, take a moment to think about whether you should try to force the admin to do it versus just create your own custom pages.

Like that would be the quick takeaway.

But you should use it.

And again, yeah, and don't feel bad about using it versus the Django shell.

I mean, you and I both prefer and predominantly use it, so don't feel like you're not a real Django developer because you use the admin.

And you're writing your blog post.

Well, you could.

Yeah, I know.

I mean there are people who could, but I couldn't.

Yeah.

Um all right.

Well, so this I think that's really it.

This is meant to be a short episode because we get this question a lot, and I think there's just confusion around it and people fighting with it and kind of wondering what's what's the lay of the land among Jen developers and how to use it.

But um It's good.

That's the quick take.

You should use it, it's a fantastic feature.

When you use other frameworks, you're gonna go, where is the admin?

Because it's really nice.

Okay, let me create the two or three fields, create the admin, start playing with it locally, creating some records, starting adding the right kind of data, and then I can start creating a couple of views around that and see and oh look, I'm missing a field.

And so I can write a migration to add the field, and then I can add a few more records in this admin, and it enables me to kind of iteratively develop my model and my views and the API that will wrap around those.

And even if I'm not going to use the admin in production, it's a nice development tool as I'm going along.

And for me, I just love it.

I love it.

And to have a graphical way to look at them and play with them is nice because you know, I always view it as that's that's sort of like the top of the waterfall, and then the views and the templates and the URLs, that kind of that just naturally flows from the models, but you have to get your models right first.

And I do the same thing.

I'll I'll play around with the models and figure out the relationships in the admin for quite a while before I do all the rest of it because that's really the the backbone of any project.

And you don't have to deploy this stuff to a web application.

If you need a little note-taking app for some project you can work on, you can just create a start app, start start project, start app.

Um, you know, my my project I'm working on, quick model, bam, bam, bam, quick admin, and there you are, you've got a little admin UI that took you 20 minutes to put together.

Where you're trying to enter data in a spreadsheet.

I mean, if you ask, I think any, again, another point, if you ask any professional developer thinking about a project, the first thing I'm thinking about is I'm trying to whiteboard what the model structure is, because that's the heart of everything.

Um and at some point, actually, I'd like to do a video series and just whiteboard how almost every website is the same: Facebook, Twitter, Pinterest, Instagram, they all are crowd with auth and a foreign key and either a one-to-many or a many to many.

And you can certainly prototype them entirely with that.

Yeah.

Um, going through and just saying, give me a website, give me a complicated website, I'm gonna show you how it's fits into that pattern 99% of the time.

That's another great uh learning approach to people trying to internalize and get wrap their head around the structure of web apps.

And being able to wrap a GUI around that in five seconds is useful.

Yeah, yeah.

We will be back as uh we will be back with future episodes.

And as ever, if you have feedback, you can reach us at DjangoChat.com.

We're on Twitter at Chat Django, and we'll see you next time.

Bye, Carlton.

Bye bye.