 Okay, I guess we will start. I will tell you a little bit about what we learned from while building a distribution, and especially while trying to make a distribution that is easily extensible. Little bit about me, I'm Oscar Bestolt. I work at Bright Solutions as a Drupal developer and now as a software architect, so I plan stuff after the customer tells us what he wants and I translate this into stuff that we developers understand. I also study computer science at Technical University of Darmstadt and I run my own little business where I have actually a Drupal commerce online shop where I import, marmalade from Thailand and sell it online. In Drupal I've done pretty much everything you can do, front end, back end development, themeing, site building, so I don't know, I guess you would call it a full stack Drupal developer. And at the moment I'm mainly responsible for the architecture of Apple platform, the distribution that we are building and that's why I'm also telling you a little bit about that. And I have given workshops and trainings and talked on Drupal camps and now I can say I have talked on a Drupal con and that's why I'm a little bit nervous and I'm looking forward to your feedback at the end. Okay, so first of all I want to tell you what is our story about why did we actually build distributions. So in the beginning we needed an internet project management tool, CRM tool, something to organize the data that we work with in our company. So we built an internet for ourselves with Drupal because we realized Drupal is able to do that and we didn't find a solution that fit all our needs so we thought we built it ourselves and it does fit our needs. We then developed Airpal for service providers which was the new approach that we actually wanted to publish. So this was the first distribution that we built and it is a ERP system project management tool especially aimed at service providers like we have been at that time or we are. Then it's open source so we didn't sell the distribution but people came to us and asked us hey can you customize this? I have a little bit different use case and I want to give you some money so you can customize it and of course we did that and we then realized that we didn't have this in mind. We had this one use case in mind to build a distribution for service providers how we needed it and we couldn't think of different use cases or we just didn't do it at that time and so we noticed that it's a little bit hard to customize it and that's when we decided okay hey let's build Airpal platform, let's build a distribution that has business use cases in mind but it doesn't specifically focus on one use case but it tries to be flexible and to be a base, a platform to build your own business software on top of that in a way that you need it and then it's even suitable for non-service providers for example and now we love customizing it because our main goal was to make a distribution that is extensible that really was our main focus for service providers we had one use case in mind and focused on that and with Airpal platform we had all use cases in mind, now we had none in mind and we tried to make it extensible so we couldn't match all of them. So we actually realized that Airpal for service providers is an end user ready solution, you can just download it, you install it and it works right out of the box and if you want to customize it, it's sometimes complicated because it was not designed that way. So Airpal platform as I said, we focused on making it extensible and creating a foundation for site builders and developers that they can build their own business platform on top of it. So today I want to tell you a little bit about the tools and the modules we've used about make files distributions, installation profiles, unlink configurations, features and all that stuff because those are all modules that are recommended to use while developing a distribution and some of them we found are a good idea but maybe don't work out that well. So first of all, who knows what a distribution is? Okay, who has used one? Okay, who has built one? Okay, there are a couple. So I'm interested in your opinion after. So for this talk I tried to find out the real definition of a distribution so I looked it up on Drupal.org. Don't worry, it's blurred on purpose because I don't want you to read it, I want you to listen to me. So on Drupal.org it says distributions provide side features and functions for a specific type of site in a single download containing Drupal core modules, themes, configurations. That's how it's written on Drupal.org. When you look up installation profiles it tells you it combines Drupal core, it contributed modules, themes, configurations into one download. Another great, but it says exactly the same, it's just different grammar so can we consider it the same? And then I thought well, I don't like having two words and then not differentiating between them so I dug more into it. And what they both say it's a single download and they both say it's Drupal core modules configuration but there must be a difference. So I found on Drupal.org, complex profiles are sometimes called distros and I'm like what do you mean by complex? Where do you set the line? When do you call it complex and why would you then call it different? So let's start with installation profiles. You've all seen them, by default you have the standard and minimum installation profile and to develop these you have an info and a profile file. The profile file is like the module file for modules. These two are required and then you can also add an install file that can manipulate the installation process. And then there's make files. Make files can be seen as a recipe how to install a Drupal which contribute modules you want to download which patches and stuff. So it's actually, you write in one file a description what should be done and Drush make then can download everything that you require, kind of require in that file. Yeah, Drush can create that Drupal site downloading all the contract modules patches and Drupal.org also does that. When we download a distribution then it's actually created with Drush make. So I have a proposal for you, let's agree on this. An installation profile is something you develop because you add modules, you have the configuration that you add and the distribution is something you actually download because you would never download an installation profile by itself. So I think in this way it's quite nice to talk about it and so the installation profile is kind of the recipe when you cook something and it has all the instructions and all the ingredients and when you download it or when you start to eat it you have a fully cooked meal so that's what your distribution is. So in general when you develop a distribution you usually develop or work on make files you work on the info and the install and the profile files for your installation profile. Okay so some distributions that we have used are Commons, OpenHRM, Acquia, Drupal, Panopoli, Airpal for service providers and Airpal platform, Commerce, Kickstart, Async, Drupal but there's many more that I think are worth looking at. So what are some reasons why we should use distributions and why we should build one? First of all with Drupal distributions you can evaluate the possibilities, you can check out what Drupal is actually capable of doing, you can demo Drupal if you just want to convince the customer hey we should use Drupal, look at what can be done with it but you can also learn a lot from it, you can learn lots about how to code, how to use hooks, just look at what they do and you can learn a lot of this but you can also use them as an out-of-the-box solution so if you download Drupal Core there's not much you can do if you use the standard installation profile you can have sites and articles and that's about it but if you want to have an application for service providers with project management and invoicing and stuff maybe Airpal for service providers is the right thing for you or the comments distribution when you want to interact in groups and stuff but it can also be used to quickly build a site so when you have a foundation that you want to you always have the same modules that you enable in the beginning of your process when you work on a project then maybe a distribution is something good that brings all those modules so you don't have to manually download them and add them to your project you could build one when you want to use as I just said the same setup for example multiple times and create the same site more than once then you could use a distribution you could also look into different use cases in different markets as we do with Airpal we show case and we actually use it to use Drupal in the business world to create business applications with it and of course we can give that back to the community because we use lots of contract modules and we profit from the community but we know that the community may be interested in using that tool as well so that's why we decided to create an open source distribution our main focus is on quickly building a site so we mainly use it as a foundation to start a new site and we mostly do that because we want to often build the same site we focus on the business applications and there's some principles that you can use in every business application that why we decided a distribution is something good for that so what have we used the distributions for in general we have used async Drupal to build dynamic interactive sites so if you want to have lots of Ajax and stuff maybe you can have a look at this we have used commerce kickstart to build online shops which is really nice most of the times we built the online shop with commerce kickstart but we didn't use it on the live site I will tell you later a little bit more why we didn't do it that way but we, for example, built our own features within commerce kickstart and then moved it to the actual site we use Apple for service providers to use the business application as a ready-made business application we use Apple platform to build business applications that don't have this specific service providers use case and we used Panopoli because it brings a better user experience than Drupal Core itself and brings lots of modules like panels and panels everywhere and CK editor stuff that we use on every project anyway so that's a nice thing that they provide those modules that we use anyways so when we develop a distribution we need to differentiate between hard and soft configuration because we also introduce some logic with our distribution and this maybe not change later on but there's also some setup some settings that should be overwriteable and that the admin could change so for example the tax system or something we don't want to override the tax system itself but maybe we need to set up the taxes themselves so we would with the distribution provide the hard configuration of the tax system or the product or line item system so we can actually create invoices and stuff like this but maybe we want to provide a default tax or an example tax but this needs to be overwriteable by the administrator or the developer that sets up the module I think this shows what could happen when you change a hard configuration for example when we want to create invoices and we depend on the price field that comes with commerce of course you can change the price field but you will not be able to create the invoices so you could really break the behavior of the site but there's other things like we use commons for the project management and you decide okay commons is not the right module I want to use the reply module because it's more flexible than you could do that because we didn't specify it as a hard configuration and we let you actually override it so since we want Apple platform to be customizable we had to think about what options are there to customize a distribution and most of them are very similar to customize the Drupal core whenever we build a site with Drupal core we kind of customize it so we have the alter hooks we have preprocessing we have custom modules we have themes, sub themes but we also have features and features overwrites and stuff like this that is actually recommended to use when building a distribution and when customizing a distribution and that's what I want to talk about a little bit more now so our experience in general with the existing distributions was that it's quite often hard to customize if a distribution uses features you can't use features to customize it and overwriting a feature is quite hard but also updating can be very painful I don't know who has used a distribution updated it and stuff broke that's quite a few people but we wanted to be Apple platform to be customizable and we thought man we are kind of crazy but we accept the challenge and we will make it customizable and I think we have a very nice approach that I will tell you more about now and the modules that we use for that so in the beginning there's features the features is the tool to capture configuration and it actually says on Drupal.org that it's the tool to capture configuration for Drupal distributions so what have we used it for what can it be used for first of all we can store site config in file system which we who didn't use features okay everybody then I can I think go quicker but the main idea is to control the changes in Git to make configuration deployable to revert changes and to have a code driven development I just talked to somebody earlier who told me he would always copy the database this is what you don't want to do or if you don't want to do it you use the features and when we develop a distribution that's actually what we want we want to deliver stuff in code we don't want to deliver database so for example the content types the views, the rules the stuff that we want to deliver with our distribution so it sounds like it's actually useful but I asked my team after developing all those distributions do you think features is suitable and most of them said no if you add these two numbers up yes it's more than 100% because some people said yeah no depends on what you want to do so that's I was when I tested this presentation everybody told me this doesn't add up to 100% so I know so I also asked my team why do you think so first of all I think this is a problem that doesn't only apply to distributions but to all other websites as well sometimes features are just overridden and you don't know why especially if you work in a team of multiple people you pull your git and it's overridden and you revert and it's overridden and you revert again and you just don't know what happens so this kind of makes the development process a little bit annoying there's no such thing as a customizable features who had it that the customer wanted some text that you deploy but he can always change who had this situation people always think you could do this with features but once the panel or whatever the content is changed on the live server the feature is overridden and the next time you deploy new changes you revert the feature and everything is lost so there's no really good way to have a customizable feature the complexity of overriding a feature is quite high there are modules for them that I will cover in a second and we always had conflicts and overridden features which just didn't sound too good but some of the teams said it's very nice to deploy example configuration so for example the soft configuration that I talked about you just want to enable one type of text so the people can actually use your distribution and try it out without setting up everything so that's why some people said yes it's good for that for example we used Panopoli and we really liked the idea that Panopoli did but we installed it and instantly we had conflicts and overridden features without even touching it we just installed it and this was really not so much fun to actually use a distribution as a base for your project when it's overridden before you even touch it so yeah we didn't think that features is that that good of an idea I actually talked to my par the maintainer of features yesterday quite long he unfortunately can't be here today he had some good points about them but I still think that all those overrides and the complexity of overriding them makes it not that useful when developing a distribution so then there's features overrides and this has the sole purpose of building a new feature on top of existing ones so the idea is you have a distribution that is built with features and you want to customize it and you want to store your customizations in the files then you use features overrides to override those base features and the idea is actually quite good so it's kind of a user interface for Alta Hooks before I found the overrides module actually I would write the Alta Hooks myself and then I found features overrides and it did that with a side building kind of way how we Drupalists love it so the idea is to have a base feature in your distribution you can make changes and you can create an override feature to make those changes persistent so even if you revert the base feature because it would be overridden or your changes would still be kept because your overridden feature overrides that so your changes will not be lost I asked my team is it suitable to build a distribution and now more people said okay no it's not because there's no way of overriding feature overrides that's also what Mike Porre says he had a similar problem they used Panopoly which was built on features to build open atrium which was then using features overrides and then there was no real way to customize atrium because there's no such thing as an Alta Alta Hook so why do we think that it doesn't work in general we like the idea and it sounds good but we had many problems while using it it has performance impacts because we have the default hooks and then we have the Alta Hooks it makes the structure very complex when you look at a view you don't see where it comes from it can come from a module it can come from a feature but then it also can come from or it can be customized by an override feature and you just don't see where this comes from so it makes the structure of your project quite complex in simple use cases it worked really nice and we really liked it but then we had airport for service providers which we built on with features and we had to customize this and it just didn't work out we had fields in views and features overrides said yes it's all fine it's exported and you deploy it to your dev environment or your stage server and it just doesn't happen so tasks as little as five minutes for adding a field to a view or changing the position of a field or something like this or changing a rule it seemed so easy five minute task and then it took two hours to get it somehow in the feature but since our deployment process is built on Git I have to get it in a feature I have to get it in code and so I told my customer well yes it's an easy task it will only take two hours because I knew I will fight with features longer than I will fight with the task itself so it proved as really good idea but didn't work out so then there's features tools it brings four main features but I will focus on the unlink feature feature unlink feature so it's made to unlink parts from an existing feature and this way you can deploy something with a feature and on your next server for example the stage server you can unlink those parts and then override it so for example you deploy a panel with some demo content on your live site you unlink it and the customer can actually change the text in the panel and the feature will not be overridden and if you revert the feature it will not touch your panel anymore because you unlinked it so this actually sounds very nice as well and we didn't only use it in distributions also in other sites that we build and it kind of works in a way that it writes the configuration from your feature back in the database and then ignores your feature and then you can actually also you could probably create a new feature on top of that as well so I asked my team is that usable and they were even more sure that it's not usable and the reason is that it's again a good idea but it's again a workaround for a problem that we have and it has some deployment issues it just also doesn't work and you have to go to your live site and actually click unlink so this cannot be automated that way for non-experience users it's very complicated even our experience users when we gave them features unlinked and said yeah just use it and like wait what do I do and why do I do it this way and yeah it turned out to be quite complicated and somebody in our team said well we keep our overrides in a separate module and I don't like this idea I don't at all if you deploy something that could be changeable everything that you deploy can be changed on the live server but you don't see in that section where you can edit or customize it so if you have a field that you can or want to customize you don't see if it's unlinked or not so there's no way of being sure that it's unlinked which we didn't like either but in some cases it results the overrides so that's why some people said yes we could actually use it but the main reason we didn't like it not all components are exportable they're not supported by Ftools Unlink so we just couldn't use it I think it was actually rules that were not unlinkable and we work a lot with rules so yeah no way we could use it yeah then there's the default config module the idea is that we use features to export permissions and roles and to provide some kind of default settings for installation profiles it actually aimed at installation profiles and the idea is pretty good and it grew and now you can do much more than permissions and roles you can pretty much use everything as a default config and it serves as a set of default configuration kind of the soft configurations that I talked about before and you can always it works in a way that it only adds the configuration once while the feature is enabled and then when you revert the feature it just doesn't touch it anymore because it's default and will not be changed there are buttons to revert them but usually when you deploy your feature with some changes and you revert the feature your default config doesn't get touched anymore so the default config can easily be overwritten by admins that set up the life side for example I asked the team and most of them actually said yes this sounds like a good idea we should use this and we actually use this in one customer project where we didn't even build a distribution but we wanted to deploy some panels and some boxes with content where the customer said you have to deliver the default version, the first version and then I want to customize it so we used it back then so why did our team think that it's usable because the distribution should be usable right away you install it and you can start using it yeah the distribution should also still work when the user changes those sets of soft configuration and they can actually be restored so there is a button restore default config it's way out of focus from the feature you have to dig down deep in the modules architecture to find that little button to reset it and you have to do it when you develop the default config that you want to publish and when you work with multiple team members on it it can crash quite easily because you don't even see that it's overridden there's no indication at all and we actually had the problem that developers had to do tasks twice because one didn't completely revert the default config but changed something in the default config and featured it and the first things were gone which was quite annoying so the development process with the default config was actually not that nice so we came up with a module we call unlink default configurations and it, this is a quote from ruble.org it provides possibility to move site configuration from files to database with just a couple of clicks so the idea is we have our configuration in the feature or in a default hook in our module and we usually can't feature it then so we want to move that configuration back into the database so we can then export it again with features for example. So yeah, as I said, you can change your configuration you can change views, panels, content types, rules everything that a distribution usually provides and you can move the configuration that comes with a distribution to the database and then actually customize it. I don't know, has anyone tried to customize the card view that comes with a commerce module? Was it fun? No, the problem was you couldn't feature it, right? Yeah, okay, it wasn't fun. So this module actually works with any kind of configuration that comes in the default hook it doesn't even have to be a feature. So you can then change your configuration your view, your rule, whatever and export it again with features. The problem is when you have a default hook that brings a view you can customize the view in your development environment and then you go to features and features says yeah hey there's a view and you can export it and you click export and it doesn't do it. It just doesn't do it. Nothing happens in the feature itself and this is the problem that we solved when we completely copy the whole view into the database removing it from the, no it's still in the code but we ignore the code base then we can then actually export it with a feature again or with a bulk exporter. So our team which actually developed this module now likes the module because it actually solved our problem that we had with features and features overrides. I asked why do you like it? Well it's easy to use, it's just some clicking of buttons. I want to unlink this view, I want to unlink this rule and you click save and everything is fine. It's useful when you want to customize a distribution. As I said, the distribution delivers configuration in default hooks and you want to change those you can just unlink them from features or from default hooks. Yeah and it helped our team to make data exportable. So this actually solved our problem of re-featuring and re-exporting and it doesn't matter if the configuration we want to change comes from a feature or comes from a module and that's when we decided okay with this approach we can now deploy all of our configuration in Apple platform in default hooks and we don't even need features because it doesn't matter if it's a feature or not. And then when somebody wants to customize Apple platform he can unlink the stuff that we provide that he wants to change and use features as in a regular deployment process to actually deploy his customizations then. There's also some tools that we know about that we haven't used for example profile and profiler builder that help you with building the profiles and distributions but we did it by hand and then there's apps and features set. I know they exist and I heard lots of good stuff about them but we haven't used them. That's why I just mentioned them here but I can't tell you any experience because we just don't have any experience. Yeah then there's that thing with updating distributions. You can always use strush up and it updates your core and it updates your contract modules but most the times distributions also patch modules. They include patches in the make files for the modules and when you just update the module the patch gets lost and maybe the distribution completely breaks and I've seen that happen lots of times and I see it in the issue queue that people complain to us hey your distribution sucks I cannot update it. And usually the biggest issue is that patches get lost on the way. So the general approach is telling people hey you wait until we update the contract modules and then you only update the distribution as a whole thing. But we are not happy about it. The users that use the distribution are not happy about it actually nobody is. And then there's the module distribution update status manager which actually forbids you to update your site. So when you go to your update report it only tells you hey you are using Apple platform or you are using OpenHGM or you are using Panopoly and it's up to date. It doesn't tell you all the contract modules anymore because you shouldn't care about them because you don't want to break them. Of course you can click a button user I know what I do I want to do it anyways then it lets you do that but in general this is a nice approach of actually actively telling people hey yes this contract module it may be out of date but it's not even a security issue so just leave it the way we provide it. I don't know who has heard about DropGuard we have been very loud about DropGuard here. We actually have a possibility to update distributions and we also have a possibility to detect patches in contract modules. So when you want to still update your distribution maybe you can have a look at that because we actually compare the code on your server and the code from Drupal.org and we create a patch and then we update the module and we apply the patch and you should be good to go. So if you really want to update your contract modules right away and not wait for the distribution to be updated maybe you can have a look at DropGuard. So in general I also ask the team anything else you want to add to my presentation anything you want to tell the people and everybody said well developing a distribution is not an easy thing and it requires a lot of work and oftentimes you don't even see it that it requires so much work so they just want you to know building a distribution is lots of work. You should always know your target audience and the use case is exactly to and this applies on do you want to build a distribution or do you want to use a distribution and if you use one does it exactly do what you try to do with it. You should not add all the requested features we get feature requests for Apple in the issue queue on a weekly basis and lots of the features are like one use case again that only this person needs so we tell them hey maybe you build it yourself. We don't want to focus on specific use cases with our distribution we want to make it flexible and so we don't add your feature request now but of course we help you to actually implement your feature request. Sometimes it's a pain to keep all the contract modules up to date as I just said it's quite hard to when you have lots of patches in your distribution and you as a maintainer need to update those modules of course you need to check why did I have this patch is this patch maybe included in the new version of the module that I just patched so I don't need it anymore. If it's not included does it still apply do I need it so this is stuff that you need to consider. If you know Drupal it's perfectly fine that you use a distribution because it's still Drupal you can customize it with views with fields you can still do whatever you want but we have also experienced people who install a distribution because they think it solves all their problems and they have never heard of Drupal before and then they write us in the issue queue hey how can I change the background color of this program and I'm like maybe you use CSS oh how does that work I'm like have you heard about Drupal no what is that so please don't forget your distribution is still Drupal which is nice for us Drupal developers but for somebody who's not a Drupal developer yeah and the learning curve still exists so when you want to dig into a distribution don't forget it's still Drupal which is sometimes hard and now we add features and functionalities so we actually add to that complexity and there's often a learning curve for the distribution itself that adds on top of the Drupal learning curve. Sometimes it's not a good idea to start a distribution to start a project from a distribution only because it adds lots of stuff that you need but sometimes you need to evaluate do I then need to customize the distribution so much that I spend more time in rebuilding those features that I need for example if I use Panopoly but I don't need panels and panels everywhere I only want the CK editor maybe it's not worth using Panopoly then but it's worth adding the CK editor myself. Everything will be better with Drupal 8 everything is somebody in our team said to be honest I looked at the features module for Drupal 8 which is only developed to build distributions but I think it will still bring the same problems that we have faced that I just told you about and Mike the maintainer of features and features overrides he said it's not start yet but we will also provide features overrides and I'm like okay then the problem that we have had while developing the distribution they will not go away in Drupal 8 if we use the same approach so I guess we will with the CMI I'm not sure if we still need something like the unlinked defaults module that we provided for Drupal 7 but I guess we will try to go more in the direction like this as well with Drupal 8. So what are the three things that I want you to take home? First of all have a look at existing distributions it's fun to see how people did stuff maybe you can learn a lot and maybe you can even speed up your development process and maybe you can use one of them. Try building a distribution and if you're strong enough like we are try building a customizable one and maybe don't use features I know if Mike would have said here he could tell you that he could use features but this is our experience so maybe we can start a discussion about that. Yeah and maybe have a look at our unlinked defaults configurations module even if you don't use a distribution if you only use the commerce module which brings a view for the cart and you want to customize it use unlinked default configuration to unlink that view from the module customize it as you want and put it in your feature. Thank you very much. As a thank you I brought some nice posters if you like I have a couple here and now I'm open to some questions. So many all at once. Yep so the question is if we evaluated to build everything from Drupal APIs. Yes in Apple we use the Drupal API so to deliver the views that we deliver we use the defaults hook and this is Drupal API so yes but that's exactly what we do. So we use the user interface to create that view and then we click the export button and add it to our code in the default hook and this is Drupal API. So yes we only use Drupal API when we don't use features and features also uses only the default API. So yeah we actually use the API. Okay how do you handle updating the base code and your client specific code in the repository view? We have I think three or four different repositories and then we use sub modules and sim links and stuff like that. How do you handle updating client specific stuff and client themes with your base code? Okay so it depends a little bit on which features of the distribution we want to update. With the approach we have when we provide a view for example in the default hook and you use that distribution you update the distribution and the code changes you get all the updates. Once you unlink the view and put it in your feature you will not get our updates anymore. Is that answering your question? Yeah so you basically break the update path for all the base stuff. Kind of yes. Everything that you customize is then in your hands we have no chance to do anything there anymore. But that was a discussion that we had before and we actually said this is the way we want to go because then it's still easier for you to customize it. So yes, we don't have a chance to update your customization anymore. Any more questions? Okay and then thank you. I just want to remind you for the Friday sprints I guess you've heard often about it but please attend the sprints and make triple eight happen and then I ask you to give some feedback. It was my first triple concessions so I'm very excited about your feedback. Please be honest even if you didn't like it tell me then I will not annoy you next time. Thank you.