A conversation with Andy Miller - When you don't need a database

Introduction

Yeah, I mean, it's kind of exciting, and a little bit frightening when you are just browsing around the internet, and you'll just come across a page for some product that you own, or some service that you use, and you see that their website is actually running the platform that you built. It's kind of like, "Whoa, that's cool."

Full Podcast Transcript

Ryan: Welcome, everybody to the Happy Dog Sound Bites podcast. Today's guest is Andy Miller. Let me tell you really quick about Andy Miller, and how I got to know him, and then I'll pass it over to him, and he can introduce himself a little bit better than I can.

I met Andy years and years ago, at a technology conference. There's a content management system called Joomla, that I went to a few conferences around the country, and I happened to run into Andy at some of these conferences. In fact, we spoke together at conferences, as well. Since then, we've stayed in touch, and it's been fun watching him go from being a co-founder of Joomla, to a winding journey down to this great content management system called Grav, that can do a lot of different things. So, without further ado, I'd like to welcome you, Andy, to the podcast, and can you tell me a little bit more about yourself, and what you do?

Andy: Sure. Hi. My experience in the web development world goes back a long time. I actually started doing web development when I went to university, around 1993, and the web was very, very early -- it was early, early days. And the browsers were rudimentary, the HTML was very rudimentary. I started doing web development then, and I just sort of fell in love with it. I kind of could foresee what it might become in the future. Not quite like a visionary kind of thing, but I knew that it would be big, so I invested all my time in it.

I got a job doing these HTML based training, CD-ROMs. That was one of my college jobs, and it paid pretty well, and it gave me lots of free time to experiment, and to learn HTML, and web technologies. I did my senior project in Java, which wasn't even a released language at the time, it was very much a beta language that was new, and kind of exciting.

And then from there, I went on, and I got a job as a webmaster, which is a term you don't hear too much anymore. But, back then it was kind of a trendy thing to be, and I was the webmaster of Exxon Corporation, which was a big responsibility, but they didn't have anybody at the company that knew anything about the Internet. So, they were hiring people for the first time in several years, and that was my job. I was the webmaster of the corporate website, which we had to build, and also the corporate firewall, and proxy server, and maintaining all that stuff.

And there was like a beta program to actually have access to the Internet. It was quite a trendy thing for that company to have this access to the internet. And I remember, because it was like a one megabyte connection for the whole corporation. It was ridiculous.

Yeah, so from then on, I didn't really like the corporate structure. So, I quickly moved on to a start up, doing consulting type work, building websites for clients, and I just continued on with some several startups, and I ended up at Hewlett Packard, and it wasn't a choice that I made, I kind of was working at a startup that got absorbed by Hewlett Packard.

And again, I was in the corporate world again, and I didn't like that that much either. So, from that point on, I just decided that I was going to do my own thing. I was playing around with doing themes for some older content management systems, like PostNuke, if you remember that one. So, I had a theme, and it was quite popular. And then I was just really frustrated with the state of the UI for it. So, I went in search of another content management system, and I came across Mambo, and I was wowed by the quality of the admin, compared to all the other systems out there, and I just kind of got more involved in that, and I became a member of the core team after doing some themes for Mambo.

And then, I'm sure people have heard of the whole spork that happened when Mambo kind of went in two directions, one in the direction of Miro, who was the copyright owner of the name Mambo, and then we started Joomla, we forked it and basically started Joomla. So I was a member of that August group that started Joomla way back when. At that time, I started going to a lot of conferences, and I think that was when I met you, Ryan, and I think probably at one of those Linux expos, or something like that, was probably the first time, and then obviously, at the CMS expos that we went to.

Yeah, so I was involved in that, and it got a little crazy for a while, it was this crazy growth that we had in the Joomla project. And then there were a lot of people involved, and then politics sort of came into it, and I wasn't really interested in that. So, I went off, and I continued to do themes under the Rocket Theme banner, which was my company at the time, still is. And I ran that, I mean, it's been running for 15 years, I think.

Ryan: Nice.

Andy: Something like that. I have to think about it, it's been so long. But then, about five years ago, I was getting frustrated with CMSs again, sort of stagnating, and not really solving the problems I was looking to have solved. So, I looked around, couldn't really find anything that I thought fit the bill. So, I started to write my own, a flat file system, written in PHP, that was focused on speed, and easy to extend, and that ultimately became Grav.

And it was funny, because I would be going to these Joomla conferences still, from time to time, and I would kind of want to talk about Grav, because it was much more exciting than the Joomla subjects. So, then I would talk to some people about it, and they were like, "Wow, is that available?" I'm like, "No, I'm just sort of playing around. It's on a GitHub, but it's not released or anything." And they were asking for access to it, and it kind of just sort of became a project.

