Developing the latest version of Lullabot.com

Transcript

Matt:

February 7th 2019, it's the Lullabot Podcast! Hi everybody, it's the Lullabot podcast episode 231. I'm Matt Kleve, a senior developer at Lullabot. With me, as always, co-host of the show, senior front end developer, Mike Herchel. Hi Mike.

Matt:

Hey, we're live on site.

Mike:

Yeah, at beautiful Palm Springs, California.

Matt:

Yeah, as we do once a year, as the Lullabot team gets together, has a retreat, works together face to face, talks about building the business and working on our work, and also having some time by the pool.

Mike:

When we do that, we corral everybody. We corner them and get them to speak into a microphone.

Matt:

Yeah, also one important thing is happening this week. What is that?

Mike:

We're launching the new Lullabot.com.

Matt:

Lullabot.com, and we have three experts who have been working on that project with us, and we're going to learn all about Lullabot.com.

Mike:

We're experts. I am one of them.

Matt:

Oh crap, you know something?

Mike:

Yes.

Matt:

You're important this time.

Mike:

Yes.

Matt:

Okay. First up, we have senior developer coming from the beautiful island of Majorca, Spain, professional sunbather, knowledge of everything JSON API, we have Mateu Aguilo Bosch. Hey Mateu!

Mateu:

Hello.

Mike:

Next up, we have Lullabot's CTO, who is also a senior developer, and does a little bit of everything. She has basically shepherded ... She's written, what, CCK and D7.

Karen:

I didn't write it, but I [crosstalk 00:01:38], and also the calendar module [crosstalk 00:01:42]

Mike:

Yeah, you did the calendar module and date.

Karen:

Date and calendar, I did, yes.

Mike:

Yeah, all of that stuff.

Matt:

Any module you liked, it was probably Karen.

Mike:

Yeah, pretty much yeah, and the nicest person probably in the room, I would say, looking around here. We have Karen S from Normal, Illinois. Welcome.

Karen:

Hey there, good to talk to you.

Matt:

Also with us today, a newer addition to the Lullabot team. We have Putra Bonaccorsi coming from ...

Putra:

Sewell, New Jersey.

Matt:

New Jersey.

Putra:

Nowhere.

Matt:

Okay, is that near the Jersey shore?

Putra:

Sort of, about 30 minutes away.

Matt:

Nice.

Putra:

It's not too bad.

Matt:

Awesome. So Lullabot.com, we launched Lullabot.com. How cool is that? It's a new website.

Karen:

Excited, yeah.

Matt:

Why is it important? What did we do different? What's going on? Tell me about Lullabot.com now.

Mateu:

One of the first things about Lullabot.com is that we moved away from a decoupled approach to a full on Drupal approach.

Matt:

Yeah, we've been on the podcast, gosh, I don't know, it's been a year or two. We had Sally and Wes and some other people talking about our decoupled Lullabot.com, and the really interesting thing that was built out there. So we're moving away from that? Is there a problem with decoupled? What do we do?

Mateu:

Oh gosh, no.

Matt:

I mean, you're mister JSON API, so.

Mateu:

No, there is not a problem with decoupling, but decoupling is not the perfect fit for every project, right?

Matt:

I think some of that Lullabot.com previously was like, hey, wouldn't it be cool if we could do this, right?

Mateu:

Yeah, there was some of that.

Matt:

Yeah, and it was cool.

Mateu:

I think it was legit, right? We were trying to ... if we want to push it forward as a community, right? Sally is working on the admin UI initiative. I'm working att he API first initiative. We need to have hands on experience. We did that very early, and a way to do it is to have yourself a project. We learned a lot. That happened maybe two years ago, and-

Mike:

Yeah, no, it was longer than that. It was 2015.

Karen:

It was really then, yeah.

Mateu:

Wow.

Mike:

I think the Lullabot.com was one of the first or if not the first decoupled React Drupal site.

Karen:

I think so, yeah. I think that's right.

Mateu:

The idea was that now that we have more experience, because we had a lot of decoupled projects at Lullabot, we reevaluated like, is it right to keep maintaining this site that was very useful for us as a learning experience? Also, we had a really cool site for many years, and the answer was maybe not. Maybe it's easy to maintain just a single website, just one consumer with a regular D8 installation.

Mike:

Yeah, that makes sense to me, and yeah.

Karen:

We took a different approach on this site, and the goal wasn't to have the bleeding edge anything. The goal was to have it as easily maintainable as possible as much as possible, no custom code, straight out of the box Drupal. All the way through our project of putting this together this time, that was our goal.

Matt:

How successful was that?

Karen:

We got pretty darn close. We have three custom modules, one of which we really don't even need that I could get rid of, so we really have two custom modules for the back end. The front end stuff, we do have custom stuff on the front end, but we have tried to avoid, everywhere we can, doing anything custom. In fact, if we needed something that we couldn't solve in Drupal core or Drupal contrib, we made a contrib module. We have made several modules that we are contributing back.

Putra:

Yeah, and just to piggyback on that from what Karen is saying is that one of the goals of this project is that we want to give the content authors the ability to easily edit the page without having a developer come in and help them with that. So it's really imperative for the site to be user friendly in a way that the content authors can go in and rearrange the order of a particular section and be able to publish that fairly quickly.

Mateu:

I think that that's key to why we would want to move away from it because if you have a decoupled, this JavaScript frameworks are not really built for you to control the layout editorially, or without pushing code because you cannot assume anything about the presentation, because you may be pushing your Drupal content to many different consumers, so [crosstalk 00:06:17].

Matt:

So you might just say that we had a website and we needed a system to manage our content?

Mateu:

Yeah [crosstalk 00:06:24].

Karen:

I feel a song coming on.

Mike:

I think we're going to play that song.

Karen:

Yeah.

Matt:

I don't know that that's necessary. What was custom? What did we need to do on the back end to make it work?

Karen:

Very little. The migration was custom, not surprisingly.

Matt:

Oh, as migrations are, right?

Karen:

As migrations are. You really can't do a migration that isn't custom. We have some custom code related to the way that we arranged things in the node form. We could live without any of that, but we have a little bit of custom code pushing that stuff around. One thing that is custom and it isn't even very custom is layout builder. We've got a custom module to define all our layouts because now we have layouts in core, and we just needed a custom module basically to create the configuration around that and some ability to do things like create some custom settings.

Mike:

Yeah, so let's talk about that a little bit. There's a little bit of work that has been done to layout builder to make that a little bit more user friendly.

Karen:

Right, correct.

Putra:

Mm-hmm (affirmative).

Karen:

Layout builder is super great and really interesting.

Mike:

It's awesome.

Karen:

It was really just coming into our core at the time we were getting this project off the ground, and-

Matt:

Before we go too far, what is layout builder actually doing for us?

Karen:

Okay, so layout builder is relatively new in Drupal, and it's-

Matt:

It's in core now, right, in Drupal core?

Karen:

It's in core now, and it's the panel's idea, if you've used panels in Drupal 7. The idea that you have a grid and regions of a page, and you have a UI that an editor can use to move things around and place it on the page, but this is all in core now, or coming into core.

Mike:

Yeah, and it goes beyond that too because it's on the front end of the website, so when you're moving stuff around, you're moving stuff around on the front end of the website as opposed to dragging around little gray blocks. In addition to that, you can add in new sections where before when you defined your panel's layout, you're stuck to that panel's layout. You can create new sections and drag them one on top of the other, and then within those little layout sections, you can add your blocks within there. It is awesome.

Karen:

Right, lots of control, and that's exactly what we wanted. The interesting thing about Lullabot is obviously we're a technology company. In the past, all the people that maintained the website were technology people, and so it really didn't matter whether it was easy to use UX because we were all a bunch of nerds and we write code to do things anyway. But now, we've got this really awesome head of marketing who is not a technology person.

Matt:

Hi Ellie.

Karen:

Who we love, but she's not a technology person. She needs something that's easy to use that she can maintain. She doesn't need to require a code push every time she wants to change the wording on a block or something like that. So we wanted to get a lot of power into her hands, and that was one of the reasons for picking this as our new solution.

Mike:

Yeah, and there's some custom code within that we wrote for the layout builder where you're adding your custom CSS classes to those layouts.

Karen:

Right.

Mike:

Can you talk about that a little bit?

Karen:

Yeah. We're going to be posting the code that we used. We're going to put all the code that we've used in a public place. Some of it is in contrib modules, a few things are not. The custom layout doesn't lend itself to being a contrib module because it's very specific to our situation, but it's something that people could use as a guide if they wanted to implement something like that themselves. So what we did is we added to what comes out of the box with layout builder, the option to add some drop downs, so as the editor creates a section, she can do things like add a title to a section and define classes that she wants to apply to that section.

Mike:

Yeah, and we actually have instead of typing in a class name that she might not remember, we actually enter those class names into some custom text [inaudible 00:10:30] vocabularies, and then we hooked up the drop downs so it auto completes. We're just using the select to widget, and so she can start typing something and it'll automatically complete, easy to add multiple classes. We have separate taxonomy vocabularies for both your title class and the layout class, so it's really a couple utility classes that we have defined in CSS, and then we've added to these texts.

