 Good evening guys for today. My topic is media publishing platform on Drupal 8. So let's get started. So this is me. My name is Kapil and I work for Siegen as a Drupal developer from past four years. And who are we? We are 17 year old company with 350 plus people and we are Asia's largest Drupal company. So for the digital publishing platform or the project I can say, building a digital publishing platform on Drupal 8, migrating 19 plus brands from various CMS frameworks onto the new platform, content dating back to 1995 already migrated over 2.25 million stories. Start with building core and then release brands on a rolling schedule. So as one company and one team deliver a unified scalable and highly configurable digital platform that enable our business teams to quickly and effectively tell the stories that are customers value. So the challenge was each brand in the crane family was operating on its web platform. Rolling out a new digital initiative across all brands would require a lot of coordination and time. So this technology system are introduced operational ins efficiencies as there were no central governance place as all websites were working independent of each other. Storage costs were rising and sites were not managed efficiently. So the project goals and power brands allow the brand to do more, take control their websites and rely less on developers, create new landing pages, managing their homepage layout, manage man news, access control, etc. Last year alone in the discovery phase, we have seen in the ecosystem that 58 tickets related to updating the footer. Let's be developer can focus on innovation. So the idea was to empower the brand team so that the majority of the site pages and features could be set up by them without needing any development support. Giving more editorial capabilities so that editors can do more rather than just creating content. So as the picture defines first we have built core and then we can roll out the brand. So develop ones use anywhere. So all brands should reap the benefits of best in class features. Brand X does something well adapted and then distribute to others. Reduce maintenance cost over time. Maintain code standard and best practices like SEO, accessibility, analytics across all brands. So all common features functionality goes in core profile. So we have created one base profile from Acrea Lightning. And we can see the long term benefits for future migration redesign common feature across all brands and easy to roll out a new feature. So you can see the picture defines that you can divide it into three pieces. So you can see the social media. So we have created one social media component. So let's suppose brand one, two and three. So some brands have some icons and some are having not. So we have created one social media components with all the icons, social media icons. The one which is needed the brand can be the brand or the editors can configure that on their own. So all of them on the all of them icons component is be implemented in core. So rest upon the brand how they can use that. Moving with the next slide. So the discovery phase. So agreed to invest in core platform first started putting features into core and brand buckets established a common language around content type layouts, components, etc. Settled on a multi site architecture came up with high level timeline including how much time it will be invested into core building out. So the approach was to leverage aqua lightning or distribution of to enable component based development as well as deploy a lightning sub profile on a multi site architecture for all the brand sites. So we propose a standardized the component as a development progress. The idea was to bring better governance to have a tighter grip tighter grip to the architecture and ensure a documented process approach towards the component. So this is how the development was planned. So we have built out the core which says most of the functionality. So the core could have 60 to 80% of all the brand features out of the box each site to be then built uniquely with its own theme and UI components and each component to have a set of configuration like views and display modes allowing each brand to customize the site to their own. So for decreasing the language gap so we call them components but in Drupal I can say that is a block type. So high level estimate after common features identified. So that was the most part in the discovery phase proceeding with next. So this is a very good slide. So we started with the core platform development two years back and came up with rolling go live schedule for the brands. So as you can see first first three three to four months we we have spent our time on the core part and then we are ready to launch our first beta. So in the first beta we have five sites that will be moved on Drupal 8 on a multi site architecture using a common profile. And data migration scripts were ready and brand training it included of one month and rest of the Delta specific to brand can be implemented at brand level. So so these are the projects and the timeline so you can see the first five websites deep these are included trains Cleveland trains Chicago business trains Detroit and that ad age. So that was the first beta. And once it was completely tested we can create a we can create we can roll out a new brand in just 30 days because we just need to migrate the data or some delta data specific to brand. So the project and the execution time. So so first we created a platform so we were around 40 plus people. So you can see development building and product. So 25 plus distributed across Detroit New York Goa and Delhi Drupal 8 development front end team release managers. Then small team set up for each brand. So web produces adopts audience management developers brand specific development assistant with site building. And for the product team governance team for business analyst UI and USD proceed with the further slide. Next slide. So platform features and demo. So site building power of group late multi site architecture and config management and integration of pattern lab. So some of the highlights. So key concepts. So panel and panel is a layout discovery block as entities paragraph and quit edit media entity. So let's get started with the demo. So I have created this video. So I have created one section pages one section page. So currently as I am creating a page with a component that I need. So I'm just going to the manage content app create content. So I'm just filling the required fields. So this is our added feature component that we created. Just bear with me for the site building part. Now you can see the featured component is ready. Same. I'm showing one more component that is being added in this video. I just go to manage content create content or you can create. So this this this component was custom created that is coming from business logic. So the top 20 block. So there are the content top 20 articles or work items. Yeah. So you can see how easy it is for editors to create a page. So just now I have created one page and this was created by editor. Some of the highlights we have implemented as I mentioned in the previous slide. So we have used paragraphs. So this is our paragraph field so we can add any component. So let's suppose I want to create an embed block. So just type your HTML code pasted here and you are ready to go. Same as photo gallery components select any photo gallery. And even we have a photo gallery component for if where we can select multiple images and we can create photo gallery content. Yeah. So that's it. Let's move with the slides. So these are some highlights the from the demo. So first we created layouts and these are the components. We can say block types. So as you may define landing page one and landing page two have the set of components as editor wants as per their needs. This is the real real example. Most components were developed as block entities. So you can see the styling of this component can be reused. So the code really the usability is increased. So this component the custom content studio it we have a promo box component and example of a social media component that every site uses. So this is our platform architecture. So we have created our custom profile from aqua lightning where we kept all the common features and content types or block entities you can say article event award paywall. Then we can roll out brand one and brand two out of that. If brand one needs article event award. Sure it can use that if other features they can just disable it. Same as brand two. If they need analytics and personalization they can use that as they can skip. So that's for that's the same for team also. So in the custom code profile it is extended and team is being created. If you have specific color styles or anything else in the team you can do at the site level. So the platform architecture for Patel app. So we have you go global style guide using Patel app center place to see all the components within the platform as well as all brand sites allow front end developers to work independently of back end. So the components we have created. We have created our components on Patel app so that front end developers does not wait for the back end data. They can directly created on the pattern lab. So main advantage was you can be done directly on the pattern lab. So in our project of front end tickets were passed before the back end implementation and for the back end up once the functionalities is completed. Then we can directly reuse that components. We can just directly replace the pattern lab the twig variables with our variables. So for configuration management the module will be added in the core profile so that it is available for all site in a multi site environment. Each pop up configuration YAML can be exported and shared among multiple sites maintained by a Drupal config API. Brand have the ability to create pop up for their respective sites. We can still push code changes to all brands. Yeah. So I'll just in the coming slide I will get this architecture in detail. So we have divide we have divided the configuration into four categories core configuration config which gets imported at the time of site setup like content types paragraphs type field config etc. Site specific configuration config specific to a single site like placing a newsletter block on our one site and not on other site. Then environment specific configuration config related to the third party API like S3 buckets or Google analytics. Like on stage we are using sandbox account and for fraud we have a live account. And then over readable configuration like block labels view mode selection block placement. So which can be changed by site iters. So we have used config ignore for this. So helpful modules for config management core configuration management. So with the help of core configurations we were able to build core profile which allows conflicts to be imported at multiple levels. The system is designed to make it easy to take the live configuration test changes locally export them to files and deploy to production. So config split. So it just allow you to create a directory wise configuration. You can set the directory to death stage fraud and you can directly import that on the environment basis then config ignore. Put the file name in the it gives you a text area in which you can put a file name and that is not been imported. If you run the CIM or if you import the configuration. So platform architecture for config management. This is how we kept our configuration for content type paragraph field base field block config. So we have a conflict site is in the death stage and fraud that I have discussed in the previous slide as per the conflict split module provide this functionality. Common conflicts file. So we have a conflict site a then common files will be in the same directory. So using pattern lab implemented front end templates on pattern lab. So we can even the tickets can be front end tickets can be tested on pattern lab directly. So templates for ready integration of front end template with component backend component render on websites. So this is our theme path structure. So we have created one theme in our profile. So pattern lab templates can be called from that. So in the form of atoms and molecules. We have created that that increases our usability of the components. So this is one sample pattern lab component you can say. So title image and the little sub headline that can be considered as atoms and these atoms as in the component if we make them together. It is a simple promo box component that is being used in the promo box. So if this kind of styling or title image sub headline it needed anywhere we can directly use that using that molecule. Or if we just need this type of image or title we can use that from atom. So continuous integration are just we have this is a long one. I'll just describe that in short. So we have a activity set up on our devs machine. So that is the developer part and the manage one. We have a bid bucket server. So we create pull request or push the code on our bid bucket. Then for Jenkins a CI server we just we have a Jenkins script that fetch the code and create a builds from the bid bucket. Then after that we have we have hosted our sites on Acvia. So we just for dev and stage we have auto deploy but for production we just need to manually switch the tags. So that's our deployment process. That can be covered as a separate topic itself. But now we are running out for the time. So this is our summary core modules and concepts in Drupal 8 such as layout discovery and configuration management having block as entities are the backbone of our platform approach. Significant improvement in media management and paragraph modules which has improved editorial experience. You can set up your platform as multi site as well as a single site installation. We maintain a maintaining a combination of both. So a strong government governance model should be in place. Otherwise the platform can get out of hand and implore implemented QA automation. We have used behalf extensively for this project that generates one report that everything is working fine. When we roll out a new brand or we deployed our code on part. Yeah. So. So for one thing I also want to cover the caching part. So we have four level of caching in our application. So one is application layer caching so provided by Drupal itself or Drupal cached tags of plugins or entities. Then we have interlevel caching the upcode caching and memcache so database query are on men memcache if if on only if we update any article. So the first request is going to the Drupal all other are handed by one is and we have a third party caches that is reverse proxy or one is cached tags and for the CDN we have cloud player the time based caching. Yeah. So that's all from my side. Thank you guys.