I never really intended it to be a major open source project, it was more just a fun thing for me to do for my own stuff. Yeah, and it just kind of took off from there, because lots of people found it solved their problems, and their frustrations. So, for the last few years, we've been improving Grav, we're doing lots of releases. And then to support that, we started a business called Trilby Media, which is basically the professional services arm of Grav, so we can provide help with site development, and custom plugins, or support, or hosting, or whatever you might need around Grav, but it's very focused on Grav. So, that helps fund the development.

Ryan: Perfect, and I want to back that up just a little bit, because there are some people here that might have heard of Joomla, and some might have not.

Andy: Okay.

Ryan: So, I want to kind of give the breadth of everything. So Joomla, is the content management system that runs just under 3% of the entire internet, which is a lot of sites. It's an older CMS that people know, but it became very popular at some point. And Rocket Theme was, I would say, probably the top theme at some point, too. So basically, a lot of companies that were on a Joomla content management system, had a decent chance of rubbing elbows with the Rocket Theme template on the Joomla system.

So, it's actually, when it forked over, and it exploded, like it really exploded, it turned into a big thing. The interesting part is you've been part of similar success with Grav, where, as you mentioned, you started out and it's like, "Hey, I've got this cool little PHP project, check it out. It's just on GitHub." And then next thing I know I'm seeing it's nominated for awards here and there, and it's really kind of blown up. So, before we touch on Trilby, can you tell me a little bit more about the growth of Grav?

Andy: Yeah, I mean, it's kind of exciting, and a little bit frightening when you are just sort of browsing around the internet, and you'll just come across a page for some product that you own, or some service that you use, and you see that their website is actually running the platform that you built. It's kind of like, "Whoa, that's cool."

And we find out, because of the way these kind of open source platforms work, we don't really have any direct way of tracking who is using it, other than some very high level metrics, like download count, and things like that. But we don't do any tracking of who's using it, you don't have to pay for it. So, there's no process of purchasing, with registering who you are.

So, we really just don't know, and really didn't have any idea of how popular, and how widespread it is, until a few years later, when we sort of happened to have a contact with a company that tracks those kind of things, one of those... I forget exactly which one it was, but it was one of those... A site that sort of tracks the technology stack of websites out there. So, they'll tell you, "This site's using jQuery and WordPress, blah, blah, blah."

So anyway, we found out that it was on about 15,000 websites. So, that was really the first time I knew how big it was. But up to then, it was kind of a surprise, because the people that contact us are only a very small percent of the people that are using it. That also goes for support, on our forums, and on our chat, only people that have trouble with it are contacting us. So, we don't really have a good idea.

But yeah, I got notified that it was featured in a German technology magazine, like a printed magazine, had like a two or three page spread with screenshots and stuff. This German guy took pictures, and translated it for me, which was pretty cool. I mean, it's just out there, it's being used by a lot of universities. It's also being used in coursework for universities, for web development courses. It's being used by large corporations, like Microsoft, and Goodyear, just the two off the top of my head I can think of.

But, there's a lot of companies that are using it, that we just don't know that they're using it, but they are. So yeah, it's just kind of become a thing, and it's a little bit overwhelming sometimes, when you sort of realize the responsibility that you have to make sure that the next version is good, and doesn't break the previous version, all these sort of things that you have to do when your product is widely used. At the start, it wasn't such a concern, it'd be like, "Oh, I'm going to break this, because I found a better way to do it." You just can't do that anymore. So, that's just the way these things go when a product, or a project is popular, or getting more popular.

Ryan: Yeah. And Andy, I can think of two more companies that use Grav, and first one is Happy Dog, and the second one is our sister company Hoist.

Andy: Right.

Ryan: So, both of our projects are running on Grav as well. So, we have some pretty in-depth knowledge on Grav. So, one thing, I'll unpack Grav a little bit, because some people as of right now might just know of it as a content management system. You touched on that it's a flat file system. And in our experience, that's been hugely beneficial.

Andy: Yeah.

Ryan: One of the big reasons for that, besides page speed, is the fact that we can track all of the content on a repository. So, what that means is, you don't have to mess around with a database anymore. So, if you edit a page, and you add some words, and it's like, "Oh, maybe I shouldn't have done that." You can easily go back to any version you could ever want, because it's all tracked in a Bitbucket, or a GitHub repository.

