MARGARET PLETT:
Alright. So, first, I just wanted to introduce myself. My name is Margaret Platt. I am the training director at Tyto Learning Solutions. We've been training Drupalers since 2012 and do a ton of private training. We do all the private training deliveries for Acquia, for their clients, and public and private training for ourselves. I am credited with co-authoring the Drupal 8 curricula for Acquia back in 2015. We worked on that before there were even notes in the API and I'm a certified developer for both Drupal 7 and Drupal 8. Personally, I love traveling with my two kids. My youngest is graduating high school this year and riding my motorcycle. And when I wrote that, I realized, oh, those are two things that have not been able to do for a long time. It's kind of sad. Travel is something I really missed and so is my motorcycle. Any of you in Chicago that ride know that we're finally... Oops, I think somebody is unmuted, know that we're finally getting to a point where we can... I don't know who that is.
I don't see. There we go. Sorry about that. But anyway, that was in Chicago, and Rives knows that this is the time of year when we get antsy and want to get out there. But I'm a lifelong. I feel like I'm competing. Sorry, guys.
SPEAKER:
Margaret, give me one second. I'm just gonna mute everybody and then unmute you.
MARGARET PLETT:
OK? I don't know where it's coming from. Is that Gather? No.
SPEAKER:
Everybody should be muted here. Yeah, it might be a separate tab.
MARGARET PLETT:
OK. So, yeah, the last thing I was just going to say... Oh, do we have other people who are unmuted? I don't know but we'll see. I'm gonna just keep plowing through. So I'm a lifelong Chicagoland resident. I've been here for 50 years. And this summer, I'm moving to Columbus, Ohio. So I'm still hoping to continue to come into med camp every year and being a strong part of the community. I look forward to meeting you guys over the next couple of days. I'll look for you in Gather Town and other sessions throughout the week. So I'm here, today, to help kick off your make camp experience by assuring you know what you're getting yourself into. Although many of you, at this camp, have been around as long or longer than me, we're hoping some of you are joining MidCamp for the first time. And we'd like to help you get started by giving you a little tour. I'm going to take my time with you to introduce Drupal. I'll give a little history, talk about its key features with a big picture overview, and I'll even provide some helpful terminology along the way.
Then we hope you'll stick around for Susann, 11:15, who's gonna talk with you about how to get the most out of Drupal. And finally, after lunch, you can come back for Abby, who will share his tips on how to get the most out of MidCamp. And even if you're a long-time Drupal expert, I encourage you to stick around. Some of this will be very introductory and some of it, what I find, is just the different perspective we all have in the open-source community about how Drupal works. It might be interesting. So stick with me. First thing we're gonna do is talk about the stars that show Drupal in order to understand how cool Drupal is. It's helpful to understand where it came from. So. Here's a little history, when I first started building websites in the mid-90s, things were much different than where we are today. Back then...this is proceeding (UNKNOWN), you know. Back then, HTML 2 had just introduced image tags. So we were able to put pictures on our site. And CSS was still in its infancy.
Our websites were mainly indexed, mainly text and images, and it was assumed that, mostly, people would come in and enter the site through your front page or the index page. So site maintenance consisted of updating text files. And as our websites became more complex, we saw static sites grow to contain thousands of those text files, and that was no small task to maintain. Around 2000, a few things changed the way we handled website data. First, PHP matured. Zend Engine had a bunch of tools that were pulled into PHP and that provided Web developers with a templating language. So templating ushered in the first database-driven website. And we found that, with database-driven websites, we could separate the data, like the content, from display and from business logic. So with that, Web technology, non-technical staff were finally empowered to manage their own website content, which relieved overworked I.T. departments and those bottlenecks that marketing was always complaining about. They were finally able to get in there and change the special or add a press release, and it really flipped Web development on its head in a good way.
So when we talk about database-driven websites, the site kind of shows how it works in Drupal. When a Web site serves a Web browser request or a visitor goes, in better terms, the visitor goes to a Web site and asks for a page to be displayed, that request goes to the system. In Drupal, we call that module, and those modules run and figure out what to serve and pull the data out of the database, assemble it, and create what the visitor sees in their browser. This allows for endless possibilities. We're assembling pages from lots of stuff that's been saved. So we can have more efficient content management where we enter once and use it many times. And this is way more efficient than the old days of editing those individual text files for every request. So that all happened around 2000. Around the same time in the early 2000s, Web developers started to realize the benefits of sharing code and sharing code on the Internet. I mean, we were doing Shareware and stuff before that, but sharing code on the Internet and working in an open-source community was spectacular.
We got to work with people all over the world. So when Dries Buytaer and his friends created a database-driven message board, as students at the University of Antwerp, he decided to release the code behind the software. And in sharing the code and encouraging others to improve on it, he kicked off an online community and the creation of a platform that has evolved into what we see as Drupal today. So still talking in general terms about Drupal, I just want to quickly address what we mean when we say open source for those of you that are new to the open-source community. Unlike proprietary or closed source software, some examples would be Microsoft Office or Adobe Design Suite, open-source software is free for anyone to use. Open-source software also makes their source code available for anyone to use and modify. So source code being what programmers use to manipulate how an application works, with the result being an open-source platform. Like Drupal has its source code available to anyone interested in modifying or developing the platform further.
So programmers from all over the world donate their time to help improve Drupal. Drupal provides a code of conduct, coding standards for programmers to follow, and all improvements and changes made to Drupal go through a solid community vetting process to ensure integrity and stability of the application. It's really exciting to see so many people collaborating and participating in a community that embraces transparency and change. And Drupal's open source community is one of the biggest reasons why the platform continues to gain momentum. I'll point to some community resources as we wrap things up later. So since those early days, Drupal has grown in leaps and bounds, powering everything from small blogs to some very influential site. Here are some of the websites that are powered by Drupal today. Of course, technology groups like RedHat and Opensource.com, but also the entertainment industry uses Drupal, internationally recognized cultural venues like Chicago's very own Field Museum, universities all over the world, state, local, and federal government, multinational corporations, nonprofits, major sports leagues.
Even NASA and Tesla build their websites with Drupal. The growth of Drupal is due, in part, to Drupal's unique strengths that keep getting better. So big picture, what are those strengths? Let's take a look at some of Drupal's strongest features. And, you know, in 45 minutes that I was given to do this, I decided to just pick a few of the big features to highlight. As you continue on your journey to learn Drupal, I can promise you'll discover a lot more. So the feature all users experience is how easy it is to enter content. With a well-built Drupal site, you have clearly labeled fields on a data entry form built to collect all your content. The text fields provide a WYSIWYG editor, so you can edit content as though you're in a word processing interface. And we're gonna take a look at how, from the site builder perspective, we're able to structure this data collection. So it's really useful in our database and it gives us a lot of power the way that we collect data or content in Drupal.
You just fill out all those fields and then save, and your data is added to the database and ready to display on the site. To keep up with the global explosion of mobile devices, Drupal 8 was built with a total focus on responsive design. So from the installer to the model pages, you'll find the interface has been built with mobile in mind. All features were designed to work on the smallest screen. And you'll even notice that the administrative toolbar in the back end automatically expands and orients itself horizontally on wide screens and collapses vertically for smaller screens. I think one of the best features about Drupal for the beginner or the non-programmer is that you can control almost everything on your Drupal site without having any coding or programming experience. The framework is built to make all configurations available with point and click access while remaining really flexible, flexible enough to allow for customization down to the most granular configuration. Another great feature of Drupal is its community management tools.
Now, these have been around for a long time in Drupal and really provide built-in support for website communities. If you're hosting a site with membership or other interactions, there's tools like commenting, forums, customized user profiles that all allow us to build better community. To facilitate community websites and the teams who manage the site, you need Drupal's comprehensive and extensible permission system. With Drupal, you can create custom roles with access to just a plethora of permissions, allowing for fine-grained control over who can access what within the system. Drupal includes the results of a massive multilingual initiative, back in 2015, with over 1,000 contributors participating and making the platform's multilingual capabilities the best at cloud. Even site installation is multilingual now. So the Drupal 8 installer actually auto-detects the language from your browser and then auto-selects the appropriate language for you. Then it downloads the latest interface translation so you can perform your entire site installation in your native language.
Everything from blocks, views, and menus to individual field values are translatable. And this all works with right to left languages like Arabic, too. In Drupal 8, we changed our approach from previous versions, enabling a new level of control over every item on our site build. Content, comments, blocks, taxonomy terms, users, nearly everything in Drupal 8, thanks to a new object-oriented programming approach, is called an entity. And entity types, like content types, can be used to store and display data. So if you're new to Drupal, I just add a whole bunch of words that you may not be familiar with. So in the next slides, we're going to look at Drupal through terminology. So I want to make sure you leave this session understanding the meaning of the Drupal terms you'll be hearing when you attend other sessions at MidCamp, and hopefully, as you continue to get more involved with Drupal after camp. Drupal sites are made up of modules and themes. In fact, there are almost 100 modules and five themes that come with Drupal corps.
The modular nature of Drupal makes it possible to seamlessly add additional functionality. So these terms are really important, and you'll hear them a lot. Modules are collections of PHP code that you can add to your Drupal installation to change how it behaves. Some modules add entirely new functionality, while others modify existing elements to make them easier to use or add related functionality that's missing. Themes, very much like modules, are collections, but in this case, they're collections of HTML, CSS, and image assets that change the way your website looks. Some of these themes act like skeletons or basis that you can add your own styling to and others come complete to use. But if you have any custom code on your site, it will most certainly be in the form of a theme project that ensures your site reflects your brand with your own style and image asset. And when we talk about those modules and themes, I said they are in core. Core is a term you'll hear a lot as you progress in your understanding of Drupal.
So I just wanted to clarify the term before we go on. Drupal core simply refers to the files and modules included with Drupal 8 or Drupal out of the box, or in other words, what is available for immediate use with every instance of the Drupal platform. Since every site can be configured uniquely with contributed and custom functionality, we differentiate the tools available with these three classes. First core refers to what comes with the platform out of the box. Contributed refers to add-on functionality that is contributed by the open-source community and really available at drupal.org. And then custom refers the functionality that is written specifically for your organization by your developers. Now, the reason that we classify them is because a module looks like a module, looks like a module. Whether it comes in core, it's contributed, built by someone else, or built by you, they're hard to differentiate in code. So we really want to keep track of what the source is for our project for maintenance.
Core models will always get updated with a total core update where contributed projects may get updates from those maintainers who built and contributed the tools. And then your custom projects need to be maintained by your team, kept secure, and working. So when you're responsible for Drupal site and responsible for the maintenance of that site, keeping it up to date, you want to know where your models and themes come from so that you can make sure you're getting updates from the source. So building a site that truly takes advantage of the database can be broken down into two jobs. First, the site builder wants to get structured data into the database. This data represents all the content, keywords, users, and other information that you want to share on your website. The second tab, then, of the site builder is to build queries and rules to retrieve the data from the database and display it throughout the site where and when it's needed. So in the next slides, we're going to introduce some key Drupal terminology that will help you wrap words around the site-building processes, getting data into the database, and then querying it out for display.
So for the first part of the process, getting structured data into the database, a Drupalist will decide what kind of data they want to collect, and then create data entry forms to template the data collection. All of the content entities listed here on this slide allow the site builder to create a data entry form. So it comes down to picking the appropriate entity for the data that's being collected. For example, data about people who need to log into the site is best collected with the user entity form, where comments and contact form are entities that allow for collection of visitor data, where comments might be displayed on the site and contact forms collect data that's stored privately. Blocks, content, and taxonomy are a little more robust. And so we're going to take a closer look at those. So when the site builder is thinking about the primary content on their site, they'll probably create content type data collection form. Since this entity has been around from the beginning of Drupal, the name has morphed from node to content in the user interface.
So in code, it's still referred to as node. So when you hear people talking about node, this is the mysterious node they're referring to. In the beginning of Drupal, I presume this, I don't know this for a fact, but I assume that the guys who created Drupal at the University of Antwerp were thinking about each of the stops or location paths on their message board as like in a networking kind of way, you know, a node in a network. And that's where their messages were stored. As the site evolved, as the platform evolved, we saw nodes holding content for, like, blocks and that sort of thing. And then we realized that we have other entities that we would use like taxonomy to classify data and users that would have their own path. So nodes didn't totally make sense in its original usage, but it certainly is at the core of our Drupal. So we kept that name. But in the user interface, we started calling nodes and node types content and content type. And as you'll see, now with Drupal 8 and 9, you can collect data or content in a variety of entities.
So I think the content name is a little ambiguous as well. But node or content are key terms that you'll want to understand as you work on your Drupal site. Blocks are another entity that are really flexible. They work for small bits of data that is displayed on your site. Like, if you had contact information that you wanted to show up on every page, you could use a block to do that. Or if you had information that you want to ride along with content, like bio information for an author of the blog or a menu, blocks are great for those purposes because they're so flexible. Unlike content, block data does not have its own path. Instead, it's displayed by placing it in a region on the page. And the term region refers to areas that subdivide a page in Drupal. Those areas are available for displaying content. So this picture is a very simplified version of a page, but it's there to give you an idea. This page is divided or subdivided into four regions, header, content, sidebar, and footer. And then we're showing three blocks placed in region.
One is a poll, one is a user login form, and the other is a menu. Blocks like the ones displayed here often come from the system or the modules that are installed, but site builders can also create their own custom blocks and custom block type. So if you have something that's regularly entered like that author information or coupon or something else that you want to ride alongside other content, you can structure that data collection as well, just like you structure content type data collection. You've probably heard the last word, taxonomy, in your high school biology class. The last time I heard it, that was it, until I came to Drupal land. You remember Kingdom Phylum, class, order, etc, all the way down to species. Taxonomy refers to a system of classification. And Drupal's taxonomy system is so flexible, it can work for the largest of collections or for small just sets of keywords. With taxonomy in Drupal, you can define multiple vocabularies to template collection of terms. And within a vocabulary, those terms allow you to...can be used to categorize stuff.
So you might have a vocabulary of states in the United States, that would be states. So Illinois, Wisconsin, California would all be in that list. And then maybe you also have a vocabulary of your products. And so maybe it's clothing, women's, men's, children's, and then you have the ability to have child terms within a term. So if you have those three terms in your vocabulary, the children's clothing term could have child term like pants, shirts, shoes. And you're able to use those terms in their hierarchy to categorize other content that comes up. Once defined and tagged, having tagged content comes in handy for everything, from menu and navigation schemes to defining sorting, filtering, and display options on your Drupal site. So taxonomy lets us take control, have more power over that structured data that we've collected in our database. So there, we've looked into this terminology around the data collection job, talking about nodes or content, which are the nucleus of Drupal, blocks, which are very flexible ways to collect data or content, taxonomy, which allows us to set up terms to classify or categorize our content, users, for information about people, especially people who need to log into the site, and then comments and contact forms that allow us to structure data collection from visitors on our site.
So I keep saying structured data, and I just want to be clear. What we're talking about is different than what we originally did with database-driven websites. When we first realized, if you remember the history that we talked about, when we first realized that we could push content management out of I.T. and into marketing or communications, let them take control, empower them to manage their content on the site, we initially saw a lot of platforms like Joomla and WordPress just take the HTML kind of page break down, title and body, and give that to the content editor. So here's this big box that you can put all your stuff in to make your page. And that kind of, to me, it's kind of a Wild West situation where people decide what they're going to put on a page, links, and dancing bears and music or whatever they want. But that was the thinking. Originally, it was like, oh, we'll just give them this capability. But we're Drupal. And as Drupal said this is a database-driven website, we want to get data into the database that we can work on, that we have power over.
And when you have a big box of data and it's saved in a database, some of you may know this term, it's called a blob. The database is like, "I don't know." If you want to download this and take a look at all the stuff in this field, you can, but it doesn't... You're not powerful with a blob. You're kind of stymied with it. So instead, what we do with Drupal is we have this capability to field or structure our data collection, break that blob up into all the elements that we want, takes the weight off the shoulders of the content editor. They don't have to figure out what to put in this big empty box, and it also gives developers the opportunity to filter and sort and repurpose data throughout the site. So unstructured data collection is super important and understanding that, with Drupal 8 and 9, we're able to collect data in the structured fields that way, with all the entities equally is very exciting. So we get all the data into the database, it's structured, and we want it to show up for people who actually visit our site.
So that brings in the second part of the site builder's job. And when we want to get data out of the database for display, we use a tool called Views. The Views tool allows us to point and click to create complex queries and specify formatting. So when you see a list of data created by the View tool, we call it a view. It's very much like an island language. View means everything related to querying. But when you hear that term, what people are referring to is this tool that is part of Drupal core that allows us to point and click through very comprehensive configurations to query the data and get it set up and formatted to display as needed through our site. Now, certainly, if you've worked under both sides or you're new to Drupal, there are always basic pages on a site that don't require this whole interaction with the database and structured data. Like the one that comes to mind is the About Us page, right? You kind of want just a big open block so you can put in a couple of paragraphs and a nice picture, and maybe it includes a block that has some links to other information about your organization.
So there are certainly lots of uses for individual pages that are not super structured and data queried. In addition to that, we have new layout and layout tools in Drupal core that allow you, as a site builder or even a content editor, to create individual landing pages. It's called layout builder. And layout builder, when configured for your site, allows you to pull content into kind of a picture of the region to lay it out the way you want it. So you want the menu over here and the autobio info over here and your main content here. You can make those decisions with drag and drop control. In addition, at a higher level with that tool, you can actually define what the layout will be. So you can say, you know, "I get that there's a header content and footer, but I'd like more regions. You know, I need three columns across underneath the content." All of that is pushed down from what used to be mostly the themer's job, in code, to the user, whether it's a site builder or the content editor with a layout builder tool.
Totally worth looking into, and I'll put a link in chat that shows a whole bunch of add-on tools that are available with the Layout Builder. So that gets us through all the terminology. I'm coming up on my time limit. So I want to leave you guys with some ideas to get the most out of your Drupal experience. Community interplay is key. And it, for me, was very different. I have been a web developer since 1996. I started using open-source content management systems in 2006. When I evaluated Drupal, WordPress, and Joomla to decide what to use for my clients, I chose Joomla at the time and worked for six years. I mostly focused on Joomla, also working on Drupal and WordPress, and SharePoint sites as needed. But I never really connected with any community. I went out and I would find resources and tools. And in Joomla, you pay a nominal fee, like in WordPress, when you need more functionality. So that truly contributed...it's what we call contributed in Drupal. But so when I came to Drupal, my very first day on the job and on my second day on the job was a Midwest camp, and that was in 2012.
And I was amazed by the sense of community and people knowing... I remember someone came up and asked me what my user number was on Drupal.org. And I was like, "I don't even have a Drupal.org account set up yet." And it was very interesting to see how you can tap into the community because I've never done that. And boy, it's so important. So you want to plugin and you want to participate as much as possible for the next few days. There are a ton of things to learn from all the experienced presenters, but the learning and opportunities you gain from meeting other Drupalers will be irreplaceable. So make sure you make those connections. You'll be sticking around now for Suzanne to talk more about getting the most out of Drupal. And like I said, Abby after lunch. We'll talk about getting more out of big MidCamp. But do the things, attend, play with those crazy tools like Gather.Town and meet people, and exchange information so you can continue to grow together as part of this community. And I have to say, as soon as you get a chance, visit Drupal.org and create a free account, if you haven't done that already.
Like I said, at my first midwest camp, I was asked about my username and actually my user number, really nerdy, on Drupal.org. And the cool thing with your account on Drupal.org is it really is your ticket to being a Drupal community member. I've worked for Drupal development (UNKNOWN). On the application, ask for your Drupal user name. And if you don't have one, like you're not a Drupal developer, they just don't even consider you as someone who would be, you know, working on their site. And another thing, another little secret is that when you have a page on Drupal.org, under history, everybody automatically shows how long they've had their account. And that kind of counts for a lot of people as to how long you've been a part of the community. So make sure you do that. It's your key into the community and a place for you to share your community cred, like all the things that you've participated and helped with. And it'll help you make connections. And while you're on Drupal.org, or if you haven't been there in a while, you know, you've been around Drupal but not Drupal.org, give yourself a tour of all the content on Drupal.org.
Go through those menus. In addition to hosting the repository for all of our contributed projects...and I just looked the other day, there's more than 46,000 really available module projects hosted on Drupal.org. But in addition to that, you'll find excellent documentation that has gotten better and better over the last few years, forum, community links, and just a whole lot more, case studies. It's a really great place and it's your primary source for the latest on everything Drupal. And finally, if you or your teammates need a comprehensive hands-on understanding of content management, site building, layout, and theming or module development, check out the Tyto learning website. We have best practice training. Like I said, we wrote the Drupal 8 books for Acquia back in 2015 and we deliver a very comprehensive instructor-led...our instructors are Acquia's certified Drupalers. And we get people ready with best practice approaches to building and managing Drupal sites. So I think that gets me to the end.
I am close here. Yeah, 11:10, not bad. So if you've got questions that weren't covered, feel free to message us, [email protected]. I'll put these links in the chat as well. If you don't mind and you want to get some feedback about this session, or if you want to get in contact with us, you can also fill out a quick survey at bit.ly/DrupalCampTraining. With bit.ly, you need to capitalize or use the Camel case. So capital D, C, T, DrupalCampTraining. And additionally, you can always check out our public training schedule. We have classes running every month. Even though we're remote now, we've been doing Zoom training or, you know, WebEx and all those things since 2013. So we were able to pivot on that in the last year. That's scheduled at bit.ly/tytolearn. And like I said, I'll put those links in the chat. I really appreciate you guys all, listening in and learning more about Drupal through terminology and features. And there's more to come. I think probably Abby is gonna take back over and then we're gonna hand off to Suzanne.
Abby, are you there?
SPEAKER:
I am. Yeah, thanks, Margaret. This was awesome. I think I even learned a couple things, too. Blobs are always like a weird thing that I was worried about.
MARGARET PLETT:
I love it, though, because we can kind of involve them with a name like that. We can be like blobs, who want the blob? Yeah.
SPEAKER:
It's certainly true.
MARGARET PLETT:
And I see Bob going, "Not Bob." Bob (UNKNOWN).
SPEAKER:
Nice. I want everybody to unmute themselves. So if you'd like to unmute yourself and... Yeah, I'm gonna ask everybody to unmute. We get a little round of applause.