Mike:

Taxonomy vocabularies are to constrain the grid. If you want to make your layout constrained by one by having a little bit of extra space on each side, we have some margin top and margin bottoms, and some padding tops and padding bottoms. So it's really easy for her to go ahead and start creating these landing pages just using Drupal's UI, which is pretty awesome.

Mateu:

Reminds me a little bit of the skinner module. Do you remember that?

Karen:

The which module?

Matt:

Skinner?

Mike:

Skinner, yeah.

Mateu:

The skinner module.

Karen:

I don't know that one.

Mike:

I remember a little bit, yeah.

Matt:

What did it do?

Mateu:

Well, it was similar, but for Drupal 6, I think.

Mike:

Something like that.

Mateu:

And without layout builder.

Mike:

Okay, but one of the benefits is that because it's a drop down, you're not typing in something. You're not going to get the CSS class name incorrect. One of the things that we actually have on our to do list is to create a view showing all these taxonomy terms with some documentation. That will be live documentation living in Drupal. So Karen, you said that we released some contrib modules.

Karen:

Yeah, and I don't have the list of all the contrib modules with me, so I'm going to have to try and remember.

Matt:

What was your favorite one?

Karen:

I don't know about favorite, but I'll tell you one of the things that we ran into with layout builder. Again, this is an early problem with layout builder being a relatively new thing, is if you use layout builder out of the box as it comes in core, one of the things you'll find is you go to the page where you can select your section and put blocks into them. You click the thing to add new block to the thing, and it would just take forever for this list of blocks to come on, so it was very ... not impossible to use, but that made it very difficult to use.

Putra:

Because it turns everything into a block that can be inserted right in the page, right?

Karen:

Yeah, because basically, the premise of layout builder-

Putra:

Exactly.

Karen:

... is everything is block, and you're inserting all these blocks. So you can make a view block, you can do a block, block, you can do a [inaudible 00:13:10] reference block, lots of different kinds of blocks that you can do, but everything is a block. Layout builder also adds ... When you turn layout builder on, one of the things it does behind the scenes is it creates a block for every field on every content type. You aren't even aware of it, but suddenly, you have a huge number of blocks in your system. Drupal then has to load all those blocks every time that you're trying to process something, and because of the huge volume of blocks, it was just very slow.

Karen:

It turns out that the problem that needs to be solved is not loading all those blocks all the time. This is actually a problem that we are simultaneously working on with another projects. [Hawkeye 00:13:55] was the one that came up with the fact that the fundamental thing that was slowing that down was the main list of blocks, the system list of blocks. If we could just reduce the size of that system list of blocks, suddenly, everything works faster.

Karen:

So I created a module called block blacklist. Basically, it shows you all the blocks that you have in your system, and you can just identify the ones that you know you're never going to use anywhere. Typically, for instance on Lullabot.com, we're only using layout pages on one content type. We don't need all the blocks for all the other content types. Even the content type that we're using, we don't need all the fields on that content type, because they don't all need to be placed within the grid.

Putra:

Definitely, yeah.

Karen:

So you can use this block blacklist and get rid of all those blocks in your system, and then all we have left are the blocks that we actually care about and want to to use. It speeds the thing up enormously.

Putra:

Yeah, it's incredible. I can definitely see a difference between before we actually installed the module and then the after performance of that. The user experience of adding a block to a page layout is a lot faster as well too for the content authors.

Mike:

Mateu, you released something into the wild. Is that correct?

Mateu:

Yeah.

Matt:

That was your long, flowing locks on the beach?

Mateu:

That as well. I'm talking about the podcast module.

Matt:

The podcast module? That sounds interesting to somebody who has a podcast.

Mateu:

Straight out of core, there are many possibilities to build an RSS feed, right?

Matt:

Views.

Mateu:

You could use views. You could also use the regular NTT system.

Matt:

Can you make page call back with custom queries or something?

Mateu:

You could do that as well.

Matt:

I suppose it would be a route though.

Mateu:

Yeah, I guess. The thing is that there wasn't anything that would allow you to add the custom fields that you need in a podcast RSS feed. That leads to a very common problem. That is that we need to go from a Drupal defined structure that will be different on every side because it will depend on the content module that you have, and then map that to a known format. We run into that problem in many different areas, because there are known standards for almost everything, and one of those things is podcasts, so-

Matt:

There's a standard way the XML should be built for a podcast feed.

Mateu:

Exactly, and you need certain metadata.

Matt:

There's the title and the description and the ... I don't remember the field names, but-

Mateu:

Then iTunes will want their own thing as well in the podcast.

Matt:

It was the iTunes module and other things in the past that did that kind of thing.

Mateu:

Yeah, but the research that we did showed that the support for Drupal 8 on those things was not great, and the things that were actually working, they didn't meet the things that we needed to do like namely have all the iTunes fields constituted to show up in iTunes. So basically what we did is we created an extension to the way that RSS fields work in using views, but adding multiple fields to map the podcast [inaudible 00:17:38].

Mike:

Yeah, so to configure it, you just create a view, and there's options for ... it's called iTunes RSS or podcast RSS, or something like that. You have your ... what is it? You have your role formatter, and then when you open up the settings for that, there's a list of ... you have drop downs representing each field that you have in the view for each of those iTunes fields. You just go and you just map one to the other. You can use whatever content module you want. You can just go ahead and add a field into your view, and then hit the settings, and then move that over to whatever RSS field you want to put it and it just works.

Mateu:

Yeah, what I like about the approach is that it's very Drupal. It gives you the flexibility of do everything at any time.

Mike:

Anyone can use this, and this is the podcast module which, to me, it was really impressive that the podcast name space was even available.

Matt:

Shut up. Seriously, it's drupal.org/project/podcast?

Karen:

I can't believe it, yeah.

Mike:

That's exactly it.

Putra:

Wow.

Mike:

Yeah, and no one registered that.

Putra:

That's crazy, yeah.

Matt:

Yeah, project squatters beware.

Mateu:

Yeah, but there is another custom module or contrib module that I'm even more excited about than the podcast module. That's the one that Mike wrote.

Mike:

Yeah, the click link module.

Matt:

You wrote a module?

Mike:

I did write a module. I'm gunning for you. I'm going to take your job, Kleve.

Matt:

Oh, oh. What is it? Tell me about quick link.

Mike:

Yeah, so it's called the quick link module, and it's pretty awesome. GoogleChromeLabs released this little job [descript 00:19:26] library called quick link. At its core, what it does is you load on your library, you pass some configuration object, and what it does is it looks at all the hyperlinks that are in your page's view port. In the background, after the webpage is idle, it'll start pre-fetching those, so it'll store those in the browser cache. What happens is when you click on one of those links, it will load instantaneously because it's already downloaded, so your time to first byte is five milliseconds. It's almost an instantaneous page load. As you start scrolling down the page, it uses a JavaScript API called intersection observer to load in any new hyperlinks that come into the view port, and so it'll just do everything.

Mike:

So the module that I wrote, which is my first ever contrib module, I basically created a little wrapper for it so you can configure a lot of different options within the configuration screen. There's a lot of really cool stuff in there like for example, you don't want it to pre-fetch the log out link because then you will just log out as soon as you log in, and these things like that. We also don't have it pre-fetch whenever you're authenticated because when you're authenticated, you don't have that page cache turned on. You don't want to slow down your local or even the server.

Mike:

You also don't want to pre-fetch Ajax enabled links, so it looks for like the use-ajax CSS class, and it won't look at that. You also don't want to pre-fetch links to files. If you hyperlink to an mp3 file, you don't want to download. You don't want to pre-fetch that, so it'll use a little regex to look for a dot anywhere between one and four characters after that, and it won't download those.

Mike:

We had a patch from Andy Giles, who does a lot of Drupal commerce work. He ran into an issue where after he added an item to the shopping cart, it started a session. The session would bypass the caching, and so that was slowing down the servers. There's an option now that new, by default, to not load this library when sessions are enabled. So there's a lot of cool things like that.

Mike:

Another thing that I really like is there's a little debug mode. You check the debug mode, and it'll actually insert a little emoji after links that it's not pre-fetching. Then if you open up your JavaScript console, it'll actually tell you why it's not pre-fetching these links, so you can actually debug it pretty easily. It's awesome.

Mike:

I got some patches from Mateu right here, which is pretty awesome. I appreciate you looking at and reviewing [inaudible 00:22:27]. I also received some other patches, which the name of the person is slipping me. I'm sorry. I should edit that in, but it's pretty awesome. It just makes your webpage feel so much faster.

Mateu:

I would say to anyone listening to this and getting as excited as they should be if they're developers, to go to Lullabot.com, try it out, see if it feels fast, and then open the Firefox console or Chrome, whatever you're using, and see the network tab.

Matt:

Opera?

Mateu:

Not Opera, not Explorer.

Mike:

You can use whatever.

Matt:

Lynx?

Mateu:

Probably not Lynx. I don't know if they have developer tools for Lynx, but open the network tab and see how after a while, after things have been painted and everything, so it's not taking actual resources from you. Things start to load, and you see the request and how they get cached, and pretty great.

Matt:

So Mike, you said this was your first contrib module, right?

Mike:

Yeah.

Matt:

You've never committed anything to Drupal.org contrib server?

Mike:

I have some core commits. I've also contributed some patches to other people's modules.

Matt:

What is the system though like? Now you have a full fledged project, or how did that work now? How does that work these days?

Mike:

Well yeah, so pretty much anyone can name squat now. That's the way it is.

Matt:

There was an era where you couldn't do anything until you were officially blessed.

Mike:

Yeah, and that was really tough for people because the people who were actually doing the blessing, there wasn't enough of them. But now, you can go in and you can create a module, create a release for your module, but you cannot opt into security coverage until you get at least one module that has gone through a review process.

Matt:

Okay, right, sorry for the side bar there.

Mike:

No, that's really important for people to know.

Matt:

We're with the team that built Lullabot.com here on the Lullabot podcast. Coming up right after this, we're going to talk a little bit about building Drupal 8 in the modern era, things that happened, and a little bit about the front end. We haven't talked much about the theme and the front end. Coming up, right after this.

Speaker 1:

Whether you're learning how to build sites with Drupal, or diving into the code, there are community powered camps, summits, sprints, and trainings happening all over the world. Find all of these and more at drupilcal.org. Of course, if you want to boost your Drupal chops from the comfort of your own home, point your browser at drupalize.me, and stuff your brain full of carefully crafted videos and tutorials.

Lizz Trudeau:

Hi, this is Lizz Trudeau from the Drupal Association. Drupal Con Seattle is coming the Washington State Convention Center Aril 8th through the 12th. Register to participate in one of three robust new tracks, builder, agency leadership, or content and digital marketing. For more information, visit events.drupal.org.

Mike:

Welcome back to the Lullabot podcast. We're talking about the new Drupal 8 Lullabot.com which was just recently launched.

Matt:

The cobbler's children have no shoes.

Mike:

Hmm, no we have shoes now. These are some pretty awesome shoes.

Matt:

It happens though sometimes, right? Lullabot.com often gets forgotten with Lullabot who we're outside.

Karen:

We're busy. Everybody's busy.

Matt:

Yeah, we're building websites for ... So we weren't busy, or we've carved out time because this was a priority?

Karen:

We decided it was time to create a site that ... We know we're busy. We know that nobody's going to have time to work on it. We also know that the same people aren't always going to be able to work on it, so we wanted to create a site that was as easy as possible for somebody to just drop into, take care of whatever they needed to take care of, and then go off and do something else. So that meant pretty much straight up Drupal, very little or no custom code. As easy to maintain as possible was the goal.

Matt:

At the end of the day, it's a brochure website, right? We need a blog. We need articles.

Karen:

It's not really crazy fancy. Yeah, that's true.

Matt:

Right?

Mike:

It's like a heavy brochure website.

Putra:

Well, there's fancy front end stuff that we also introduced for this version of the website too. I did some more-

Mike:

We got a lot of front end. One thing before jumping into front end, there's one module we forgot to mention.

Karen:

Yeah, one of the things that came up as we were trying to figure out how we were gt lay out the Drupal 8 site is we had some pages on the current site that were an arrangement of funny grids like three across with a two across with a one across with a two across, that kind of crazy layout. It was basically what was dropping into the panels of that layout was basically the results of a view. So we wrote a module called views layout, and the idea is you just create a view as you would normally create it. You just say, “I want the view results to drop into this layout,” and now everything just arranges and drops into whatever layout you set up.

Karen:

It can be any kind of crazy thing. It doesn't have to be a nice three by three that you get out of the box with views. You can even do things like say, I want this crazy layout, but I want to leave one of these sections blank so that I can put something else in it, or whatever. It just was a fun problem to solve, and turned out not to be too hard to solve as something that you could do with the new layout system.

Matt:

They sound like actual problems you get on lots of projects. Like a design team comes in and says this is what it's going to look like, and then you're like, great, what happens when there's only five instead of six?

Karen:

Right. Well, I found myself doing things like creating a view and then saying put offset one here, put offset two here, put offset three here. I thought this is crazy. There's got to be a better way. So we can just create a layout and everything drops into the right place.

Mike:

Cool. Now as Wes Ruvalcaba walks into the room, we're actually transitioning to talk about the front end of the website, so you walked in at the right time.