On top of that, having it be flat file, it's been ultimately way faster than the other CMS’s that we've used before, as well. Those are two of the main reasons we use Grav. It's fast, it's secure, it's easy to manage. But, moving sites around is the other advantage as well. Creating development sites, and live sites, and moving them from one environment to the next, you're really just moving files. You don't have to set up a database, or a user, and do all that kind of stuff. So, those are the few benefits that we see using Grav, and it's night and day compared to other content management systems that we've used. How about on your side? What other advantages have you seen Grav give businesses that use it for their websites?

Well, I think that you touched on the primary one, which is the flat file nature, that is really, really key for a lot of companies. Not just for the performance, not just for the ability to track everything in source control, which is hugely important. But, what that actually allows you to do, is to really create powerful workflows.

So, for most projects, a web development project with a traditional CMS, where you have files, and you have a database, it's quite cumbersome to manage a development workflow, or a life cycle of that code base, because you have to sort of keep in sync this database structure, database content, files, the file content part, all the plugins that you're using, all of their dependencies upon other parts of the database, and all of this stuff. This makes it complicated when you're going through the development phase, and trying to put it into sort of some kind of a test environment for the client to test against, and then perhaps a staging server, where perhaps publishers are working on the content, and then, finally, a production server.

This is a cumbersome process with a traditional CMS, because you have to sort of make sure all these parts are synced in between everything. So, if changes are made on a staging server by publishers, you need to be able to get that back to the developer side, without losing code changes that the developers made. This all goes away with that whole flat file and the source control capabilities, because you can just sort of be syncing these files, and the state of the files is exactly a one to one state, throughout all the lifecycle.

So, you can take a zip, and you can put it onto your own computer, and you have an exact copy of your website, and you don't have to worry about things, and you can change it, and then you just copy those files to your production site, and now your live site is exactly the same as the development site that you just worked on.

So, that part is really, really important for multiple reasons. I think that's one of the primary reasons why people love Grav so much. There's just a lot of benefits of being filed based. On top of that, I think that it's really nice, because Grav is very different from traditional CMSs, in that it doesn't render any content out of the Grav core. It just sort of gets the data, and sets the data, and then all of the rendering is handled in Twig templates.

So, if you don't know what Twig is, it's a templating language written for PHP, or written in PHP, and it allows you to write HTML with simple logic inside that HTML, without having to know all the intricacies of PHP, and not having all of the security vulnerabilities of having PHP code in your templates. So, that means that you can basically realize any kind of a design that you can think of, so you're not tied to a certain restriction.

And this was very common in the Joomla days, especially, we have a lot of experience with this, working with themes, is the theme designer would say, "This is how I want the blog page to look." Or some content page, and then we'd have to say, "Well, we'll have to sort of have this part, because it's coming out of Joomla, is going to be restricted to how it can look. It's got to look like this, but we can wrap it with some modules, and things like that, to kind of give it the look that you're doing." But you never really had that full control, because the platform itself was imposing a bunch of limitations.

This is kind of the same in all the other platforms out there. But in Grav, we really don't have that limitation, on purpose. I mean, I made it that way, because that was a major frustration for me. So, it does allow you to do many, many different things, and a designer can come and say, "Hey, this is how I want it to look." And with Grav, I say, "No problem. I can make it look exactly like that, to the pixel if you want." And it's all going to be controllable with custom fields, and everything, nothing's hard coded. It's all going to be dynamic.

So, you get a ton of flexibility on how things look, and I think that's one of the reasons why it's become so popular for documentation, to be used for documentation sites. Like I know when Microsoft Mixer is now being shut down, but it was like Microsoft's streaming service. Their documentation for Mixer was written in Grav, which was pretty cool. So, they had approached it for documentation, and I know a bunch of other places that are using it for documentation.

Funnily, there's a Drupal product, that's actually a very popular product, but its documentation actually is written on top of Grav, not Drupal, which is pretty cool. So yeah, it's used for documentation, because you can really tailor it to that, or you can use it for a traditional website, or e-commerce, there's basically no limits. So, that's a second primary feature I think, is its absolute flexibility when it comes to building sites.

And then I just think that it's easier to use than a lot of those. It doesn't require quite the complexity to develop custom logic. So, from the Joomla world, you'd probably know that if you needed to do some custom logic, you probably need to develop a component, and perhaps some custom modules, and perhaps some custom plugins, system plugins and stuff, and these all have to be set up in a certain way, and they have to work with each other, with controllers, and all this stuff.

But in Grav, you could do that if you wanted to, but you don't have to. It's a lot simpler to create custom logic. The plugins are very basic, they're just event driven, and you can do very minimal stuff, and get custom functionality from it, which is pretty cool. And you don't have to install plugins, you can just... It's just files, so you just create a folder, and put some files in it, and then all of a sudden, you have a plugin. Okay, you have to follow some rules, obviously, but it's a lot quicker.

