Transcript
Unknown Speaker 00:00
Okay, I'm gonna go ahead and get started. There's a lot of content we have to get to today. So, let's jump into it. A Welcome to planning Drupal seven end of life of the museum. I'm Doug Allen, a board member at MC n. And here to welcome you and introduce today's session. MC n is a nonprofit volunteer run professional organization committed to growing the digital capacity of museum professionals. MC ns developed a deep active community engaged in year round conversations webinars, resource sharing. As an MC a member you can join special interest groups participate in our mentorship, program and shape benzenes future and leadership roles, such as our SIG chairs, conference chairs and time with us on the MC n board. If you aren't already a member, we hope you'll join us You can learn more at mc en.edu. Also, I want to thank Microsoft, the registration Assistance Fund sponsor axetil. Excuse me, Microsoft is the registration Assistance Fund sponsor. Xel is the Ignite sponsor and all the other sponsors that are listed in the program for help making this conference possible. Today's session is a workshop and we're going to be using the chat box for your questions, please post your name in the chat box and you'll be called upon. So you can ask your question. If you'd prefer not to ask, just type it into the chat box. Once again, this session is planning for Drupal seven end of life at the museum. Your presenter today is Alex Morrison, the managing director at cognac. And he'll be joined by Matt Chapman and Ben Kyriakou chiriaco. Also with cognac, who will be answering your content types that are questions, Alex, off to you.
Unknown Speaker 01:55
Hi, everyone. I hope you can hear me. I am very pleased to run this session, I'm going to start sharing my screen and explain what we're going to do if I can do that. Let me just see if I can do that. Right. Okay, so
Unknown Speaker 02:21
not
Unknown Speaker 02:34
right. Can everyone see the screen? What? Thank you, right? Okay, let's go. So the session, we got an hour today to talk about something which I think is for those affected, it's going to be quite an important subject over the next year or two. So I just wanted to keep it fairly simple and to make it as open as possible for people to add their own thoughts and questions. And to have this this discussion here MC n. The session is going to break down into three very simple sections, a quick introduction, just introduce myself and my fellow presenters. Then I'm going to give you a bit of background on this whole subject. We've done a bunch of research, which I'll share with you to explain why this is an interesting issue. And then the most important part of the session, I think it will be the will be the q&a session. So I've pre prepared a bunch of questions for Matt and Ben. And I'll take questions from from from participants as well. And hopefully we can have an interesting conversation that way. So let me just spin on here. So my name is Alex Morrison. And I'm the managing director and founder of cog app. We manage run help support quite a large number of Drupal websites. And so this, this subject is dear to our hearts. And we see that that is a subject that's going to there's going to be important and interesting over the next few years. For people I'm here today with two of my colleagues. I run projects and manage the client relationships and do research and think about strategy. my two colleagues actually do the work of of leading teams on the kind of projects that we're talking about today. So just briefly then. So my colleague Ben is here, Ben Kyriakou Ben's worked with us for for a long time now. Leading projects working with with Drupal. Benji wanted to say a bit about your background here.
Unknown Speaker 04:56
Sure, so yeah, as as Alex said, I've been working with Drupal for quite a long time now, I think the first Drupal site I introduced Drupal five, which was very many years ago now. And yeah, recently, especially this year have been working with Drupal eight, and specifically over the past 12 months or so, migrating some Drupal seven sites to Drupal eight. So hopefully I can give you some pearls of wisdom from the experience there.
Unknown Speaker 05:24
Thanks. My next call is, Matt. So Matt is like, like Ben, very experienced developer leading teams working on Drupal projects, and how steep experience of moving things from one particular Drupal seven to Drupal eight, so much just want to say a bit about how
Unknown Speaker 05:48
much the same has been in working with Drupal for a long time, probably since since about Drupal five. Over the last 10 years, it's been the main constant in my career. And it's been either moving people onto Drupal seven, or Drupal seven and Drupal eight or moving across. But generally, Drupal has been a key part of the platform.
Unknown Speaker 06:14
Thanks. Okay, so so that's what we're bringing to this to this party. And the first part of what we can do is just to look at a presentation, I'm just giving you the results of our research. So this is a separate presentation, which I can share the link you can you can have access to this. So quickly zip through this. Hang on, how do I present it?
Unknown Speaker 06:53
So when I first heard about Drupal seven, Drupal eight, I thought, Okay, well, no big deal. And then I started to understand a bit more about what was what was involved, and realize that we needed to do quite a lot more research to find out what what was going to happen here as Drupal seven came to the end of his life. So just give you the results of that. Before we go into the questions. I'll begin with an update. So Drupal seven was due to go end of life in November 2021. Because of the pandemic, and the impact that that's had on everybody, they've actually extended that. So the the issue that we're talking about now as a Terminus in November 2022, which is good news, obviously, in relation to timing of everything in 2020. That feels like okay, well, we can all relax, I think, depending on on how you experience what I'm going to show you now. I think we don't get it, that's probably not right. Why it has been delayed. And that's good, because it gives us more time to get get our act together. It still means that if you're investing in the Drupal seven website, then you're probably putting money into something that is not going to go very far. So best to get on and move to the future technology now. But let's come back to that question as we get into the questions. So just briefly, then, is some talk a bit about Drupal Drupal at the Museum of why it's been good in the museum's world. Then a bit about what's happening with Drupal seven, some of the issues around upgrading, and some of the possibilities that arise. So Drupal seven, has over time become a very strategic asset for lots of museums and their online programs. And it's kind of unexpected, that it would come to the end of his life in this way. And the way that it's that this is happening, I think we would argue it really does need quite strategic response. It's not it's not just a kind of, Okay, we'll just business as normal kind of event is actually much more interesting and potentially significant than that. And that's what this is. This session is all about. We look at Drupal itself. Drupal launched in 2001. So it's no 19 years old, I guess. It's been very, very successful. And I think it the reasons I quoted here, it it's very versatile. It's quite cleverly arranged, organized. It's open source, very importantly, it's incredibly widely supported. And it does a job of providing kind of Enterprise Content management services to people who otherwise would have to spend a lot of money on buying a proprietary system. And it has all the advantages that open source has responded over many years to lots of demands that, that museums will recognize. And it does is incredibly widely used over a million websites. And those are not not trivial things. It's a big deal. Drupal seven came out in 2011. It'll hit the buffers in 22. Drupal eight, funnily enough, came out in 2015, after much brouhaha. Remember waiting for it with bated breath. Funny enough, that's coming to an end before Drupal seven in November 2021. Because, for reasons I'll explain later, but the good news is that Drupal so Drupal eight is being replaced by Drupal nine, which was actually released in 2020. And seems to be a decent thing. So at least that the upgrade path is secure. Why is Drupal in use of the museum. And this was something that really surprised me when I dug into it. So there is a very helpful survey produced by the MIT museum. And the link isn't in this slide. And I'll share this with you. One winner after this. But I did the analysis of the 148 listed websites.
Unknown Speaker 11:34
And of those, over a third, were using Drupal. The next one down was WordPress, then typo three, and the rest and the rest of just basically tumbleweed. So it is it is really preeminent. It's It's It's literally twice as popular as the nearest competitor, WordPress. And there are reasons for that. Why, why is that? Well, it's open source and widely supported. And it's based on the most common and most popular and best established open source frameworks are Linux, Apache, MySQL, PHP. It's got very good security against hacks, which people care about a lot of our clients, we deal with Arabic websites, Yiddish websites, all sorts of multilingual content. And it's got very good support for multilingual stuff. It's got good support for version control software. So if you're doing a sort of enterprise, project using using content management, you really need this kind of facility. And many more lightweight content management systems simply don't have this, which would make developing a large project in the framework, much more difficult than it is in Drupal. So that's that's often a key consideration in the decision. It's got lots of support for integration with other systems. So again, because it's so widely adopted, and because it's, it plays such an important role. For many organizations, there are integrations with all sorts of other things that people care about. And it's got really good facilities for for scale. And in the case of museums, lots of rich content. So it can it can handle museum collections, and all the things that museums care about. And it integrates Well, with with complex search and all the things that you might do with solar or Elasticsearch all fit well within Drupal framework, which again, is not it's not universally true. Because thinking about alternatives, as we said, is twice as popular as the most popular alternative alternative, which is WordPress. WordPress is still I think, primarily aimed at smaller websites. We've never been found. So I know people are. If we were looking at alternatives, we'd be looking possibly at craft CMS, which we've used on a few things and we like a lot, but it's not open source and it does have limitations. Not sure that it would be suitable for a huge corporate project. Type oh three is up there with with WordPress in popularity. Or we know about typo three is we recently moved some of the off typo three on to Drupal eight and they were really keen to move. That may be a one off experience. But it seemed it seemed indicative to us and we certainly didn't see any reason to love it particularly. And the all the other systems are just used by a tiny minority. So Drupal is far from perfect. Anybody who's used it knows that it's got all sorts of complications and it's gnarly and awkward. But if you need the features I've developed and you need to be open source, then it's it's hard to see that there are many better alternatives. And so obviously, it's worth it's worth considering this question. But you may you may go around that bush and still come back and say why don't you know we do still need to use Drupal. So with that preamble, then Drupal let's let's have a look at the Drupal seven, Drupal eight Drupal nine sequence. So Drupal seven was a major improvement over earlier versions, it was a big change from from five and six, which many people started using. It's been it's been very successful. But the the underlying components in the software architecture have been overtaken. So it's, it's not, it's not organized in the way that that a modern web software project would be, would be organized, particularly with respect to the object oriented programming paradigm, which is extremely powerful and useful. There's an article which is linked here, which explain a bit more about that. So in particular, that when they moved to Drupal eight, they wanted to make it a big paradigm shift. And this is this is where a lot of the the advantages of moving from Drupal seven to Drupal eight come in, but also where a lot of the complication comes in. So
Unknown Speaker 16:38
Drupal seven was obviously introduced before, widespread need to produce responsive websites. And that has made an enormous difference in terms of the complication of building high end, lovely websites of the sort that museums need and want. Drupal eight really reflects that. But in order to do that, in order to in order to really kind of embrace the modern web environment, it's made a shift to a truly Object Oriented Architecture. And, and changed the basis of its underlying technology into two of the of the leading web development frameworks, which is respectively Symphony and twig. So Symphony is the fundamental software development framework, which has been an alternative to say Laravel, if you're familiar with those things, twig, is the templating system. Previously, Drupal had its own templating system, they're now using a third party system called twig, which is which is actually really nice. It's the same one that's used in using craft and others. So these are the major the major players in this. So in a sense, Drupal eight has aligned itself with the rest of the industry Symphony is is preeminent in its world, as Drupal is in the museum's well, that I've just talked about, and twig ditto, there are alternatives. Sure, but these are these are absolutely industry standard bits of kit. And they do absolutely align with with what people think, should be used for modern web development. So that's the thing, we're moving into these two completely new technologies. And that's, and I'm making the shift from seven to eight, a very big deal. So it means you've got to convert in moving from seven to eight, you've got to convert everything to work in accordance with Symphony under the hood, with twig for the front end templating. So essentially, you've got to rebuild your front end, and you got to rework your back end. And it's not, it's not a sort of push button process by any means.
Unknown Speaker 19:13
We talked about Drupal eight into Drupal nine. And it's a funny thing that it's called that it's a whole number shift, because in many ways, it's it's not a very big deal. But the reason that they're calling it a move from age nine is because it corresponds with a change in this underlying software platform called Symphony. And there are breaking changes between Symphony three point x and the new Symphony four. So they couldn't they couldn't just keep it as Drupal eight, but actually moving from Drupal eight to nine as much better content in more detail. That's really not a big deal. It's the seven to eight, shift, that is the big deal. And because of that Because of these changes that they've made to put themselves on top of Symphony and twig, it gives them a roadmap, which is very secure, and it's easy to anticipate. So they're just going to move in lockstep with the rest of the industry, a symphony and twig, enhanced themselves. And it's unlikely that in the foreseeable future, there would there would be any similar architectural change in Drupal, as it is now between seven and eight. If we look at the benefits of Drupal nine, because nobody's going to be using Drupal eight very much longer, but if it's Drupal nine, you get better support for new technologies. So this whole thing about modern, responsive websites, the experience for content editors is better. I would say that this has never been a good feature of Drupal, and it's still far from ideal, but it is a bit better. The performance for end users is going to be better, it'll be faster and more responsive, ongoing long term support, and a clear is clear forward path. And all all the trimmings that go with that. So you do get you do get positives, if you don't want to upgrade, so clearly what we're saying. And we can talk about this in more detail in the, in the q&a session, moving from 70 is a big deal. And it's going to take quite a while and it's going to cost quite a bunch of money. So if you don't want to spend that, what's your option, while you can move from Drupal seven, something else, well, that's going to be a big deal, also, or you can stick with Drupal seven. Now, if you don't have, if you don't have a very ambitious development program, then that may be something that works for you. And with Drupal six, there was a long term Support Program people people can pay, and they'll get updates to Drupal six, which includes security, updates, and so forth. There is a plan to put something like that in place for Drupal seven. And I'd be very confident that that that that would be possible. But of course, it locks you into something that sooner or later you're going to want to get out of and which will not be a hugely productive platform for large scale long term development. But it is it is feasible. So if you've got a website that isn't going anywhere very much, or you don't have the budget to improve anytime soon, then you can pay a relatively small amount of money probably and and keep it with Drupal seven and and get the benefits of security. And so it has to be said that arrangements for this are not yet finalized. So I'm talking about something that will exist in theory. And I can't I can't see why it wouldn't exist, there's going to be too much market demand. But, but it's fair to say that the arrangements aren't actually in place yet. So that's just saying what I just said that there is a bunch of support going to be provided for Drupal seven. And yo on what commercial terms it's not yet clear. Um, so that possibly going to rebrand it as Drupal classic. But we don't know about what's involved in upgrading from Drupal seven, we can talk about this in more detail in a minute that we support for these things. We've started work on migrating from Drupal seven to Drupal nine.
Unknown Speaker 23:49
And Matt and Ben have been involved in some of those projects. So one of the projects that we got a fairly substantial website for medium size, cultural organization, they got 158 different bits of that website are going to need to be reworked in one way or another. And all the front end code is going to need to be reworked. There are some tools for migrating again, Ben, Ben in particular has good experience with this content migration and so forth. But the scope is quite limited. In our opinion, and again, we can talk about this. If it's a large website and presume it's a large website, because you're doing this in the first place, allowing less than six months is going to be it's going to be pretty tight, depending on the size of your team and their ability. But if you extrapolate back from that, if you want to hit the November 22 deadline, then you're going to have to start in May 20 to 22 are the absolute early absolute latest, but the earliest start date is now you can Get on with us now. Starting out is going to be advantageous a because if you're still fiddling with your Drupal seven site, then that work is going to need to be migrated. And that's fundamentally slightly wasted. But also, because this is a big thing, because it's Drupal developer resources, they're not that thick on the ground. So if you're relying on being able to hire a large team to do Drupal work quickly, then you may you may be disappointed if you wait too long. How much effort? Yeah, we were still working on our the flagship seven to eight project. And we can talk a bit about this, an equivalent project we worked on took about 290 person days is really quite a lot of time. And it's these things are quite difficult to estimate. Because it's all fiddly, and the devil is in the detail. But a preliminary survey can give you an idea of the scope of the challenge, we're talking about how did we go about doing them? opportunities. So if you, if you are going to go down this route, then you've got some some good opportunities, never let a good crisis go to waste a lot. So you can revisit the way you organize your content. Drupal eight, nine, do have better alternatives, particularly for pages, the way the page content is organized in website, you can improve your editor experience, so it was a good thing. It's much neglected in web development. And then the user interface twig is really good, and should be a good upgrade. And you should be able to, to think in relation to the upgraded projects, you should be able to look at the interface and come up with something that that would be a better version of what you've got. Now. Since you're gonna have to rebuild it anyway, you might as well. So here's the summary, just very briefly. All these things going to need to be upgraded or replatform. Sooner or later. Ideally, you do it in time for the deadline. seems unlikely that deadline will be extended, but I suppose it could be. And you've got to, if you're not going to do that, then you need to think about how you're going to get support. In terms of alternatives, it's obviously worth thinking about what the alternatives Drupal might be. But we're not, we're not sitting here thinking oh, no, there really are lots and lots of other good ones, for the majority of Drupal websites. And the new versions are perfectly good. And they do have a long term future. So that's reassuring. And having settled on, if you if you are going to do that upgrade, then it is it's it's a major project. It's not, it's not a couple of weeks work. And at the very least, if you're going to have to obtain a budget, then planning needs to start as soon as possible. Because if you if you say you got to start in May 22. And you got to get budget for that, depending on your budget cycles, you may need to start, you may need to have a considerable run up in order to acquire the necessary resources. So that's the context. That's why because of this research, which some of which at least was quite a surprise to us, when we did it much earlier this year.
Unknown Speaker 28:39
That's why we that's why we set up this workshop because we felt that that people really need to understand about this and get onto it. So I'm not going to go into the q&a session, I skip this bit. Okay. So let's go back. So,
Unknown Speaker 29:13
right, okay. So I've got some questions that I've pre prepared here. I'm gonna have a quick look in the q&a. How's that work? Um, sorry, we need to look in the chat.
Unknown Speaker 29:36
I don't think we've got any questions in the zoom chat yet as far as I can see, but correct me our hosts if if I'm wrong. So yeah, I think Alex plow ahead with
Unknown Speaker 29:51
Okay, boy, oh, Blimey, sorry. Right. So all right, let's some. Let's see. So, um, I'm going to ask this question. to Matt and Ben. Um,
Unknown Speaker 30:04
chat is now. Right. And there's a new message. Oh, Tina. Okay, Tina, you've got a question. Can you type it up? Speak it.
Unknown Speaker 30:22
Sure. Oh, hear me, okay.
Unknown Speaker 30:24
Yeah, yes.
Unknown Speaker 30:25
I'm sorry if I missed this, but do you recommend going from Drupal seven to eight, and then nine, or Drupal seven to nine.
Unknown Speaker 30:38
So currently, and I'll let Matt speak for himself, but I would say my recommendation would be to go to seven to eight, and then to nine. Partly that is a sort of at this moment in time recommendation, because Drupal eight is still much more mature than Drupal nine is Drupal nine has only been put into stable release recently. And in the experience I've had trying it out, there are still some things that aren't entirely up to date, both in terms of kind of contract modules, and some supporting infrastructure. And as Alex said, We don't anticipate moving a site from Drupal eight, Drupal nine to be particularly onerous, as long as you haven't written a Drupal eight site that for some reason is using loads of deprecated code for Drupal nine, which is quite hard to do. And it shouldn't really be that much more effort than just doing a point to release. So I would say seven to eight, then eight to nine, but I'll let Matt weigh in with his own opinion.
Unknown Speaker 31:40
We probably wouldn't be doing our upgrade until next year. So maybe April, May. And from what I was reading, it seemed like that was the recommendation before but now. I think on the Drupal site, they were saying you can go from seven to nine, there are some instructions, because the difference between eight and nine won't be too big, right?
Unknown Speaker 32:06
But yeah,
Unknown Speaker 32:07
just do you wanna comment? Yes.
Unknown Speaker 32:09
You're,
Unknown Speaker 32:11
you're correct in what you've read that the upgrade for me tonight will for the most part be trivial. The reason it would be better to go straight to eight first is is the same reason that blocked a lot of people from moving Drupal eight when it first came out, I think Drupal eight Drupal eight adoption, and we didn't start going up for maybe one to two years after it was released. The reason you probably not retraced Drupal nine is the availability of any contributed code and you contributed modules, plugins extensions that you would need. I think there are some that still aren't a third, No, none that springs to mind. But I know there's one that I've seen in this last week, that still hasn't been marked as Drupal nine ready. And the other thing to know is that there are tools available when you're building a Drupal eight site that will say, hang on a second, you You shouldn't be doing this, because this will be incompatible with Drupal nine, like Ben said, you know, you get notifications for a substantial amount of deprecated code. So an agency or a partner who is who is helping move to Drupal eight, then to Drupal nine will hopefully be able to, to make that to ensure that the transition tonight is is painless. And ultimately a transition from eight to nine if if that's taken into account could be once two hours with the with the smoother upgrade path between the between the major versions. So yeah, sorry, that says along with me saying yes, eight and then nine at the moment. But like you said, when it comes to me next year, that that may have changed. And I think that ultimately it will come down to the the audits of any existing sites and the audit of any custom code or contributing code that would be needed on a new site.
Unknown Speaker 34:04
That's a good moment to to have that conversation. So it's about planning for Drupal seven upgrade project. So Ben, do you want to just talk about how we've gone about that? Because I think that was again, something that we discovered how to do.
Unknown Speaker 34:17
Sure, yeah. So so as Matt touched on there, one of the major factors right now, when you're planning out migration is the level of contract support. So when we say contract, this is very Drupal return, basically, the kind of modules that you download from drupal.org that someone's already written contract as opposed to say custom code, where it's code you've written or core code, which is stuff that comes prepackaged with Drupal. That is something that we've done as a first step with all the signs of you've migrated, and has been very useful because it will immediately flag up where modules don't either don't have support Or just don't exist. So a kind of good example from our perspective, because this is something that a lot of sites use is search. In Drupal eight Search API, which was a Drupal seven search module is the canonical search solution for Drupal eight now and other modules that you may have used in Drupal seven, such as Apache solar, or Samia do not exist in Drupal eight, or at least don't exist as the same modules. So factors like that are going to be the kinds of things I see as a question about some jobs. Well, the kinds of things that will immediately start to increase your cost of migration. You know, if you do a module audit, and you know you have a column for does this module, have a Drupal eight version and you see lots of ticks in that column, that's probably a good sign that your migration is going to be less complex. If you do that audit, and you see lots of crosses in that column, or you see lots of custom code in that column, then, then you're starting to kind of increase the cost of your migration. Matt, do you want to jump in on that?
Unknown Speaker 36:11
Do you have any extra
Unknown Speaker 36:15
without touching on the front end? Which are they we've got? We've put down as a discussion for later on. I think that pretty much covers it.
Unknown Speaker 36:25
Um, so Ben, just just apart from looking at the contract modules, what else did you look at when you came to do the survey for the recent project that we've been working on?
Unknown Speaker 36:39
So like I said, I think the easy bit is are these modules supported? The custom code is another big one. Because if you're writing custom modules, obviously, that code is going to have to come over to treat blades. There are some tools to help you with that, as Matt said, definitely one of the things that if you're a developer, you will want to have running alongside all your regular linting. And things is the Drupal nine support tools. So that while you're writing code for Drupal eight, it will just double check that you're not using anything that's marked for deprecation in Drupal nine, like I say those things are generally few and far between. So that's, that's probably not a problem, you're going to hit a lot, but worth making sure it's not a problem at all. And that's one of the bits where it's somewhat tricky to say, how how long that's going to take you because really, it depends on how much custom code you have, obviously, more and more lines of code equals more time. And it's also going to depend for either you or your development team, how familiar you are with Drupal eight, because it is a big shift. From Drupal seven API's to treat blade API's, there are some things that will carry over fairly unchanged, but there are also a lot of things that will effectively need completely rewriting. And that is another thing to be aware of is certainly if you have, you know, if you are a developer or you have in house developers, there's a sort of preliminary step to all of this, which is learning Drupal eight, because as Matt said, this is not you know, like five to six or six or seven. It's It's a whole new ballgame in many ways. And there's Yeah, there's there's some some learning to do magic and talk a bit about the kind of front end and how you might want it that that's a bit that I'm not so hot on
Unknown Speaker 38:36
the probably the front end, and is the Drupal seven was very, and Drupal six as well was very restrictive, let's say, in the way that it allowed you to do front end development, there were a lot of things that you couldn't do, there were a lot of things that were difficult to do. And we drink late, that's not a problem. If you've if you've got an experienced front end developer writing the best possible markup they can, you can use it. That will be fine. So I think from a front end perspective, again, it just comes down to an audit of individual components on the site and less than the other. And the only thing to really bear in mind would be that the markup given to you from Drupal eight is not the same as the markup given to you in Drupal seven and this this was a big sticking point when we were when we were looking into things like this and past agencies where where we've had to save big is that it was quite difficult to explain how you can't just sort of take the old front end and drop it onto the new site. Again, it comes down to what Ben said there is a there's deprecated functionality, there's changed functionality. Ultimately it is for the better. And when we get down to the front end tip section I may explain a little bit more in depth, but we've got a relatively well proven way That kind of removes a lot of the hurdles from from updating the front end of the Drupal site, which is basically removing Drupal eight from the equation for a sizable chunk of the development. Not going headless. But I'll explain a bit more in depth later on.
Unknown Speaker 40:22
So this question that she asked about cost? And I think the the, the answer, the cost is, obviously, it will depend, it will depend on on three things. It'll depend on how complicated your your existing site is, it'll depend on how long therefore, that work is going to take. And it'll depend on at what rate you're buying, you're buying the work, or whether you're able to do it in house. All we can say, I think is that the best ways to shine the light on this is by doing an audit. So rather, you just can't look at a big, hairy website and say, Oh, that's going to cost you this much money. It'll take as much time. But there are ways and we've sort of sketched this out a tiny bit. in the chat. So far, there are ways of doing an audit, which can certainly throw some light on it. And we're busy as fast as we can, acquiring knowledge of doing this on existing projects, so that when we come to answer that question, again, for the next for the next clients, that we'll be able to give them much more definitive answer. But the the key message, I think, is, this isn't something that's going to come out of regular maintenance budgets, this is a much, much bigger project, it'll have to be funded on a one off basis. And it one would hope that it wouldn't be the same cost as redeveloping the website. But it's certainly going to be order magnitude, that amount of money. It might be, it might be somewhere between half and half and the whole amount. But it's also depends clearly, on how much you're going to take advantage of the opportunities that arise. So it's one thing to do a kind of screen for screen rebuild. And just accept that you'll take whatever benefits you can as you go. And another would be to do more thoroughgoing things, actually, when we can rethink the front end here. Because that's, that's the opportunity with replay. So there'll be a bait, there'll be a base cost below, which you ain't going to be able to, to manage. And that's going to be substantial, a substantial cost for a big website. But then you can you can imagine, then adding some some extra resource and budget, and getting something which might be substantially better in the process. But but in all cases, you're only going to be able to get a handle really on the budget question. By by doing a preliminary survey,
Unknown Speaker 43:16
just to just jumping on the planning there as well, Alex does stress the importance of good planning, with an example is, is also being able to plan and look at features that perhaps don't get used on your existing sites that perhaps you don't want to rebuild. As an example, I worked in the last sort about two years ago with a large football club in the UK who are planning with the site saved. I think it was it was double figures in the 1000s of pounds, it was 10 or 20,000 pounds by by auditing their site planning their site and going I don't nobody uses this or not very many people use this. It's not worth the outset the outline outline cost. So I think planning to a plan shouldn't necessarily just be how to transition It should also be a plan for Do we need feature parity between our old site and our new site or have our business goals channel have have a cultural goals change business goals changed over the last 10 years that we've had this interesting site?
Unknown Speaker 44:23
Definitely. And I think that's maybe a level of audit that I skimmed over a bit but I should touch on is, once you've done that high level audit of, you know, module by module theme by theme, then also looking at your your content types, your blocks, things like that the actual elements of the system, is also worth doing. And as Matt said, that can then potentially flush out things where you look at you look at your content types and say, actually, we made these three content types. They're basically just the same thing, but they've got one slightly different field. Maybe Maybe we simplify that Make it into a single content type. Maybe we don't need all of these taxonomies that we need over here for, you know, some projects that we did a few years ago. And now we're not using. So that's definitely a good way to find that dead wood, I would definitely suggest automating that as much as possible, if you don't already have that information. And I wrote a small tool called content outline. That's there's a sort of very early version of that up on drupal.org. Now, which you're welcome to try out. And I did that because I didn't want to have to go through every single content type and list out all the fields. So it gives you a kind of breakdown of what content types you have, and what fields they've gotten all of your blocks and views and things like that. And this, I'm going to seamlessly segue now into Sarah's question, and how long it would take. Because it really comes down to how much you've got in the site, I would say in terms of scale, it's we're not we're talking days rather than hours, but probably not weeks. You can take this a very long way. And when we've done this, the initial audit has been very much on the module kind of content type building block level, because we've done these projects in an agile way, sometimes when we get to specific stories. So for example, if we're working through custom code and custom modules, then we might break that down even more into the level of specific features specific functions and bits of code. But I would say for an initial audit of the site, it's it's going to be in in the scope of days, depending on how much you've got to audit. And yet how, how far you have to take that really
Unknown Speaker 46:44
let me move on to another question that Roger asked in the chat earlier. So what about alternative architectures? Clearly, Drupal now supports different ideas about how a website might be organized. So questioning headless Drupal, things like that. So Matt, Ben, do you have any thoughts on those possibilities?
Unknown Speaker 47:08
I, I'm on the fence with headless Drupal. However, I do like the idea of static sites, they remove a lot of the complexity from the front end. And they're also by because in the very nature of what they are, they're a lot more secure. Because you're not exposing your PHP site to the world. There are alternatives to Drupal in that respect. Drupal may or may not be the best tool for that. I couldn't answer ask it and give a definitive answer, I'm afraid. I would strongly recommend against Gatsby with headless Drupal. Because in my experience building, the Gatsby site has tended to crash Drupal because it tries to do things too quickly. It's it's a definite avenue that we could take. It's one that I've been thinking about one of our existing projects to do partial headless. But the other thing is for for for a lot of this for lots of museum sites say that, you know, they have quite large collections, which doing with a static site isn't particularly it doesn't lend itself very well to a site the who's who's up, which is built by calling content. So we've got 100 or 200 collection objects, that's fine. If you've got 1000. If you've got 2000, it starts to slow down very quickly. And all of a sudden, you want to make one text change to one item, and you've got to wait an hour for the content to rebuild. So there's that. Other options, things like headless Drupal with something like react or view? I've done that before. It's okay. The main problem you've got there is that you are in my opinion, kind of abusing the web platform, you're building your website on the most fragile part of the web, in JavaScript, so you do run the risk of your entire site breaking for no good reason. And you also it also shows it also means a lot of people can't access the site, especially people in rural areas, which may be more of an issue in rural areas in the States. I'm not completely sure what the general internet in general internet connectivity is like in in rural areas in the States. You do risk limiting the amount of people that can see your site.
Unknown Speaker 49:48
I was I was impressed. Ben. Matt, with the stuff you showed me using fractal as a way to develop the front end you just want to say this about that because I That seems to be a really positive development.
Unknown Speaker 50:03
So yeah, this this was what I was alluding to when I mentioned about decoupling the front end from Drupal in in, in a way. And what I mean by what I didn't mean by that was was we run headless Drupal, it's we develop the front end for Drupal site separately, that's all called fractal, which I used at previous agency and liked so much that I ended up becoming one of the maintainers on it. So I thought I'd say that to front load my my potential bias towards it. But ultimately, what it means is we do the front end in a completely different tool, we do it from the front end, it's all called fractal. And you don't need to know Drupal to use this tool. And this benefits us because we've got some front end developers who are at the moment learning Drupal, who are very, very small front end developers, but have not had the exposure to Drupal, that perhaps someone like myself band or or some of the other developers have had. And what this means is they don't have to learn Drupal before they can start delivering value on a project I developers has has built maybe bad luck on the current project that Ben and I are working on maybe maybe a third of the core components for the Drupal sites, and she hasn't had to touch Drupal yet. Which I think is going well, it is going well. And then with the flexibility that Drupal offers us, you know, someone who's got more Drupal experience can look at the markup that that Emily has written. I think every maybe in the audience. So say I would say wave if we were in person, that's gonna be useless now. We could we could look at the markups and the styles that Emily has has done for us, and then someone would have been more Drupal experience and go right, this is the best way to integrate this in Drupal eight. And I can go off and make some twig templates. And Ben can go into the views that he's building and Drupal eyes, the markup required. And all the time this is going on. Emily is using her more advanced front end skills to go and build, build up the next thing using you know, the minimum markup possible properly accessible semantic markup, and she's not letting Drupal get in the way. Now, this is something that we couldn't do with Drupal seven it was I mean, we tried it in various ways, it was practically impossible because you needed to know exactly how Drupal works. With replay, you don't have that problem. The other thing is means is that on the site that we're building, if there is any scope for a micro site, for example, that use it that needs to look the same, but perhaps has a different technology behind it. Perhaps it's a slim Symphony project or a node thing or react thing. We can reuse those styles without having to involve Drupal in the mix. Because all we need to do is grab the CSS files that have come from Emily's fractal work and drop them into a new site. So that's what it's all about with with with a slightly different workflow that we've taken on the front end. So I've just seen a really saying Hello, This made me smile that we've we've got people who have who are learning Drupal for the very first time, who have hit the ground running on day one on an upgrade project and have been able to deliver value from from the offset, which is something that we've never ever been able to do up to this point. I think historically on Drupal seven projects that I've worked on, when I've been doing the front end or the back end, the front end, front end generally started two weeks or a month behind, maybe one sprints, two sprints behind if you're working in a in a scrum fashion. And we've not had to do that now, which is great. And this front end is now portable, we can we can move it to a to b to c.
Unknown Speaker 54:10
as well. While we're talking about approaches, I just want to jump in quickly while it's at the forefront of my mind. So obviously, we're talking about migrating to Drupal and other systems and how you might do that. But we are talking about this from the perspective of this is a site that we're currently using and that we currently care about. And I know there are potentially people out there who have Drupal seven sites that they're still maintaining, but they don't really touch the CMS side. So I do want to propose that there's another solution potentially here which is flattening your site and just making it all static, which is something that we have done in the past for clients. I'm not sure if we've done it for anyone recently. But that is an option. If you're thinking oh no, I've got a Drupal site. I don't want it to go If I don't want it to go out of securities, what words in order, but I don't actually need to CMS functionality is there are lots of tools out there, that will just create you a static copy of that site, you can stick it up on some some cheap hosting somewhere and never have to worry about the security side. Or you could you could build it in MS Word right here, front page is still quite popular. So there are other options out there, if it's not a site you necessarily care about right now, but you don't want to have to deal with security implications.
Unknown Speaker 55:38
Just put a link in the chat for the briefing presentation that I I just I gave earlier before we got to the q&a session. Tina observes quite rightly in the chat that flattening is hard for sites with lots of interactive components in custom code. Yeah, it's absolutely true. But if it's it doesn't have that then there's been says that it can be an option. Yeah dependent side. So I really, I think anyone who's involved in this and whatever way, the sooner you can you can start looking at what's involved do the kind of module audit and review that Ben and Matt described earlier and and consider your options this the best already. And then past can become clearer as a result of that. We probably were not at 629 in my timezone. I guess that's probably 129 and yours. For those of you on the East Coast, that any other any other final questions quickly. Put them in the chat.
Unknown Speaker 56:46
I just like to thank everybody for coming out. It's been really good. I'm around on the the various slack channels on MSDN. So we're happy to to continue this conversation via that'd be great. It's been really interesting for us. And yeah, thanks. Thanks so much. onward.