Karen:

Perfect timing.

Mike:

You can join in over here with us and share a microphone. There you go. All right, so let's move on to the front end of the website. I guess we'll start off with Putra. You said we've got some cool stuff happening.

Putra:

Yeah. Well, I came in to the project when the theme had already been set up and all that stuff. I just came in, just add in some front end more of like [crosstalk 00:28:40].

Mike:

Front end awesomeness.

Putra:

Awesomeness, that's right. Special sauce, I guess when it comes to some of the end action on the website. We added some front end polish to some of the bland animations just to get some moments in the light for the users as well too.

Mike:

Some pop.

Putra:

Some pop for sure.

Matt:

Did you make the logo bigger?

Putra:

It's just kind of small, but I think that's what makes us special, so.

Matt:

So it's a custom theme, right?

Putra:

It's a custom theme that Wes put together, and we use scope to also process all of our assets. We also break everything out into separate [inaudible 00:29:18] and also separate files based on the section of the site that we want to load those assets on, and yeah, I think it came out really well.

Matt:

So joining us now, we have senior front end developer Wes Ruvalcaba coming to us from Ohio, and yeah, so tell-

Wes:

All the way from Ohio, yeah. I walked here.

Matt:

All the way from ... That's a terrible lie.

Mike:

Boy are your feet tired. Wes, you did the initial architecture of the theme. Go ahead and just give us a 2,000 foot overview of how you architected the [SAAS 00:29:50]. You have multiple libraries, how we're doing that, and go down.

Wes:

Sure. Yeah, so when we first were putting the site together, we weren't sure how many people would be available, or if we were going to get any help. So the idea behind putting the theme together the way I did was to be consistent with other projects that we generally work on, and that someone could just walk in and not have to wrestle too much with different dependencies, or making the front end build work, or basically doing anything new or crazy. It would just try to keep it pretty simple so the components are broken up in a way that we usually break them up where it's if you're familiar with its Max X, so you have a base folder and your component folder and all that, all the partials are named after the components. All that was pretty simple.

Wes:

We were able to get the front end build so that you didn't have to know if we were using Grunt or Gulp. We were originally using Grunt, but Grunt, we were having some issues with it. Some of the packages we were using were a little out of date and weren't working correctly, so we ended up switching Gulp halfway through. That was first time I've ever really made a Gulp file, and I love it. I'm never going back.

Matt:

What do you like about it? What's the deal?

Wes:

The thing that a lot of people go back to is that it's more like writing JavaScript. Grunt's whole philosophy is more around making it easier by not having to know JavaScript, so you're writing more configuration than code stuff. Yeah, now that I know way more about JavaScript, Gulp was just fantastic for me.

Matt:

One thing, Wes, so you were involved with the last Lullabot.com website with the decoupled react. You've done a bunch of work on that too.

Wes:

Yeah.

Matt:

Was it different coming back to let's do everything in Drupal, and let's build a Drupal theme as Drupal themes are made to be?

Wes:

Yeah, I mean that was one of the things, I think was hard for a lot of people to come in and pick it up just out of nowhere was it was something they weren't used to, and this is a side project that we do.

Matt:

U mean if somebody new said, “Hey, I've got 20 hours to work on Lullabot.com,” they're like, “Oh, crap, I don't know what I'm doing here?”

Wes:

Right.

Matt:

You're saying the ramp up time was hard rotating a lot of people in and out?

Wes:

Yeah, just because there were a fair number of people who hadn't done a lot of that kind of work, but I mean, we had something that was way more approachable than our first version of it, and really got down to a lot of good best practices. We were doing a lot of really fun work, but yeah, getting new people on the project was tricky to entice them to do it, one, and then to have them feel successful early on ended up being a little bit of a problem. So getting back to this kind of thing was actually fun for me. I've been on a project for a very long time, and I've seen all the code bases' warts, and I just get to do some maintenance. But yeah, coming back and doing some Drupal work was really fun. We knew the requirements. The client was okay, I don't know, but-

Mike:

Yeah, the client was a pain in the butt. So I want to talk about some of the cool stuff that we did. We're not using jQuery on the front end at least.

Wes:

Yeah, that was your initiative, and that was fantastic.

Mike:

Yeah, we're not using any type of jQuery. We're not using any type of framework. We're just doing straight up vanilla JavaScript, which is really cool. I'm looking at the ... The home page bundle size is eight kilobytes for JavaScript, which is pretty- Yeah, which is-

Matt:

What?

Mike:

Yeah, eight kilobytes. You don't need JavaScript for everything, and honestly, our site functions fairly well even without JavaScript. It's not 100% good, but it's honestly completely usable, and so yeah, that's pretty awesome. We ended up writing some custom JavaScript that's probably going to make its way into a module. One of the things that I did is I did some functionality that very similar to views load more where you have that load more button at the bottom of your view. Similarly, to view load more, it just reaches out into the pager and grabs the next page, and then it processes that. It uses Async promises, and it'll pull in the next page, and then pin that to the bottom. That's pretty cool.

Mike:

What else that I'm really, really proud of is that it actually does paging where you know how like if you've been on a website that has a load more button? You start scrolling or you hit the button, you hit the button again, you hit the button again, and then you navigate somewhere. Then you hit the back button and then it's like you have to hit that button six more times, and you're like dammit. This keeps track of that. It'll take you back to where you were, and stuff, which is super, super cool.

Wes:

There's your model name, no more dammit.

Mike:

Yeah, no more dammit, right? It'll fall back to your regular, old, I don't know, hyperlink pager for IE 11 and for non JavaScript users, so it's pretty neat. What else did we do JavaScript wise? We have a custom module player which is pretty fun, audio API. If you haven't worked with it, it's pretty cool in browsers. It's modern, and it's fun to work with. I like how we're splitting everything out into their own libraries so the CSS bundle size is very small. The HTML is all pretty semantic, and we did a lot of custom ... obviously a lot of custom twig templates.

Matt:

So this isn't ... Go ahead.

Putra:

Sorry, we also added some utility classes as well to fill the website just so. Most of the classed were semantic, but at the same time, we're also trying to utilize more utility classes just so that we have more flexibility in terms of building out a new section and not having to go back and create a unique class for a particular section that we're working on, so that's been helpful as well.

Wes:

Yeah, I've always found on projects, yeah, starting with them and doing that is great, but then you start finding things that you're doing everywhere and you're writing the same styles over and over again, and utility classes have just been much better of a mix of just not being a purist and being balanced with what I use where.

Matt:

So this is one of those projects that you launch and you're like, yeah, view source. It looks good.

Wes:

Yeah. Well, I haven't been on it for a while. I don't know what these jerks did, but I'm pretty sure it's still awesome.

Matt:

It looks pretty awesome.

Putra:

It looks good, yeah.

Matt:

You gotta stay away from them.

Wes:

But no, it was great. I actually had ... My life picked up a bit and I did not have the time for this on the side, and it went from ... When I had it, it was like everything looks like a page. Everything more or less works, and then Putra comes in and all of sudden, we have flick animations which I've now stolen for another project to modify it.

Putra:

Awesome. I love that.

Wes:

The code is great, loved it, and then Mike's doing all this cool, crazy stuff that ... Then the front end performance is just amazing, so really-

Mike:

Yeah, the front end performance is completely awesome. I'm really proud of it because getting all As on webpage [inaudible 00:37:36] and hundreds on page rank, the light house audits and all that type of stuff.

Karen:

I think that's especially cool because one of the concerns about moving away from react was we don't want to get slow and get bogged down, which can happen with a monolithic site, so very exciting.

Mike:

It's a really lightweight site.

Matt:

How was using Twig? Was that something that has been a lot of fun? Is there anything special going on in that front within building a theme?

Mike:

Yeah. I mean for me, the tricky part was just knowing how to get the data that you need into your Twig file. The key to that is actually setting brick points within Twig so you can actually open it up and page [inaudible 00:38:14] is still on, and then knowing enough of the entity API to screw around to get the data that you need.

Putra:

Yeah, we also added a number of customer levels to [inaudible 00:38:28] node in order to grab particular levels that we wanted to render in that Twig file as well, so that's been helpful.

Wes:

Yeah, as a guy who does not have PhpStorm, still just using plain old editors all the time like VS code, that's been my problem, is Twig is super easy. It's like just coasting. It's like, oh, I have everything I need, and then the moment I don't have what I need and I need to go find it and figure out how to get it, I'll kill browser tabs like crazy using Devel, or all my old tricks are actually-

Mike:

We need to sit together.

Wes:

Yeah, really.

Mike:

I will sell you on PhpStorm. I will be their advocate, so Jeff Way, if you're listening, you got to cut me a deal here.

Matt:

The Lullabot podcast, brought to you by PhpStorm.

Wes:

Yeah, right. No, my problem has always been, as a guy who used to be a designer, the IDE interface gives me a headache.

Mike:

So you're one of those?

Wes:

Yeah, I'm one of those.

Matt:

Eclipse still exists.