Okay, so just a case in point. Yesterday, I had some custom work that I had to do for a client, and I knew there was a plugin out there, and I went to use it, and the plugin was completely broken. So, I had to create a plugin, and I created it in two hours, like to do all the functionality that I needed, from scratch. So, it wasn't a huge loss. But I mean, if that was in WordPress, or something, and you were relying on a plugin that didn't work, and then all of a sudden, you had to build that custom, I mean, that would dramatically change the time it took to develop, because you'd have to have to build a custom plugin, and that's quite time intensive.

So yeah, so extending it is relatively easy, and quite quick to do, so that's another major feature. I mean, there's a lot of features. It's got multi language built into it, which is very powerful, and it's not clumsy, like in some other platforms. It was kind of built that way, from very much near the start of graphic development, we've had that multi language built in. So yeah, I mean, there's a lot more features, but I think those are the key ones.

Ryan: For sure. You hit the nail on the head a bunch of times, and I'm going to go back to one specific thing you were talking about, because that's honestly, the secret sauce of our design process, and technique, is the flexibility, and the perfect marriage of allowing somebody to edit a page, but not allowing them to wreck the design.

Andy: Right.

Ryan: So, what I mean by that is, let's say you create a WordPress site, you give it off to a client, or company, whatever it is, and say, "Here's Gutenberg, edit everything you want, because you can pretty much do anything in there." And then the next thing you know, somebody who doesn't have any design background, doesn't know any of the brand standards, any of the fonts, the colors, and doesn't know how pages should be set up, they throw 50 videos on a page, and put a button way at the bottom, and everything's getting all screwed up because it's just in the wrong hands, and they broke the framework.

What Grav allows that same person to do, is go on the page, and enter in simple fields, what would you like to add? Just in free text, what's the heading going to say? What is the content underneath there? What image do you want in the hero section? What image do you want underneath, in this part, in this part, in that part. And what that allows the person to do is give them the flexibility to edit their content, but not change the design. There's such a big difference there.

Going back to the conferences we used to speak at, a lot of times I would speak at the Joomla conferences, for example, about templating, or theming, or conversions, or navigations, or things like that, and it always revolved around setting up the page on Joomla, and at the end of the day, I'd field questions like, "Well, we want this module here, but it has to be here. But then we want this section here." And at the end of the day, it's like, "Well, now we need four modules, and a custom fields plugin, and two other things." And then if I have to tell them how to edit that, there's five different pages for them to edit the content for one page.

Andy: Yeah. That was one of the major things that I disliked about the Joomla model. It was super flexible, you could do a lot of things with it, but it required you jumping around in the admin, to change a bunch of different places that would eventually affect one page. So, that's exactly what you're describing, is you have to set a module to display on this menu item, and you configure it here, and perhaps you need to create a copy, because you're using it somewhere else, but it's got a slightly different configuration.

So, it wasn't intuitive for people to be able to pick up. But with Grav, and in what we do is we generally will build a page, and that page will be a custom page template, and you'll have a custom page blueprint. And the blueprint is our terminology for defining all the custom fields for that page. So, that means that the client, or the user of the website, only has to go to that one page to make changes to pretty much all the important key parts of that one page, rather than having to hop around in all different places.

So yeah, that's a pretty cool thing. And I think a lot of platforms have this nowadays, but it wasn't sort of built in at the start, and it's sort of shoehorned in. It's like, "Here's a way of doing things." But it's not the way the platform was intended to do it from the start. It's kind of like an extra add-on.

Ryan: Yeah.

Andy: It's an afterthought, really. But for Grav, it was in there from the start, and that's the way we want to do it, because that's the way that makes sense.

Ryan: Yeah, exactly. And the Happy Dog website, for example, if you look at the home page, it's very complex, there's a custom video animation that's in the hero, and there's some hero text, and then there's marketing text underneath. And then there's logos that show up in three separate different rows on the page, and then there's all sorts of different parts in between.

And for us, if we want to edit the content to that homepage, it's literally just one page we edit. There is a place where we can do the path to the video, and turn the text that goes in the different areas. There's one spot where we upload all the logo files, and they kind of show up in three different spots, because of that Twig logic that you'd mentioned earlier. So really, paired with the right company, like Trilby Media, for example, you could really take Grav, and pretty much any design, and make it work perfectly for your business.

