 Hello everyone good. Good morning. I hope everyone's having an amazing Drupal con so far. Just a show of hands has anyone heard of Drupal 8 Okay, awesome really glad you guys have heard about it I know there's been a lot of great talks from trees yesterday throughout the con and Today I'm really really excited to share with you guys some of the adventures that we've all had up on the stage in Launching mskcc.org memorial stone caterings brand new website on Drupal 8 Several weeks ago, so we're super super excited to be here and my name is Molly Burns I'm an account director with phase 2 and I've had the pleasure of working with this amazing team So just to introduce The folks we've got we've got Evan Liebman who is the director of MSK digital and he's been the product owner and champion of this project Jacob Rockowitz is the Drupal CMS consultant for memorial stone catering who is also known as the developer extraordinaire as I like to say From the phase 2 team. We've got Jonathan headstrom a software architect Also our man in core who's been working on unblocking a lot of amazing Drupal core blockers that we had and doing a fantastic job And we've got Brad Wade a senior front-end developer at phase 2 who did our Drupal theme architecture and From digitas. We have Jill Baker a principal creative engineer who worked on the front end and the design process so super excited to get started and I Wanted to start with introducing Evan who's going to be talking about some of the processes that The MSK team went through to choose Drupal 8 and their design process and All right So just a little background on MSK So MSK is a cancer center located in New York City. We have a singular focus which is conquering cancer And Molly mentioned we just launched two websites in jupy 8 MSkcc.org and Sloan Kennery.edu and that was a leap from v6 to v8 Our adventure began Well, I'm going to talk a little bit more about sort of the digital strategy and a little bit more of the strategy around Why we chose jupy 8 and these folks here are gonna get very technical for you Just to start just to give you the background our adventure began in April 2014 just about a year ago And we selected two agencies to work on this project and many thought that we were crazy But we decided to split the business because you know, we chose Digitas LBI for for the creation of a digital roadmap and strategy As well as a design and UX and strategy for for the two redesigns And by April 2014, we had done some prototyping of migration From v6 to v8 and we knew we wanted a technology partner with experience and being an early adopter in Drupal So we selected phase 2 So just a little bit about about this process of developing the digital roadmap Looking to create meaningful digital experiences for our consumers And so today's healthcare consumers are involved in decisions about care and treatment of themselves and their significant others and Healthcare providers are expected to interact with patients and other medical professionals In digital environments, and we weren't quite there yet. So, you know, we set out to To deliver these desired digital experiences through MSK digital space And in doing that we began this development of our digital roadmap And so the first part of the first rollout of our digital roadmap are to redesigns of MSK CC that organ Huge project but a small piece of the pie So other other projects that we'll begin working on our pre-care tools customer relationship management in hospital tools So a lot of work to be done and you know, there's a great project and we got the sites out there But this is part of a, you know, a larger holistic vision to enable MSK to better serve its core audiences And you know presently our digital face to the world are very distinct sites We have six major sites that are that are out there External facing and we're not all aligned with the same, you know, you know, we don't have unified assets We don't have shared code libraries. We're all on different platforms So this is part of the, you know, bigger project that they will be working on this year And into next year to align everything So I'm sure many of you are familiar with journeys and personas when we first started this process We developed these journeys and personas Seven seven people here that are frequent visitors of our website And not going to go into detail at all about this, but just, you know, understanding a prospective patient from the point of diagnosis To survivorship and what are all the digital touch points really helped us understand that strategy work helped us to understand What these what tools were necessary So you can please go to the websites and check them out. This is their life now It's been a week. It feels like two weeks. It feels like two months, but it's only been one week And so this is this is our home page very simplified very focused very direct Divert in are you a patient and caregiver? Are you a health care professional? Are you a researcher? one of our Landing pages for those segments really simplified the approach Within these pages, but also the number of templates. I think we're down to like nine templates now on the website This is one of my favorite templates that's the tile template. We're going to talk quite a bit about this in The technology portion of this presentation and this is the home page for Sloan Kettering.edu also using So I've been getting this question quite a bit Since I've got here and figure to come right out in and answer it So why why did we choose Drupal 8 and it was it was actually pretty easy decision And these three decision The decision was based on these strategic pillars of MSK innovation financial sustainability and talent recruitment and We have a culture of innovation at MSK We have a relentless commitment and unmatched expertise That results in breakthroughs in patient care research and education and there's lots of similarities To the Drupal community there and we'll talk more about that Tomorrow in a session. I'll tell you more about that in a moment Finance from a you know a perspective the financial sustainability perspective We didn't think it was really viable to go from v6 to d7 and then to d8 because we we wanted this all the work that we had done into Developing the personas and the journeys and the strategy work. We don't we didn't want to do a two-year redesign We want this to be a long-term perhaps five years and so we thought if we We launched last month on to last week And in Drupal 7 we'll be talking about jupy late redesign right now I'm you know moving to jupy late and perhaps doing another redesign. So, you know, we need to be financial steward and We just didn't think it was worth the money. So also for me. This is the biggest Decision maker which was talent recruitment. I mean there are there are folks who Who are doing work in symphony and object-oriented program who are not here right now? They are you know That's that's their focus and they don't even know that jupy late's coming and available for them And I think that that that really helps to widen the talent pool for jupy and that makes it really exciting for us So just one, you know one final thing when we when we set out in April 14th to do this that mentioned that there was a lot of pre-work into moving to jupy late And that was all pioneered by Jake and Jake, you know, he came into Talk with us back in April 2013 and he had this mantra, you know D8 don't be late And it really helped to drive us and get us focused on jupy late And so Yeah, I This is what I'm gonna talk about and I brought up prototypes because Every project I have worked on in my career has started with the prototype just to be clear like even custom CMS is just proof of concept To get some catering to Drupal 6 I did a proof of concept in and one thing to say about prototypes Is it's trying to address the biggest concern of the project and for Drupal 6 for example? I only ported their doctor profiles over because that was the biggest selling point because some catering is about finding a doctor And when I did it views made it very easy to create a rich filter template to find doctors in Drupal 8 And I'm gonna jump past To the next slide about prototyping is in jupy late The key thing was proving it could be done that you could take a 30,000 nodes and move them to jupy late and have an admin UI that works and What was kind of amazing is the migration which I'll get in the more detail just I Got it down to about a 30 minute migration when we were prototyping where we could just bring over all this content and just show It working show the menu system was working on there was no theme It was just the bardic ad basically was bardic and admin UI it just showed that you can navigate the site Also started showing key benefits to the content maintainers To see the responsive design working in the admin UI to see the improvements in the node edit form to see CK editor in there and stuff like that this project the migration that I set up started in with Alpha Alpha 3 2013 and One of the key things when I was doing the prototype was also just to get the scope of the problem Like what was there going to be the real problem of moving to jupy late? And I think everyone who's especially coming from jupy 6 when you're looking at functional programming and you look at symphony It's overwhelming So I had to do a lot of just learning symphony. I mean my recommendation is learn symphony do a week of just doing a symphony prototype And you'll throw it away That that was another thing I kind of had to make it very clear when we were pursuing this project that I I submit 25% of the code written was thrown away at some point because you're just moving ahead things change in core You've got to rewrite things. You've got to change things And and the other biggest thing because it's like chasing head Testing is to chase head you have to have testing for all your custom code There's no other way to do it Because what's going to happen is some API is going to change it There's going to be some regression and the only way to see it in your custom code is to run some tests You can't run through every single line of code you've written to see that it works Especially when it comes to into back-end integration with third-party API's And I mean I was new to testing Drupal 6 really wasn't pushed because simple test was a contrived module and wasn't in core The biggest benefit I found was like a certain level of comfort with the code I was writing like when we went live there were certain APIs I just didn't have to think about because I ran the test and I was like it's working It's integrating properly with back-end systems like clinical trials Moving to the next slide. So just about the migration. This is important there. I Don't know the status of the migration in core But when we started the project my great module was just like a twinkle in trees I it was just announced that they were going to bring it into core and have a migration and it wasn't really a Valuable approach to be chasing head and chasing the migration path So I went with a custom migration and I actually did something I've done a lot of migrations from one system to another and One thing I did is I did the opposite of what I've always done Which is in the new system you write this massive migration that pulls in data and I realized in the prototype that D8 was this not stable I mean, you know now it's a lot more stable and I kind of just reverse it so that the migration is a push from D6 Which is very stable So I wrote a lot of the code that I'm going to describe here was written in D6 and one of the things that also For this migration you're going from one similar system to another So it's very easy to write SQL bulk inserts to move data You have to transform the data, but you still are looking at here's a menu table in triple six Here's and there's okay. The truth is here's a menu table in triple six and there's six menu tables in triple eight But the data does map in some way you can do a migration and transform it a little bit and get it to work And then the other big challenge big challenge and benefit is you have to rebuild your configuration and In Drupal 6 I just wrote the YAML configuration files. I had some templates that I would export from Drupal 8 Great thing about symphony was it's very easy to pull symphony code into Drupal 6. I just pulled down the YAML serialization and parser And then this is to migrate nodes. You have to serialize it. That was just my conclusion Basically, you take the object that's in Drupal 6 serialize it and then in Drupal 8 I opened it and brought it in using the normal entity API so that I made sure all the data was correct and stable so there is that after the migration it's the challenge of getting the functionality and Definitely Drupal 8 has a lot of modules in core. There are just certain views in core I think makes a big difference for a lot of people, but there's little subtle changes Big one that came to mind was like the menu block module got brought into core That's just a module that allows you to parse your menu in different ways to pull little pieces out And that's a key requirement for most websites now is you want to just show the first and second level or the second and third level of your navigation So that helped a lot, but then there was a reality that When we start now for three there was no module for that like any functionality we wanted had to be custom That gradually changed as people started catching up and some modules were brought over I'm only going to talk about one Module that had to address and it's web forms, and I think web forms is still in a state of uncertainty There was there's still working on that module so we had to come up with a solution and I kind of took I looked at the problem and tried to come up with the simplest solution to the problem and what I came up with was One of the most complex things of web forms of most of the code is the UI admin interface To have all those fields and drag and drop them and control them And I stripped it down to just a YAML file that represents a form And I also kind of brought things back to the form AP form API instead of putting a layer in front of it You basic I'm going to show an example, but basically it's a render right it takes the form render rate dumps it into a YAML and Someone can edit it It's readable and every developer is familiar with it and the content editors have gradually come around to what render Rays are and understand the hash before it and once you have the form It's it's it's really what web forms is doing is just crud. It's just saving data It depends on what direction web forms is going to go in but if you just want to collect data it's just inserting into a table and then exporting into a spreadsheet and then the final piece is send mail, which is a pretty simple one and One funny thing about that migration I talked about with the pushing from Drupal 6 It was incredibly easy to migrate 200 web forms with like hundreds of fields from Drupal 6 to Drupal 8 Because the migration was in Drupal 6. It was able to use the web form API Build the form and then just serialize it to YAML So I didn't have to write a lot of custom migration to get these forms over because I was kind of leveraging Existing code and and the truth is my existing knowledge of Drupal 6 which kind of shipped it over to Drupal 8 and This is really the example of the UI it's really simple This is the form over here that build this This is the YAML that you used to build the form on the right It's if you're a developer you're very familiar with this syntax if you're not it's basically just a bunch of properties and It collects it and then there's settings to kind of set up the confirmation page We're gonna do a buff about this form. I think it's also just the future survey forms in Drupal 8 and 9 There's got to be a better solution or a long-term solution for it so that in future versions of Drupal We don't have to do custom code for it And I'm gonna hand it off to Jonathan because I mean the other thing besides doing custom code was chasing head was running into core issues And we definitely cute like as I started moving along There are little subtle issues in core that needed to be addressed and yeah when Jonathan came on we Handed him a list of ten things that were just not working and he had to go through them and resolve them I'm gonna hand it off to you Yeah, so Like Jake said this project started on alpha 3 in 2013 so by the time I came on to the project in October Beta four or five there was quite a stack of issues that they had been piling up waiting and You know one of the great opportunities when you're working on a project like a real actual project during this level of You know the phase of core development is Not only do you have the opportunity to fix clear and broken bugs But you have the opportunity to fundamentally change core to make the fix make sense instead of you know if you wait for a release candidate or You know final release Really major bugs are essentially just sort of bandated over you're not going to be able to change underlying APIs to enable the system to make more sense so that was You know really great since October we have committed 57 Directly contributed 57 patches that have been committed we've submitted dozens more that you know are still waiting for review and Many many dozens more of patches that we didn't actually write But we reviewed and moved along to our TPC and eventually being committed and then in addition to that Literally hundreds and hundreds of long neglected issues Some sitting around for as long as four years it needs review We reduced at one point that number two. I think four months Then I started coming back on myself where I was the last person to comment So, you know that number is grown back to six months. I need to review. I think is the oldest You know so just sort of moving drew blade along Working directly on issues that MSK was running into but also issues that they hadn't run into yet Or issues that would unblock the final release was you know one of the big roles. I played on this project Another really great opportunity at this stage of core development is there's other agencies and developers working on You know drew blade projects for clients you have a way to You know at this at this stage there's more of an opportunity to collaborate with them because You know, it's not as finalized of an API something like Drupal 7 where you know, if you run into a core bug on Drupal 7 You know, there might be an issue about it But you don't really you know go out and ping another developer working on core because they've already had their say or it's too late to do it Whereas on this project There were several different developers from several different agencies that we worked with regularly both on core issues and on contrib collaborating trading off on on issues to sort of get them fixed in the contrib space we directly contributed patches to upgrade these nine modules That is the sum total of contrib modules were running on this site The Drupal 6 site had a hundred and fourteen Contribute the site has nine and it's not there is quite a bit of custom code to make up that difference But a big part of it is like Jake said through play does a lot more The custom code for Drupal 8 you can do a lot more with a lot less So, you know his YAML form module I think is 6,000 lines of code and I think web form in Drupal 7 is 50 plus thousand lines of code So like I said, 57 patches have been directly contributed and committed. There's a bunch more Ryan Aslet aka mixologic. He works for the DA gave me a very interesting statistic. He said the average Issue when you you know submit a patch and move it to needs review Sits for 23 days before anybody does anything and that's the average So there's obviously a lot of opportunity for more people to participate And help move Drupal 8 forward You know the issue queue can be a scary place the critical issues that are left They're sort of blocking a release candidate are really big and complex and you know I wouldn't recommend that for a beginner, but there's plenty of minor and normal Even some of the major tasks are pretty easy to jump in You know if you're not a coder there's a tag that's called needs manual review you can you know go and search for that tag And it usually explains how to reproduce the issue. You can spin up a simply test me So you don't even need to run it locally. It'll build Drupal 8 with the patch applied You can repeat the steps if it works. You say you can say this is good Part of the you know the core issues that they'd sort of stacked up were blocking You know the front-end work that needed to be done So, you know moving sassy, which is the sort of new underlying theme for Drupal 8 I helped unblock some of those issues and You know by doing that that helped you know make Drupal 8 more conducive for the approach that You know this front-end the design That they were going to use for this site It it Drupal 8 made it much more easier than Drupal it would have been in Drupal 7 so to talk more about that So my name is Jill Baker and I'm a principal creative engineer at Digitas LBI Just a few words about Digitas. There are a few of us in the audience We are a global agency that does all types of work I haven't mentioned earlier we were responsible for some content strategy for a lot of the design work user experience And then the front-end build as well so one unique thing about this site in terms of how we built it is we built it as a standalone prototype app and Jonathan was looting to Drupal 8 I think gave us the flexibility that we needed in order to accomplish that so With Digitas only being responsible for the front-end of the site It's actually sort of unique in that I and the other developers on the team actually didn't need to have Drupal expertise We were just building a modern flexible responsive front-end that was then integrated piecemeal through natural workflow So one of the things that we do along with our site builds is Not changing slides So one of the things that we do along with our site builds is build these living reference pages And I think this was instructive in terms of the actual integration when it came to that point in the process So they're sort of thrown in here, so forgive the presentation But we create a living style guide which you can see an example of on the upper right there where you're seeing actually A representation of some of the major styles on the site in this case the color palette and actually here We're showing the SAS variable names and they're resulting hex values as well So that full style guide contains other things like basic global element styles Some global utility classes that you can use etc We also create an icon library which you're seeing in the upper left there We use icomoon for custom icon fonts for cross browser vector rendering of iconography And so as we add new items to that font we represent those there and also include the class names that are used to represent them in code and Then on the bottom left and bottom right here You're seeing examples of container library pages or component library pages And we use those to display Each component as we build it we do build everything in a component style rather than a page style And then we also represent here any variants of that component So for instance if you have a quote that either has an image background or it doesn't if you have a table that needs to have One presentation versus another we would represent all of those here and also include The component name which you're seeing their icon feature text in this case And also any instructional notes on their use So these pages serve as a reference for the client for designers for the UX team as they review And also for front-end developers as they got on boarded to the team and continue and maintain code standards as the project progresses One thing you can also notice here is there's a switch theme to section this site had three major segment themes and We built this little theme switcher essentially so that on the prototype You could just use a URL parameter to test by swapping the entire container library page into that other theme by a body class So the front-end prototype site architecture was initially based off of our in-house Yeoman site generator, which we call starter kit this architecture leverages assemble as a static site generator and Use for handlebars rendering for JavaScript templating if you're not familiar with Yeoman or assemble I highly recommend them for spinning up modern sites very quickly It lets you focus on the hard and interesting problems and not resolve the same sort of base problems over and over again And you can also use Yeoman for many other common systems and patterns You know in this case we were using it with grunt and assemble and so forth, but you can use it for react angular. What have you We're using both npm and bower for dependency management such as lib sass for sass compilation And as I mentioned we use grunt as our primary build task manager You know some people in house are trying gulp out now as well for tasks such as library load JS Linting sass compilation auto-prefixing minification and others So I'm just going to run through very quickly some of the third-party libraries and plugins that we used You can review the slides on your own time if you're interested in any of them We did use jQuery very heavily as well as bits from jQuery UI such as the tab control We also use parts of Twitter bootstrap via the bootstrap sass implementation If you're not familiar with the bootstrap sass implementation It's actually really powerful because one of the weaknesses of bootstrap is that it's sort of a monstrosity There's so many pieces to it It can get very heavy and often you find yourself just re-skinning every piece anyway and essentially writing duplicate code instead of writing your code once So with bootstrap sass you can actually override their sass variables instead of overriding each resulting style declaration So you change one value and bootstrap itself will be generated with the appropriate styles rather than overriding them individually You can also leverage their built-in mix-ins, etc We also use the picture fill library to polyfill the current browser implementations of the w3c responsive image spec So in that way we were able to use the modern standard and then picture fill just fills in the gaps for those browsers as that support Others to highlight owl carousel We're using if you ever get asked to build a carousel that has that peak effect at the sides highly recommend owl carousel It's hard to search for it. It can do it. It's called stage batting J push menu for off-campus navigation sticky JS for a custom sticky sidebar behavior we use chosen for select element styling and Inquire for media queries in JavaScript In terms of browser compatibility, we were tasked with supporting i8 and higher in addition to all other major browsers And a set of particular mobile devices and operating systems as well We used IE conditional comments to serve a slightly different html element with a class that was targeted to those browsers And we also leveraged the following grant-built tasks strip MQ to serve query lists CSS Despite our CSS being written mobile first To unsupporting browsers modernizer for general feature detection bless CSS for avoiding Little-known IE limits on number of selectors and rules in a given file And auto prefix are to automatically add browser specific CSS for prefixes So similarly to using yeoman to kind of do the initial setup and kind of cut out some of the common repeatable tasks These tasks are great because they happen Live as you're developing they happen on build automatically so developers don't have to worry about you know checking Can I use for the latest browser prefixes needed based on our support matrix? Bless CSS automatically chops your files into chunks that IE can handle and you can serve those only to IE etc So this is just a quote from our internal starter kit documentation Regarding the principles behind our component based architecture and So for us a component is a small package of front-end software that does only one thing and it does it well a Component should include all the appropriate pieces. It needs to do its job, but no more and no less Essentially all items that we build are built as independently as possible to allow for maximum flexibility on the front-end a Window shade is still a window shade regardless of what page it appears on So our architecture involved a few different layouts, which were nestable one inside the others who avoid duplicative code We're able to share pieces of a template such as the standard set of CSS and script imports as separate handlebars Partials so that we can repeat them across pages without literally repeating the code Each component is at least one handlebars file and then optionally sass javascript and json for Styling scripting and data respectively We do use the BEM syntax. I think there's another talk today about that so I'm gonna definitely go to that one For our class nomenclature for easy identification of components and their subparts avoidance of specificity issues and standardized ways of handling variants in our code Each item can stand alone as is represented in our component libraries, but it can also be affected by the context in which it is placed We feed data into each page and component by inline parse JSON helpers external JSON files and page YAML headers Often components are written with default content so that developers don't have to add unique content every time They need to throw it into a page to mock it up But we make it overridable so that unique content can be added if needed for that page As you can see despite it being only a front-end static site We use very modern and effective tools and workflow to achieve a highly flexible and maintainable as well as user-friendly site The component architecture is one way in which we hope to make the lives of our back-end counterparts easier And help to maintain the fidelity of the design as it was translated to become authorable Brad Wade of phase 2 and I worked very closely together to ensure that our code worked well in tandem and that our deliverables were meeting their Hi, so I'm I'm Brad Wade from phase 2 and my job on this project was to try to integrate all this code and Work that Digitos didn't creating this prototype because believe it or not We didn't want to have to redo everything. She just described in Drupal so we wanted to be able to leverage what they had already done and The prototype the standalone prototype was being developed and created and approved at the same time as we were doing the Drupal build so These are happening in parallel So we needed to integrate their code in and we needed to do it continuously and regularly and over and over again So we wanted to be able to automate as much as this process of integrating there what they've done As much automate as much as we could So what I did was I wrote some grunt automate automation to build out their prototype to build the static their static version of it And then just copy over various assets from it to copy over the custom JavaScript the custom CSS the icons of videos images So we have the assets move we moved the assets over using this grunt automation into the Drupal theme and then we had to do some one some Some setup of the Drupal theme basically one-time setup of making the theme aware of where are these assets? And which ones are we using which ones are we not here's that here's where the CSS is here's where the JavaScript is and Then we took some time to evaluate the libraries all that list of libraries that Jill showed you She mentioned how she was using jQuery Drupal uses jQuery. So we took some time to see well Can we use this is same library? Can we just say okay? We're gonna depend on Drupal core jQuery, which we did do They also use modernizer, but their modernizer was the more verbose provided more class names That they were keying off of in their CSS So instead of using core modernizer we you know elected to include digit tosses version of modernizer and in In the theme in the Drupal theme So we had that set up, but we did have to write a small amount of CSS in JavaScript just to kind of make it work some glue JavaScript and some and some CSS to account for a few use cases That the prototype wasn't aware of that happened in Drupal, but but the good news as we we did wind up being able to use like 90% you know was just came through just fine And it was just this the you know over 90% just some small use cases that we had to account for what we called these this Drupal compatibility layer to make it all work So so now we had the assets this JavaScript and CSS ready to go, but of course it was Expecting a certain kind of markup. It was expecting the markup that they had in the prototype so this is where the work that you know the hard work of integration came in of our making Drupal's output Their markup match this this prototype and so we took these three approaches to do that the our main MO was to go in Override the twig templates and and just have them match what was expected so we take take one of those components from the From the prototype we take a look at it So we would take a look at one of our components which would use handlebar Templates using variables that were defined in JSON So that was what was happening the prototype over in Drupal and we were using twig templates with variables You know that came from fields in the Drupal database And we would we would basically recreate those templates in Go from the handlebar style to twig And so working with twig and Drupal 8 was was great and especially as I was just Twig has a easy gentle learning curve Ever you know everyone was able to pick it up quickly and enjoyed working with it It was also it's very much like handlebars or mustache You know some of the modern templating languages, so there was a ton of similarity between the style of Templating that was going on between the prototype in Drupal The templates themselves in exactly overlap in the same in the same way because there was there's nested layouts And and the nesting assumptions were different in each so these weren't one-to-one correspondences in the templates, but but the the templating languages themselves are very similar Which is which which is nice that Drupal is using something that's more can be more normal and accessible to General front-end people out there. They'll see these twig templates and they'll say oh, hey, this is my world I know what's going on here So that was our normal Main way that we did it, but sometimes we did work ahead and cooperate With digit toss and said you know there's some places where we just want to send you some markup And could you guys style this instead? You know we took we took Drupal's form output and we said hey Can you guys just style this you know use this markup instead of your just ideal markup that you'd normally use? So we did that sometimes just speed up the process to you know make there be less overall work to make deadlines and But that that's a viable option as well in your prototype Put what you know Drupal's already going to do and that that might be a good decision for for people in their projects, and we use both approaches So the third thing we did was well We we had we had this problem a common problem that we wanted to have some rich widgets containers components That would require rich complex markup We wanted those to appear inside the body content of a Drupal node Inside that field that's usually governed by a content editor entering Text into a whizzy wig we wanted some of these really within that some rich widgets So how are we gonna do that so Jake had a vision and created a custom module That allowed editors to Enter some simple markup with a special class name and Then Drupal would filter through that the body field and and find those little code snippets Transform them into more complex markup And in order to produce these widgets that we needed so For example for for a quote a pull quote a Content editor could come in and enter wrap The quote text in in a div with a special class name and there's a little extra data there to find in a data attribute And in this simple markup Would get run through a template that you know gets transformed using a template like this with much more complex markup In order to produce you know a beautiful stylized inline quote inside the body field That looks like this here On the left some of that extra data that I said mentioned was actually a reference to a user ID That went out and grabbed and was able to grab the the username and the title to attribute the quote there at the bottom So an advantage to this approach is that That that complex markup that we looked at Isn't saved in the database in your body field in line in there And that way in the future When you want to make a change to how it's output or a change the style or you redesign or when you're moving to Drupal 9 You don't have to like you know have this you're not wedded to that exact markup You can change that at a later time So we started with this idea I think just to sort of meet this use case But then but then later in the project we decided to Well extend this concept a little further to achieve what we called the tile template layout So We here we would see some Some divs with these brackets referring to different nodes node IDs defined in brackets inside, you know wrapped in some divs and This relatively relatively simple markup Well was able to produce this much more complex beautiful layout that you see here and We're gonna talk more about this tile template now Awesome, thanks Brad. Um, so We just want to have a little bit of a discussion about the tile template specifically Because it kind of represents a lot of things that we've already discussed in the project So I'm just gonna kind of ask a couple questions and kind of get kick us off And then we'll sort of open it up to audience in a little bit So to kind of start us off and Evan I know the tile templates one of your favorite parts of the site And that it kind of in our agile design process sort of came up towards the end as we were approaching You know final push. I'm just wondering if you could talk a little bit about more about like the site motif standpoint Why the tile templates are so essential and how they allow your team to really maximize and display content And it really comes from this position that we have where you know We have 30 25 30,000 nodes and we need to display a lot of teasers just to invite people in And you know really having a simple approach and very focused as we as we've attempted to do on many of our other templates We felt that the tile template offers the best view to show many different pages that are deep down within the site That people can access quickly and they can just scroll through and pick what pick what they get to but you know Molly also mentioned that we were stressed for time and so Within this agile process The plan was to go live in April and this design was approved mid-March And as we began to talk about that design with Brad and the rest of the front-end team at phase two We put an estimate at about four weeks of work to implement all the tile templates And so we had many variations of this tile template. I think there's And so that became an issue for timing and then well, I think the API That API I mean the key thing there is Componentizing the front-end of your website that was the the most successful aspect of that code package for me was there was a page that Broke down every single widget that had to be built and gave you the markup to exactly what needed to be done And the the tile template once the API was written, which I will throw out that core made it much easier to write an API Where okay? Here's a here's a class that just processes html and parses html even the parsing of the html and core is just easier There's some more utilities But to be able to have this the static markup that just said this is the html you need I literally took that html put into a files marked it original Then I wrote the twig template which you know and matched up every every single component just has a There's actually a dedicated page for every single component you see on that tile template You can just see the markup working and then you can see the basic markup. It also gave documentation for the content errors That I mean that the key thing to walk the key takeaway is this whole component system for the front-end Which is there's at least two sessions dedicated to it. I feel like in Jupo 9. It's going to become the norm Also, I had it really it helped to accelerate the project because we like I said we were looking at 20 days And we knocked it down to less than five So, you know, that's what got us this method Just a follow-up on the component based discussion I mean that's been such a key part of like the work that you guys did on the front-end I'm so I'm wondering Jill if you could talk a little bit more about how the component process sort of fed into the tile templates Because there were so many different variations and how you guys work together so in this case as they mentioned we're we're using the components for many types of pages and to a designer Having something in a grid with flexible widths and totally different things within each cell is a template to us Not so much So basically what we did is we defined every variant of these different types of tiles that could be placed within a grid And then we sort of extracted the two separate pieces the layout and then the tiles themselves So the layout we just built to be flexible where you could say, you know This is a two column versus four column versus six column type of Grid and then within that you could basically in theory plop these tiles of various types And you know you saw a little bit there But we're using them for things as disparate as bios and location pages and other types of featured content And so to do that we needed a lot of different ways to to stylize and display that content So in some cases those tiles would be text only in some cases they'd have a lot of text So they need a different treatment where we introduce sort of a read more behavior within that component Many of them included images, etc. So lots of different variants to choose from and as Jake mentioned We tried to display every single one of them in one page as a comprehensive reference And the read more bit is actually I feel like a success story as well. We're As soon as we saw the design on the front end we reached out and said, you know This is sort of how we're thinking about implementing this piece. Does that actually even make sense with Drupal? You know, it's gonna require the DOM to be in a little bit different order than you might expect And so we were able to just quickly prototype that out on the front end and then verify those expectations With phase two and I think Maybe rad. Yeah, I just wanted to tangent off of that because Digitas was Creating specific components using the BAM class naming methodology When we were matching the markup, we were careful to get each component Right and get each component very precise But we didn't actually have to match all the markup on that page entirely Because those those components are reusable and you can put them here and there move them around We have some extra like region wrappers around there that don't show up in the prototype and so If with these reusable components, there is a little bit of flexibility to the overall entire markup of the page And that's a big advantage of being using a good methodology like them and doing this component-based design Great. Um, so one more question on this topic. I know that the The team has already spoken about how it was Drupal 8 really allowed This to happen much more easily than it would have been able to happen in the past And I know Jonathan you've been working kind of deeply in Drupal 8 and Drupal 8 core And I was wondering if there's any other things that kind of Drupal 8 Accelerated in the course of this project Yeah, I mean, I think it's touched on it a bit, but just the ability to do much more with much less boilerplate and much more concise ways like Jake said you just have a one class to one thing and extend You know core class that does 99% of what you need it or you know in some cases, I think in the book Book module case, you know the core book manager just wasn't doing enough or as much So in Drupal 8 instead of writing some crazy patch or you know hacking around You can just swap out the service and make it as long as you implement the interface Exactly you want You know and that just that theme just kept coming up over and over whether we're talking about custom code The YAML form module or you know pointing to Drupal modules for Drupal 7 I would absolutely crucial but things from 6 to 7 for instance Great. So one last question before I turn it over to audience questions So, you know if we were to do stuff again, you know, would we do things differently and this is a question for Jake Because I know that you are around since the very beginning I mean, I think I my conclusion on this project is like the whole notion of headless Drupal I see a lot of merit with it It's also like we're talking about components like taking complex things and making them simpler And one of the concepts of headless Drupal is just like take the front end Which is really complex and move it over here and take the back end and move it over there And it might make it easier for people to manage their websites I mean the other sign point which we are struggling with is if you separate the two you could actually upgrade your back end And not upgrade your front end or do the other way around because there's separate independent things And one of the struggles with Drupal is you have a lot of things going on in one place And it's hard to figure out how to move forward to the next version of Drupal So that that was my takeaway and I honestly see there's more opportunities ahead even with this project toward headless Drupal just breaking things down into Simpler components are simple like taking functionality and isolating it into maybe sometimes a symphony library Literally just building symphony code to deal with something that is very specific custom code Yeah, and speaking of that, I know we'll be doing a bof a little bit later on The form approach so just a little bit of a shout out to that and let's move on to audience questions So we have this make up here and we're gonna move it back there So yeah, please when we get the mic up would love to hear your questions So my burning question because it's part of my life. How have you and will you manage core? Updates now and how do you move the content once you do? So we've been talking a little bit about this I think this is a good question for maybe Jake and Jonathan to sort of tag team I mean the simplest thing there's basically two challenges. It's moving config in data. Well, no, it's Configuration data and custom code and I think those are going to be three tracks in the upgrade path that we're going to address And I think the good part that Jonathan's kind of focused on core I think he's gonna be able to handle data and config pretty well because he's aware of it and And actually in the custom code because I have test tests are essential. I can't even I Mean I've got you know 50 different test suites running every single version every test for it just because it and and really there's simple API Changes and you just got to go through the change record and catch it And I think we're gonna have a pain point in we're on beta seven We're gonna run into a major pain point from beta seven to catch up and hopefully when they have the upgrade path that will solve a Lot of the problems and it's important to say we don't right now There's no critical thing that needs we need to upgrade so we're gonna hold off until we actually need to Yeah, and you know so the site is on beta seven Which is a little misleading because beta eight and nine were essentially the same release So they're really and then beta ten one really big thing that happened from beta nine While they're still not an official upgrade path the it's called the head-to-head module which was big In early adoption of Drupal seven it's sort of the civilitated unofficial upgrade paths from each version of alpha For seven so that has been revived for Drupal eight One of the really big changes that happen between dozens of different fields, so we don't have to address that Cratch there's an example Hopefully, maybe it just works in the head-to-head module. So even even though that's not in core and sort of officially An upgrade path I'll just add like with core there's certain moments where you just have to have a leap of faith that you'll figure it out I mean even with config management we features isn't available And I'm doing poor man's config management and actually core works really well It's two lines of code to have a YAML config file and bring it into core You just have to know you need to bring in that file and I think with the upgrade path That's what's gonna happen. We're gonna run into issues and just resolve them So I wanted to ask a question about workflow if you had to do custom coding for that or if you had So just a quick shout out we have to be haggler who is also on the project in the front row He worked a lot on that and Mike Liddo as well, but Jonathan do you want to take this one? Yeah, so that's actually one of my favorite patches to core that wasn't committed and it probably won't because it's a Eight is all of the underlying functionality and API is necessary for complex work flows are in place There's just no UI for it. So You know one of the patches that Jake set me loose on was to go and make a UI for actually moderating But it introduces the patch itself is really just a module, but that's UI So And I just have one one sort of point to sort of turn it to you guys is that The editorial team worked really closely on getting all the content ready and they had a lot of you know We're able to do a lot with the process of doing the content entry on the d6 side and and are also working in d8 So maybe you guys could talk a little bit about how the team is working Currently it seems like they've got good handle on it Yeah, I mean that you know a lot of the pretty much all the editorial work was done prior to the final migration and so Just working in d6 and having that ported over But now it's you know as far as as far as working Also clarify like just because I think people are concerned about workflow. It's a very simple workflow It's basically the idea of you just don't want revisions to go live You just want to be able to stage them and then the only other thing that like that's what Jonathan worked on and the only other And it was a really simple amount of code is to be able to let someone view unpublished content that you're staging And it was like setting up that permission and just allowing people to go to you know Just let a doctor review their bio that's not published and it's Core makes it very easy to do very simple access control rules not very rich ones Like just you want someone to have a special rule to view a page. It's actually quite simple. There's a hook for it And that that requirement made it very simple. We don't have a complex Any more questions I have one question What was the most challenging part of this project and if you could do it again, what would you do differently? I'll pass this over quickly, but I just want to say the timeline and if we had more time, you know, that would that would have been great Anyone else? But when we very first started this site a lot of stuff in the theme layer had changed and so, you know I was going to do the simple things I've learned, you know from Drupal 7 on I Went to do them and it's like, oh, it doesn't happen this way anymore. So what do you do? I'll do a quick Google search and then find nothing because no documentation had been written yet So it really helped me to understand how fantastic and how great What good documentation and documenting things is and the documentation has gotten a lot better since then But that was a really that was really rough Part of the project for me at the beginning and really encouraged me to help with the documentation process Thanks rad. So it seems like some of the takeaways there are documentation Always a good thing. Um, but as another face to your my says, it's so hard And um needs review in core right like people should start hitting up those issues. Um, really simple issues people can review It's like sort of the medium it so, you know All of a sudden Jonathan came in kind of halfway through the project and I looking back I think You should have someone dealing with core immediately through it and maybe you know when we're starting it was a lot of small issues But it would be nice to have had those addressed I mean really stupid ones like an arguments didn't work properly in oh that one I actually patchwork like arguments didn't work if they were more than 25 characters along the field name or something And but it's good to kind of if you have someone looking at core early and addressing these small things It's good. It's good for the community because these little issues can just get taken Out of the queue and then the bigger ones can kind of come to the forefront Yeah, that would be my biggest like make I think if you're doing this type of project you want someone on the core path immediately It just also just Jonathan's kind of moving along with your project and when you run into an issue you can hop in And he knows what's going on in core and you can hop back out and address it and it makes a big difference It's a certain couple of when I ran to every single bug on the project. I would have to push it to him in core and take a look at this and Very few are like that's an incredible pickle that you can't solve and sometimes we solved it with custom code We talked about and we're like no, let's just brute force custom code around the patch So I think that that's um, I just wanted to see if Evan has anything to in closing Yeah, sure. So I'm just in closing. I you know, I think that you know, this was a huge undertaking Um, and it you know, what what this team did was, you know, really nothing short or remarkable It was a fantastic feat and You know, we we had we were staffed with the right team and you know the right approach to core in front end and in the back end. So We think that we made a really fantastic decision and We're really excited about Drupal 8 and in the future of it and just Thank you. Sorry shameless plug. We're we're hiring Come talk to me three developers Awesome. All right. Well, thank you guys so much for hearing about our adventures in Drupal 8 and hope everyone has an amazing Rest of their Drupal con and yeah, go Drupal 8