Wes:

There's wincing in the room.

Matt:

You could go to them.

Wes:

Actually I've considered if I'm going to use PhpStorm. I've been interested in Veeam, and Veeam appeals to me in a lot of ways, but I don't know if it solves the problem.

Mike:

Veeam is definitely the hipster route to take.

Wes:

Yeah, it is, but it interests me.

Matt:

Hey, so I just have one question. Karen, maybe we can bring this back. It's something that I see online when people are talking about building Drupal 8 these days. They say, “Drupal 8 still isn't ready. It's crap. The contrib space is hard. I can't snap together a website.” It seems like we were able to.

Karen:

Right.

Matt:

So what is missing out there? Is there anything that's still troublesome in this?

Karen:

Honestly, the goal was to do this with what's available in contrib. We created a few contrib projects to solve some specific problems, but other than that, we were able to do it.

Matt:

We missed something, right? We were missing iTunes. We built our own.

Karen:

Yeah. The things we were have put out there as contrib modules, so theoretically, anyone who wanted to do anything similar should be able to do pretty much out of the box.

Wes:

I wonder if some of the people having those frustrations are used to maybe more front end contrib modules, or things that we didn't even touch. Actually, I don't generally recommend using modules for the front end is you have someone that can do it just with plain old web stuff, but-

Matt:

I don't know these grumpy people. It was something I saw and I read it on an r/Drupal thread of Drupal 8 sucks or something, and it was like, oh, I don't know.

Wes:

Yeah, when people get upset with a tool like this, it's like what were their expectations. I want to know what they were missing.

Karen:

I think one of the other issues that we ran into is that people who've come in from Drupal 7, for instance, are upset if they don't see their Drupal 7 solutions. Sometimes in Drupal 8, the Drupal 7 solution isn't the right solution anymore. There's a new way to fix it in Drupal 8.

Mateu:

Yeah, that's true, and coming from Drupal 7, the tooling is completely different. So now, we have composure, and you need to figure out how to build your side before pushing it to your deployment server unless your deployment server has those build tools. That also is maybe challenging for some people just jumping from other projects that don't have that kind of workflow, or that are in Drupal 7.

Matt:

Right on. Hey, so we're at about time to wrap up. If we could just go around the table and maybe mention something you haven't mentioned yet, something you enjoyed about the project or anything neat about Lullabot.com that you're particularly proud of. Putra.

Putra:

Yeah. Well, Lullabot.com is definitely my first project here at the company, so it's nice just-

Matt:

It's the 'hey, welcome to the company. We need a dang website.'

Karen:

Dive into this website [crosstalk 00:42:08].

Putra:

Dive into this website, yeah, but you guys have done a really good job as far as setting up the documentation for setting up the website and everything else, so it was fantastic to be able to be involved in a project. I'm really proud of the amount of work that we were able to produce, so yeah.

Matt:

Karen.

Karen:

I'm proud of all kinds of things, but one thing that we haven't talked about that I think is cool is we used Lando to do our local development. We did a lot of playing around with Lando and figuring out the best way to set it up and accomplishing a lot of things, and-

Matt:

And we've gone on to use it on other projects.

Karen:

We've gone on to use it on other projects. Again, our goal is to make as much of this public as we can.

Matt:

Wes.

Wes:

Yeah, so I would say the documentation and getting it so that people like Putra came on. It seemed like pretty quickly, she was making pole requests, very proud of that. I have to say, I want to mention a couple times, a lot of that I owed to [Kerwin 00:43:02] Young who I've been stealing and morphing his work for about two years now.

Matt:

Hey Kerwin.

Wes:

Hi Kerwin, thank you.

Matt:

Mateu.

Mateu:

For me, one of the good things was that after being in the project with non Lullabots, I came back and worked with this awesome group of people, and it got me really excited since I got time between transitioning projects.

Matt:

Mike Herchel.

Mike:

This is my first project working with layout builder. Layout builder is freaking phenomenal. It's a game changer as far as page layout, Drupal, putting together sites. I don't know, it's just pretty awesome.

Matt:

Panels existed. It was cool.

Mike:

I mean the UI in panels is a piece of crap compared to layout builder.

Mateu:

Was it cool?

Mike:

Yeah.

Wes:

It solved the problem. I'm not hating.

Mike:

Yeah, layout builder is pretty neat, so yeah, so thanks to all the core people that are working on layout builder.

Matt:

Right on. Thanks everybody for joining us.

Mike:

Yeah, thanks everybody.

Karen:

Bye.

Putra:

Bye, thanks.

Mateu:

Bye.