Now, the caveat to that is you have to trust the agency that's doing it, and you have to trust the design. Because one thing I want to throw out there is sometimes there's clients that want to change all the designs, and companies that want to do that. And that's fine, Grav's intention is more for managing your content, and allowing the template, and the theme, and the designers to hold their designs true, and have it be more concrete. Is that a fair assessment?

Andy: Yeah, I mean, I think so. I think it's always like a balancing act, when you're trying to... A client will come to you, and sometimes you have a client which trusts you to do whatever you need to do. Those obviously go really easy. And then you've got clients that have ideas, that sometimes are good, and sometimes we don't think are good. So, there's a little bit of discussion there, and some pushback, and compromise, and all this stuff, and then it gets harder. But Grav can accommodate it, for sure. I mean, no matter which way that it goes.

Ryan: Okay.

Andy: I actually have a little story, which kind of ties into this, it kind of made me think of it. A couple of years ago, we were contracted to do a prototype site for a government department. I won't mention which one it was, to sort of take a Drupal site that they already had existing, and to just develop it from scratch on top of Grav.

We didn't have access to the actual Drupal code. We had a couple of screenshots of how they administered the content, and we had the other design that they had originally wanted. So, we took that, and within a few short weeks, we developed the site, and we used some custom short codes, and short codes are actually something from the WordPress world. They may have been from somewhere else first, but I know they're quite popular in the WordPress world, but it allows you to do some complex HTML rendering with some short code.

So, sort of square bracket syntax to say something like tabs, and then inside of that you have a square bracket syntax that says tab, and title equals tab one, and then another tab, block, and then title equals tab two. So, that will then be rendered in HTML as tabs with any associated JavaScript, so you can click tabs. So, a whole bunch of short codes to make some of their custom content simpler.

And then, we showed them this, a demo of the site that we'd built, and they were blown away, because their current site, they have to communicate with the developers to make any content changes, because there's no way that a layperson could go in there and make changes. They had things like sidebars hard coded as HTML inside the content of each page. So, every time you'd have to go in, and sort of add this extra menu item in HTML, if you added a new page. All of this stuff, very, very manual, very, very much just this big HTML text block that they had to template . There were no custom fields there at all.

And the menus were very manual. A lot of the functionality from the design, the developers couldn't do because of limitations, or perhaps... I'm not sure if it was limitations of the platform, or limitations of their capabilities, but the design didn't really match the Drupal site. So, we basically made it match exactly with all of the designers, features, and functionality that she had wanted, and they were super blown away by this whole thing.

It was just political machinations up higher, that basically said, "We're using Drupal, we're going to stick with Drupal, no matter what." That sort of stopped that project going further. But, we sort of nailed it. So, I always think of that one, as a great example of what Grav can do. Even though technically, it didn't come to fruition, it wasn't because of what we did, because the whole team that we showed it to were like, "Wow, this is going to make our life so much easier." It's developed in a fraction of the time that the original Drupal site was developed, it's so much easier to maintain. It's so clear, and obvious how to do things, it's just the simple syntax we have now, and custom fields for things that don't need to be in the main content area.

Just all of this stuff that we did, plus, it was way faster. It was simple to deploy, it required less hardware to run it, like instead of a big, multi core server with Varnish cache on in front, and a separate database server, it was just hosted on a very lightweight VPS, and it was blazing fast compared to their Drupal solution. So yeah, I mean, it's kind of one of those things where you can really show what a difference Grav can make, and that was a great example, where we took an existing site, and just sort of redid it on top of Grav.

Ryan: So that's a great success story. We love success stories here.

Andy: Yeah, yeah.

Ryan: You hinted on the migration of going from one CMS to the other, and you also hinted on, that businesses can be scared to move from one platform to a new platform, because there's this conception that it's this massive undertaking, because they're basically married to their content management system. So, if they've been on WordPress for nine years, somebody comes running by, "Hey, there's this Grav thing, you should check it out." The first conception is, "Oh, this is going to take just an extraordinary amount of time and money to migrate to something like Grav."

I would venture to say that's patently false, that it's not a scary move to go from a different platform to Grav. In fact, I think there might even be some plugins, or extensions for certain content management systems that actually helps migrate their content even faster over to Grav. So, in your opinion, what's the migration process like? How easy is it for a business to go from their existing platform over to Grav?

Andy: Yeah, I mean, it's generally not that hard. It sort of depends upon your content. There are sites that we've worked on that have a ton of content, thousands of blog posts, for example. Migrating that is just time consuming, because you can do it the easy way, which is basically, get the data out of the database, and dump that straight into a flat file. So, each page inside of Grav is a separate markdown file. So, it's a separate file for each page, and the content can be HTML. So, we can take the HTML content straight out of a Drupal site, for example, and stick it into this markdown file, so the HTML is there.

But we don't like to do that. So, when we do it, we normally don't export the content from the platform directly, we normally take it right off of the webpage. So, from the view, from the website, we will copy and paste the content, and then we'll manually mark that up inside of the markdown page, with just markdown syntax.

So, we will move that content from this HTML format, which is sort of riddled with bad HTML, and hard coded styles, and all this other stuff that is a legacy of using a WYSIWYG in the true HTML fashion, where you give everybody control to write whatever HTML they want, even though they don't know that they're writing HTML, they're just highlighting things, and selecting stuff from the toolbar, that is actually saved as HTML, which is then in this sort of pre rendered state. And then it's kind of hard to manipulate, so we like to migrate to a cleaner markdown solution, which can be time intensive, if they've got a ton of content. But for the most part, companies don't have that many pages, and it's really not that bad.

For example, for that government project I was just talking about, they had about, I don't know, 100 pages, and that wasn't that time consuming to do, because it's just sort of copy paste, and then you're just marking up things like hyperlinks, and titles, and stuff like that. And then when there was some more complex stuff, we just converted those into short codes. So, those short codes, we could just copy and paste, and reuse them quite a bit, and just make changes to the content.

But copying and pasting is actually really quite a fast way of importing. But at the same time, you're cleaning up their entire site. So, you're getting rid of all that legacy crud that has built up over the years on that other platform, and you're starting, kind of with its fresh, lean version of something. So, it is scary sometimes for clients that are switching to another platform, and it's mainly because people just don't like change. They get used to something, even if it doesn't work well, it's cumbersome, they learn how to work around those roadblocks, and they get comfortable with it.

So, even though it's not a good solution in many, many ways, they don't want to change, because they don't like to learn something new. But if you show them something that's just so much easier to work with, then sometimes that can tip them over that tipping point, where they say, "Okay, I'm starting to get more comfortable with the idea of change, because the benefits are so great. It's going to be so much faster, it's going to be so much easier to maintain, we've got all the benefits that we discussed before, like the source control, and the portability, and all that stuff."

So, it just sort of depends on the client, and how willing to change they are, and sometimes large corporations, governments, they don't like to change no matter what. I mean, you could show them the most amazing thing in the world, costing no money, and they still wouldn't do it, because it's change. And they have to get change approved, and that's got to go all the way up quite frequently.

But, it's generally not a massive thing. I think it's easier to port a site to Grav than, say, from WordPress to Joomla. That would be very difficult. It's really not that hard because of the flexibility that we have in templating, and the way that we handle the content in these files. We've never had a problem porting a site in all these years. I mean, it's just something that you do, and it's very doable.

We started off with tools, but we ended up not using the tools, because those tools were basically trying to take the structure that was often bad, the site was poorly designed before, because it was working around the limitations of some CMS they were previously using. So, rather than trying to port it, we just sort of rebuilt it. I don't think it takes more time, and you end up with a much more superior solution, because it's been basically redeveloped from scratch.

Ryan: Yep. And another aspect of that, too, that I'm sure people are curious about, is security. Because when we've worked with clients, in every content management system, there is a time where a website gets hacked, I've seen them hacked in Drupal, I've seen him hacked in WordPress, I've seen them hacked in Joomla. From our personal experience, over dozens of sites, we've not seen one Grav site hacked. And now, that could be security through obscurity, that the numbers aren't as high as the others. But I'm sure there are also some security measures that are in place, even just due to the nature of it being a flat file system. But I'm curious, from your perspective, from being the founder of Grav, what can you say about the security of it?

Andy: Yeah, security is something we take very, very seriously, and we have ever since the start. One of the main things that I can point to, to say Grav has a standout security feature, is that you don't need the web UI to administrate your site. And you certainly don't need it to run your site. So, that is actually a totally optional plugin.

So, if you go to the Grav website, and you go to download Grav, there are actually two options. There's a download Grav core, and a download Grav core plus the UI side of things. And that's because a lot of people don't run with the web UI, because that actually is probably the most likely way to hack into a site, because you've got this username and password login, and once you're in there, you have access to administrate the site, right? It's the same for WordPress, Joomla, Drupal, all of these CMSs, you have to admin the site through this UI, because the content is ultimately stored inside of a database, and you can't just access the database easily. You needed some kind of a UI on top of it.

But for Grav, you don't, and because they're flat files, you can actually administrate your site, just through the files, and a Visual Studio code, or whatever you want to do to actually open up the files, and change your content. Or, and this kind of goes back to the whole lifecycle thing I was talking about earlier, you can have a site for your staging server that has this UI for your users to be able to... For your publishers and content creators to be able to log into admin, and create, and modify content.

But then, you could push those files to the production website that doesn't have the admin. And if you don't have the admin, then you've got this major security vulnerability just not there. So, it will be secure from that side of things. And then on top of things, we use Twig for templating, where quite a few CMSs still use PHP as their templating language.

And PHP is obviously very powerful, but it allows you to put PHP code into your templates. So, if you were hacked, and you could inject some PHP code, you're going to be wide open, and for Grav, it's much harder to do that, because Twig adds that security level. And in fact, now we actually turn on the toggle, so your HTML is actually not going to be rendered unless you explicitly tell it to be raw HTML. So, it's like an extra level of security in the templating. So, there's that.

The other major thing that's an advantage is, in the WordPress world, for example, and I always pick on WordPress, I'm sorry, WordPress. But, people build sites based on tons of plugins, and this happens in the Joomla world too. So, to get all the functionality that you want, you're not going to create that from scratch usually, so you just install all these plugins, and these plugins are often poorly written, have security problems, they may not be updated as frequently as you would like. So, you may be stuck on an older version of some plugin, and that's got some security hole that's become widespread, and well known, and now that's a hole into your website. That's an attack vector.

On the Grav side of things, we try not to use plugins unless we have to, and plugins are much simpler. So, they're usually not as likely to have a vulnerability, because the complexity is less. We also have created a whole bunch of plugins, as part of the Trilby... I'm sorry, as part of the Grav core team. So, we have hundreds of plugins that we maintain, and we know that those are much more secure than the average third party developer, because we understand the platform, and the best practices to use and everything.

So, most plugins are not going to be third party, and quite frequently, you don't need to create a plugin, you can just do some custom logic inside of your theme, for example, where you can create your own custom plugin to do a little bit of logic, without having to rely on a third party one. So, that's another way that Grav is often much more secure.

And I think a lot of people come to us from the WordPress world, for example, because they've got into a situation where their site can't be updated because of a plugin that can't be updated for some reason, it's not compatible with a new version, or perhaps it's not compatible with a certain version of PHP. So, they're sort of stuck in this state where this site is old, and it's getting older, and there's security vulnerabilities that have been discovered that they can't fix, because they can't update to the patched versions. So, they're kind of stuck in that situation, because they're held hostage by some plugin that they are relying on.

That generally doesn't happen in the Grav world, because it's sort of... I mean, generally speaking, it's much more compatible with updates, and plugins seem to maintain their compatibility because they're less complex. You know, things like that.

Ryan: That's some good information on security.

Andy: Yes, so in quite a few ways, the security is enhanced, for sure.

Ryan: For sure. And I don't want it to sound like this is just a giant advertisement for Grav, and all the other content management systems suck. There are times and places for-

Andy: There are good ones out there, for sure.

Ryan: There's other good ones out there, and for example, WordPress has come a long way. I remember when it first started out, and it was just a blog system, and they've evolved in their own fashion. And I'm not trying to make this like this big commercial for Grav, but I am serious when I say this, it is one of our secret ingredients, because of all the things we have talked about.

So, I'm trying to run an informational podcast, but it's very truthful that it's that powerful, that secure, that fast, and it's that good. So, that being said, this is the point in the podcast where I'm going to pivot, Andy, to talk about you personally, if that's fine?

Andy: Of course.

Ryan: There's a section that we do on every podcast, I call it the lightning round. So, what I'm going to do is ask you five questions. There's no such thing as a wrong answer.

Andy: Okay.

Ryan: Just tell me the first thing that pops into your head.

Andy: Now I'm stressed.

Ryan: It's low pressure, you'll do just fine. Are you ready to do the lightning round?

Andy: Yeah, just do it.

Ryan: First one's super easy. So, what is your favorite food?

Andy: Thai food. Spicy Thai food.

Ryan: Okay. Spicy. Nice. I like it. I'm a big spicy Thai food fan myself, so that's good. So, are you a fan of curry in your dishes then?

Andy: Yes. Yeah, I like all kinds of hot and spicy food. But probably Thai is my favorite, though.

Ryan: All right. Second question, favorite place that you've traveled to?

Andy: I travel quite a lot. So, this is kind of tricky. I would say Kenya, and I have a couple of reasons. One is kind of a cheat, because I was actually born there, and my parents were working there when I was born. So, I have this affinity to it, but I hadn't been back in many, many years, and I took my family back a few years ago, and we did a safari, and it probably was because of my history there that I just loved it so much. But, the people were so nice, so friendly. We had so much fun, we saw so much cool stuff on the safari, and it was just amazing, and I'll never forget it.

I think my whole family really loved it, and we talk about going back, and obviously, someday we would love to do that. But yeah, I was sort of worried that going back after so many years, I had these faint memories of when I was a child there. But, going back as an adult, with a family, I was worried that it wouldn't live up to my expectations, but it totally did, and blew it away.

Ryan: That's good. That's an awesome answer. All right, moving along, this one could be a tricky one. See how your memory is. Do you remember what your first ever smartphone was?

Andy: Like smartphone, like with a big screen?

Ryan: Yeah, the one that you could... Yeah, I guess go through the first smartphone that you remember having.

Andy: It was the original iPhone.

I was a Mac user. I've been a Mac user since about 2005. I don't know, when did Tiger come out? I don't recall. But, it was around then. My first computer was a Mac Pro with Tiger, and that was just released. My first Mac, yeah. So. So, ever since then, I've kind of been in that Mac world, and I was very excited about the original iPhone when it came out.

Obviously, it was severely limited, that original version. I still actually have it, and I still use it as a clock. So, I just sort of keep it charged, and I use it. I kind of reach for it, and I use it as a clock, and that's all I really use it for these days, but the battery lasts a week, just as a clock, which is kind of cool.

Ryan: That's crazy. And you were right, it's April 29th of 2005 was the release.

Andy: Okay, wow, good. Yep. So, yes, that was my first smartphone. I was kind of late to the whole mobile phone thing. I wasn't one of those people that carried a mobile phone when they were still large. I can remember that I had a Motorola Razr.

Ryan: Oh, I remember the Razrs.

Andy: Yeah. So, that was the other phone I had prior to that.

Ryan: Okay. All right, next question. If Christmas was tomorrow, and Santa could bring you anything, what would it be?

Andy: Oh, can I ask for things that don't exist yet?

Ryan: Sure, you can answer any way you want.

Andy: I would like to get a new 16 inch MacBook Pro with the M 2345 whatever chip.

Yeah, because I love my Macs, and I love my MacBook Pro. But, my little MacBook Air that I picked up, like the base model MacBook Air just blows me away on how awesome it is. I just want that for my main computer.

Ryan: Cool. All right, last question. What does your future hold?

Andy: Well, as my future is kind of wrapped up in Grav, it's mainly about Grav, we're just sort of focusing at the moment on some premium products that we released for Grav, some cool plugins, and themes. So, we're going to do some more of those, some more premium products. We're just getting Grav 1.7 stable, which we released in January. So, that's the big version that we've been working on for over two years, and it has a lot of cool functionality in it.

So, getting that stable, and then the really exciting part for us is to begin working on Grav two, which is going to be a major... Effectively a rewrite. We'll port over functionality from our current Grav one code base, but we want to sort of have this as an opportunity to sort of take everything that we've learned over the years, and distill it into a new version, and make that much more of a headless CMS.

So, I mean, there will be the admin still, and all those things, but we want it to be able to be more headless, and more flexible in how it's used. I know that you guys use it in a very headless way, by basically using it as your content management and then you render everything in JavaScript. But, to do that with an API, rather than just your custom JSON data that you're probably using today. So, having a much more structured API level on top of it.

So, that's what we're excited to be working on next.

Ryan: And yeah, you're right, we use Nuxt.js for generating the JavaScript static site, which is blazingly fast. But, if we ever need to add, let's say, a blog post, or a podcast or anything like that, we just hop into Grav, boom, it's done. So, it works out really well. So Andy, it's been a pleasure talking with you today. Grav is, again, it's awesome. I highly recommend looking into it. But, if you are more curious about Grav, and you want an agency to help you out, who better than the company that actually wrote it? So, how would people get in touch with you, Andy, if they had questions?

Andy: Yeah, the simplest way is just to go to Trilby.media, or TrilbyMedia.com, if your brain thinks in dot coms. Yeah, and then on there we just have a contact form, you can easily reach out to us if you need that sort of help, or if you want to just experiment with Grav, and try it out. We have ways of reaching us there, through our Discord chat, which is on the top of the GetGrav.org website, there's a link to it, and you can join the Discord chat. I know Ryan's in there a lot, too. So, a lot of people are there. We're there. We can help you out. You can chat with us, ask us stuff about Grav, or whatever. It's just a place to be.

Ryan: Perfect. Andy, thank you so much for your time. I really appreciate my time with you. Have a good rest of the day.

Andy: Thank you very much.