 Okay, so I'm going to talk about how not to build and maintain a Drupal site. The contents of this session primarily are divided into seven different parts. How not to plan a Drupal site, how not to build a Drupal site, how not to theme a Drupal site, how not to code a Drupal site, how not to configure, host or maintain a Drupal site. From all points across various areas, who am I to talk about all this? My name is Prasad Srigaokar, based in a city called Aspune in India, Western India. I have been a Drupaler since Drupal 2006, Drupal 4.7 days. I was running my own Drupal services company in India and where I happened to work on around 200 odd Drupal projects for clients from almost 12 countries over five, six years. Currently I work as a curriculum developer for Acvia. I develop Drupal training programs and I deliver those across continents to various clients, customers, enterprises as well as individuals. During this journey of being a Drupaler from 2006 onwards and working on all these projects, I have spent endless sleepless nights maintaining, managing, working on Drupal and those sleepless nights were primarily because we did something wrong. We did something wrong and the site, something went wrong with the site and we tried to fix it, debug it, work on it. So that's why we are talking about why we talk about what not to do rather than what to do. Now, if you go to Drupal.org, if you go to documentation, if you go to Drupal Planet, we find thousands of blogs talking about what to do. So there are to-do lists. There are best practices lists. There are lists where we learn about how to work with Drupal. Very few lists about how not to work with Drupal. The typical first Drupal project or first few Drupal projects that we work on. This is how it happens. Project starts great because Drupal is in our hands. We propose Drupal to client. We do very fast prototypes, very fast builds with using all the tools of Drupal. We hack something. We make something work. We do workarounds. Project goes live. We go for a beer and midnight we receive a call from angry client. The site is crashed. That's how typically Drupal, first few projects, they happen. Why it happens so? Because there are multiple ways of doing everything in Drupal. There are multiple ways in which we can achieve a certain functionality, achieve various pieces of functionality and typically in first few projects, the ones that we choose, they tend to be wrong. They tend to be the incorrect ones. So even though site goes live, even though the functionality works, even though clients see what they expect to see, something is wrong and when it goes live, when there are lots of visitors to the site, then only that the thing that we have done wrong, that actually magnifies and that becomes our nightmare. Another reason is that we can follow hundreds of best practices. They can all go unnoticed, but we can just implement one bad practice and that practice can be disastrous. And that's why it's extremely important to know what to do, but it's much more important to know what not to do in Drupal. The selection basis, the criteria on which I have selected these practices are like three important criteria is the security. Anything that makes our site less secure, it's something that we should not do. Performance, that is anything that makes our site less performant, we shouldn't do. And efficiency, anything that decreases developer efficiency that we should not do. So these are the three areas on the basis of which I have selected the practices which we should not do while doing a Drupal development. Of course a disclaimer, these are based on my experience, my research. They may not be a comprehensive list, I might have missed on certain practices and you may disagree with many of the practices, but then you are free to try them on your site at your own risk, obviously. So let's begin. Let's see how not to plan, design and architect a Drupal site. The first question you should really ask is that, do you really need Drupal? At the beginning of any project, just because you know Drupal, do you want to recommend that to the client? Now Drupal is a great content management framework, we can do a lot of things with Drupal, but if all your client is asking for just a single landing page or a single form to submit data to something or four or five pages static website where the content is not going to change for like years or months, do you really want to recommend Drupal for such small projects? Are you trying to kill a fly using a cannon? That's the first question you should really ask. Second question again, do you really need Drupal? Are you trying to fit a square peg into a round hole? Now Drupal again is a great content management framework, we can do a lot of social content sites with Drupal, lot of really content related sites in Drupal, but can you really build a three dimensional multiplayer game using Drupal? Can you really use Drupal for a missile control system? You cannot, you can build it for any kind of content management system, any kind of possibly a social framework, social content framework, possibly for commerce, but at the beginning of the, I have seen several projects where Drupal was suggested, Drupal was pushed by the agency because they had Drupal capabilities, but the requirements actually didn't require, they didn't call for Drupal, they didn't have a need for Drupal. So at the time of architecture itself, the first question should be asked, do we really need Drupal for this? And yes, if you decide that we want to go ahead with Drupal, Drupal is a right fit, a right solution for this type of problem, then we start with the second question, and not to do is that do not start with Photoshop. Now clients are desperate to see new designs, clients are desperate to, from clients perspective, from them their website is their website design and not functionality. So they are demanding, they will be demanding for design, show me designs, I don't want requirement documents, I don't want workflows, I don't want wireframes, just show me the design directly. And that's the danger, because workshop documents, even though that might be a good way of doing designs, but they are not good ways of defining the functionality of a website. And modern web is becoming more and more complex. There are lots of workflows, lots of functionalities, lots of things which need to be defined at the beginning of the project, which cannot be done using Photoshop. So start with requirement specifications, start with workflows, start with wireframes, process that you define and follow consistently, but never start a website design project using just Photoshop and a website design. Most of the times you go to a new client, you go to a new domain and you see that there are some requirements which you feel that are very unique requirements and possibly no one in the world has done this and I'm using Drupal, but I might need to build some, develop some custom module for this because it's a very unique requirement. But think again, now Drupal consists of a lot of rich APIs and there are like thousands of modules and Drupal now powers, I think 4% of the web, which is like a few million sites in the world using Drupal across like 150 countries. So the requirement that you think is unique might have been encountered by someone else somewhere in the world, which basically means that there might be a solution that they might have contributed back to the community. So just do your research, go back, check whether your requirements are really unique and do you really need to reinvent some wheel in Drupal. If you need anything from like Salesforce integration to CRM integration to buildings like e-commerce and integrating with some unique third party system, most likely that you will find a solution that it's done in Drupal by someone somewhere in the world. One of the most frequent mistakes done by a novice Drupal designers, Drupal developers is that the entire site and all the workflows are built by keeping in the end users of the site, end users of the system in mind. So which means that how visitors, how mostly anonymous visitors will see my site, that's what is kept in design, but not the editors. Now site editors, site content editors, content managers, site owners, they are the people they are going to use your site day in and day out. And unfortunately in Drupal 7, the out of box editorial experience that we give to editors is not that great. It's not that intuitive. They can't even find their content on the content overview page. They can't find users on users overview page. Now all that is fixed in Drupal 8, but in that time, you need to keep your users, your editors, content editors in mind at the time of design and architecture of site and make sure that your site is designed. You have their workflows defined and make sure that their day to day life becomes much easier by implementing Drupal. Otherwise from day one, they will start hitting Drupal and they will say that our earlier system was good and I don't know how to go and how to edit content and I can't use this system. So don't do that mistake. Keep editors in mind, keep editorial workflows in mind and make their life much easier at architecture and planning level. At the time of beginning any new Drupal project, never ever underestimate fresh research. You might have done 3 or 4 or 5 Drupal sites, maybe 10 Drupal sites, a new project comes in and at that time, you know that you think that I know all the answers. If the client wants X, there is a Y module. If client wants Y, there is Z module and I just know all the modules. I'll just put them together. But the information, especially technology information is the most perishable commodity. Just perishes like within weeks, possibly within days sometimes. Drupal community moves very fast. There are lots of developments happening in Drupal community all the time and your knowledge might be outdated within a couple of months time. So whenever there is a new project, whenever you are receiving new requirements which you think you can solve by using certain modules, just give it a fresh look, possibly ask a new intern to just look into those or you yourself with fresh eyes, go to Drupal.org, search whether my solution which I thought is still valid or not or if there is a new development which I should learn. So these are the things which we should keep in mind while planning, architecting or designing a Drupal site. Now let's talk about what not to do when building a Drupal site. The first rule about site building is that do not program sites, build the sites. Now Drupal provides, it's a content management framework, it provides us with fantastic tools for site building, fantastic tools like Drupal's core entities, content management, content types, blocks, views, taxonomy terms and main nodes. Now using all those, can we build all the functionality which is required? Just find out. There are modules which extend this functionality of content types, views, menus and taxonomy terms. Just use those. Try to use as many built-in tools given by Drupal as possible to build Drupal sites rather than trying to be programmer rather than trying to program Drupal sites. So build them as much as possible. When building the sites, the important factor, don't forget there is built-in reusability in Drupal. Are you using several content types which are almost same but just couple of fields different? The best example are something like article content type and news article content type and company news article content type. All might have exactly same fields but just the types still be defined as different. So instead of that, can we use something like a taxonomy term to distinguish those content? So think of reusability, think whether you are doing redundant activities, you are doing redundant designs while designing or building the site itself. Are there any content types like zero or one content, possibly something like you thought that my front page should have some unique fields? So having that for that purpose, let's define a content type called as front page content. And then in entire lifetime of that website, you just added one node for that particular content and that set that as a home page. Now is that the right way of working with Drupal? Now what is wrong with defining just content types with lesser number of content or just zero or one content? You define anything as a content type then at the back end, the entire node system comes into play. So there are all the hooks related to node they come into play and every time there is a edit or update of that, all that system runs. So do you really need that entire machine, entire engine to run? So always do analysis of whatever I'm defining is that really a content type or not? The second thing about reusability is about fields. Now Drupal 7 provides a fantastic way of reusing of sharing fields. The image field is the best example. Now if you take image field and just the same field, you can actually reuse across multiple content types. Now what's the advantage of reusing fields? If you have seen Drupal's architecture at the back end, one table is created per field. So which basically means that if you create like five fields for images, five tables will be created and there are likely to be complex joints when you run view queries. So instead of that, if you actually have just a single field, which is shared across multiple not only content types, but multiple entities like even users or taxonomy terms, actually it becomes much more efficient at the database level. So sharing fields is a good idea when that she field will is likely to have much more shared properties across different entities. Another advice, which again, while defining content types, once any Drupal after like three or four projects gets a hang of what content types are and what beautiful things can be done, if you just define a content type and build a view around it, starts to make everything as a content type and then build a view about everything. So is that really a right way of doing things? Drupal 7 with a module like entity construction kit, it provides us a way of defining custom entities, custom entity bundles. So actually instead of if you want something just to be in blocks, but don't want to provide custom blocks to our customers, we tend to give them as content types, then people add content types and we build a small view to show that as a block. Do we need to again generate entire or use entire node machinery for that? Just define your own custom entities and use them expose your content entities to views and use them in views. That could be a right way of working with Drupal. When you are using site building in Drupal, understand everything that is provided by Drupal site building tools. Simple example of block visibility. Now if you are using blocks, obviously your Drupal site will use a lot of blocks and if you want to show a certain block on say front page, but not on inner pages, if a person doesn't know Drupal site building and knows HTML CSS a lot, he will just use display none in his CSS using conditional IDs and classes. Is that the right way of doing because if you do CSS hide, the block is still rendered by Drupal, but it's just not displayed in the browser. So we are making our system to do a lot more work and then at the end at the browser level we are just trying to hide it. But Drupal blocks provide out of box way of defining visibility. So when you are same is to about say the field labels. So your content type has field labels, every field has a label. If you go to contents display settings, you can actually manage those labels to show on the top or on the left side or hide the label. Now if you are generating a label rendering it towards the browser and at the end if you are just adding a CSS hide, then actually you are making the entire machinery generate a lot more content and just hiding it. So for slicker performance, make sure that you really understand or your site builder really understands all the possibilities about displays and rendering given by Drupal's core as well as contributed modules and always work on that CSS hiding, CSS visibility none should be the last possible option. In fact that should not be an option for rendering any output in Drupal. On the live site, never use these modules. Drupal core has a statistics module which actually gives us a per page view, per page count. Now why this should not be used on live site? Because every time there is a page view, every time someone, some anonymous user comes to our page, it needs to go and create update entry in the database. Which means that there is a bottleneck always created, how so ever caching you do? It will always be a bottleneck that every time there is a visitor, your database query will run and your slide will become slow. Now what's the option for that? Use something like Google Analytics, which actually doesn't need to go to your database but collects the data at some outside place. So there is a solution. Same is true about database logging. Now by default in Drupal 7, when you install a site, database logging module is enabled. What that module does is that every type, every single event in the system that is recorded at the database level. So it creates a database entry for everything that happens to the site. Now why that is bad? Again there are thousands of anonymous users coming to your site and even a simple thing like Fevicon.ICO missing is recorded in the table level. You don't need to record all those logs. If you need to record all those logs, use a system, use a module which is again a built-in module called as syslog. So don't use database logging module because that's a bottleneck that will create, make your site die literally when there are the traffic spikes. Use a module called as syslog which will actually still log all the events but in the system file rather than in the database which is much more efficient. Theme developer module, again that's a module meant to be just for development purpose, just for finding out the IDs and classes that you want for theme development. It adds a lot more markup in your file and it's just not recommended to be used on the production. Similar things about all the UI modules. Every module which ends with UI, things like views UI, so those modules of course they are not danger. They just add slight performance overhead. Actually you don't need those modules on your production site. How to work without those modules, we'll see in later slides. Never use these modules. They are going to someday or the other come back and have impact on your performance. Views underscore PHP is an evill module. Never ever use it. Someday or the other it will just kill your site. Being PHP developer it becomes very tempting to write some PHP code within our views. Write some, add a contextual filter and within that write a SQL query with in clause and all and it just it will work fine when just the developer is working because that's just one page load. But if it, if your PHP code runs in a loop on a view which returns like 100, 200 rows that's that's going to be a disaster for performance when the traffic spikes on the site. Another important factor in site building is that never, never ever write PHP code in blocks or using or pages using PHP filter. Now again, it's very tempting to do it. You just go, you just enable PHP filter module and then you create a new block to change the filter to PHP filter and write whatever code you want. So your client wants say five latest products purchased or five latest products to be shown as a block. You don't know how to use views. Just go to a block, enable PHP filter, write PHP code and it works bang but why it shouldn't be used PHP in block that to three major reasons why it shouldn't be used Drupal's PHP filter. It uses a PHP's eval function to evaluate and run execute that code, which is much slower than the standard PHP code being run. That's first thing. Second thing, PHP blocks, they're not cached. So anything that you write by using PHP filter that is not cached by Drupal at any level, which basically means that by bypassing the entire Drupal caching system, you render your site and at the end level when it's there, it's loaded in the browser that code executes that will make your site significantly slower than what it should run. And the third reason why it shouldn't be done is that any insecure code written over there is likely to make your site much more vulnerable to security attacks. Now what could be as insecure code? You just write when you use Drupal and when you use Drupal's modules to write this functionality, you use Drupal's database abstraction layer. Now you use Drupal's sanitization functions for handling text. While writing blocks, while writing PHP, you will not do that. And which basically means that your site will be much more vulnerable to accesses and phishing attacks than it would have been. So these are all the cautions that we should take while building a site. Now let's talk about theming. So what not to do when we are creating custom themes? So first rule, do not put content in templates. Now in Drupal's PHP template system, the templates are used for generating markup. The templates are used for generating Drupal's modules provide you content in an array and templates just just put that content in markup and provide the ultimate generated HTML results to the browser. If you put content in markup, if you put your content in templates, it will still work. If you do content template overrides and put specific content, it will definitely work. But that's not the way that will make that content completely uneditable by the editors. It will make that content completely un-cached and it will be actually just abusing the content management framework and content management systems. I have seen people doing node-id.tpl.php and then put specific content within that so that it's rendered fast. But that's just absolutely if you actually are overriding a lot of templates and then putting a lot of custom content in there, just rethink whether you have either really understood Drupal or whether you are really using Drupal to its greatest possible extent. Same thing, never put business logic in templates. Again, templates should be used strictly for generating markup. If you need to run any business logic, could be as simple as generating a random number and providing it to your template. Never put it in your template.php. Never run any PHP code which contains business logic blocks in templates. Again, it's not cacheable. It's not changeable. It's not modifiable. Consider building your own module, which does that or consider using something like pre-process functions to use in your template.php. Entire data given by Drupals, all the modules can completely be overridden. But the right way of doing that is to use pre-process functions in your module or in your template.php. But never ever modifying that by writing business logic in your template files. So again, if you are writing business logic in template files, just reconsider and never do that. Third rule, do not hack any core theme. Those who are new to Drupal, it's very tempting that they see that Bartik theme is nice, but I want something slightly different than Bartik. They just take Bartik and they start modifying CSS. It will work. But when you upgrade Drupal for the next time, all your changes will be lost. So never hack a core theme. In Drupal 7, there is a possibility. We can actually just extend an existing theme by creating a sub-theme. Now, any theme in Drupal can become a base theme now. It was just not like Drupal 6 where there was just only a handful of base themes. Any theme can be a base theme and you can just create, extend it by creating your own sub-theme based on a base theme. So always use this logic. If you like a theme, if you see that anything that you want or most of the functionality and design that you want is already existent in an existing theme, but you just want to do some changes. Just create a sub-thing by extending that and add your changes. Now, let's talk about what not to do when writing custom code. How many coders here who develop modules? Wow. So first rule to you guys, do not write custom code. Don't rush to become a Drupal programmer. Be a Drupal developer because when we have a hammer, everything looks like a nail. So when you have a powerful hammer like Drupal's API or Drupal's hook system, every single problem that you see in Drupal, you think that I can solve using hook XYZ. I can just use that hook XYZ in my system and I'll just override it and I'll just add whatever function or whatever custom thing that I want to implement and it will just work. Don't do that. Again, go back to the first rules which I told. Think whether you can do this using site building. Think whether you can do this using contributed modules. Think whether whatever you plan to achieve in the site is there a simple, easier, better way of doing it, the Drupal way of doing things rather than writing custom code. If at all, still if you had to write custom code, do not write too much custom code. Now, what is too much custom code typically based on the, the experience and analysis of various projects, people say that between 70 to 80% of any sites functionality should be built using Drupal's given tools and only 20 to 30% effort is typically devoted towards writing custom code in a project. So if you are writing much, much more custom code than this, if your entire efforts are towards custom code, just revaluate, just think whether you are doing things the wrong way and are there any better ways of doing things in Drupal. If you are writing code, next important part, do not ignore coding standards. Okay. Now I know that a lot of people follow coding standards, but everyone follows his own coding standards and they are not coding standards. So if you go to Drupal.org slash coding hyphen standards, there are a list of coding standards across documentation, theming and module development, which are listed by the community perfected over the years, always use that that makes our code readable to other developers that makes our code portable that makes in future, if you decide to contribute your module to Drupal.org, that mode is really essential, really helpful, always follow coding standards, whatever idea that you are using like PHP storm or net bins or a eclipse or anything else, there are Drupal plugins available to almost all the popular ideas which actually make sure that you while writing the code itself, you are following coding standards. If not, after the code is written, there is a module in Drupal called as coder, just use that module to find out what coding standards you are not following. And it's very easy. They are like, it's not like very gigantic coding standards, seven or eight rules which we need to follow on which are very easy to follow, which makes our code much more sturdy and much more portable. While developing modules, make sure that you are not vulnerable to attacks. Now, what what what what type of code becomes vulnerable to attacks? Now, unsafe user inputs is the most prominent source of any type of attacks. Now, what is unsafe user input? It could be literally anything. Now, you are allowing users to write comments on your site. Now, that is a user input. You are allowing even authorized users to add notes to your site. That is user input. You are allowing your editors to edit blocks. That is user input. So it could be any user input which gets stored in the database. And in your module, if you are displaying that content directly without doing any sanitization functions of Drupal, you are exposing yourself to a much higher risk. Now, there are lots of sanitization functions or other four sanitization functions provided by by Drupal's code. That is, we can do a check URL. We can do a check plane. We can do check, check markup and we can do check accesses. Always run your whatever you are willing to display on the site. Your module is displaying. Always check your input, the input that you are getting. Always check it, wrap it around these functions. So that all the unsafe input is properly tripped out. Same is true about using Drupal's database API correctly. Now Drupal's database abstraction layer has completely changed in Drupal 7. And there are lots of functions about running database queries. And all those queries, if you instead of doing a select star from something or instead of doing a update my table with something, instead of running a query directly, if you do use DB query, DB update, DB insert, DB delete functions, they are much safer because they always check that there is no SQL injection happening at your site. When you are running your site, when you are displaying the content again, running everything through set T functions is always a good idea because that is always done a sanitization check. Same is true about forms. It's very tempting to use a quick form using some template.php build HTML form and use that functionality. It's a very wrong way of doing things. Again, you are exposing to a lot of security risks. Drupal's form API, if you know and use it properly, can build some fantastic forms. And again, they are all checked for security vulnerabilities. Some bad practices should not follow. Rather some good practices, which you should follow is that you must always have version control systems. Never keep just notepads for writing attacks when you are a small, independent freelance developer. It's very tempting not to have any version control repositories and just write up my code, commit it and done. Never do that. Whatever is the size of the project and size of your team, always use version control, get SVN, anything that you prefer. Always do code documentation. Never think that I am the only coder who's going to read my documentation, but you yourself will need that document, those comments, six months down the line. So always document your code and always do testing. So these are like standard software development practices, but implement those in your Drupal module development as well. And important point. Okay. So anyone who loves Candy Crush, only they should hack code. Anyone who doesn't, please don't hack code. Otherwise, Gris will send you a Candy Crush request. Okay. Earlier he used to crush kittens, but now he sends Candy Crush requests. So these were all the things about module development. Primarily it's about all using whatever tools again given by Drupal score API using those properly in your code rather than trying to reinvent or trying to go completely off standards in the code. Now let's talk about which configurations or configuration settings should not be left as they are on the live sites. The one thing which we have observed in many sites, many, many sites is that the permission system, which is given by Drupal is never ever looked by, by any developer. When you add any new module, the module adds a lot of permissions. Now many, many times the modules has lots of default permissions as well. And you keep all the default permissions as they are. Now someday or the other, they are going to cause some security risk to your site. So some module might ask a thing to just delete all nodes and it will just have enabled by default. You never looked at it and it just happened. So before going live for any project, just take out a couple of hours, possibly a couple of days for some large projects, because every module you might have like eight or 10 different roles and like 50 different modules. So this page may not even load. That will be like such a huge, large, gigantic page. Go to that page and literally the recommended thing is that just uncheck all the permissions, save and then literally go line by line to see that for each role, whether I really want to give something, this permission or not. Now any user should not get anything more than he is intended to do on the site. So always check this page, this configuration settings, but a sanity check is always required. Same is true about the input filters or input formats. It's most ignored and the most possibly frustrating setting for all the developers. You build your first couple of Drupal sites. You go, the site goes live by default. It's input filter is limited. It's filtered HTML and your editors, they start adding content and they give you a call at midnight that I added few images and when I try to go to edit, it's not visible in the site is live. It's visible or the other way around. So when I added adding images in my content, I save the node images are not visible. I edit it back. The images are visible. So there is a problem and what could be the problem? Cause there is a default input filter, which is filtered HTML, which doesn't take image tags, which basically means that your content is saved with image tags so they can go back and edit it. But it's not displayed because the input is filtered while displaying. So do you allow every then then what we do is that we go back and we just make full HTML as default format. What that means is that all the spammers on your site, they start putting some links where you never want to go. So that that starts happening. So input filters are important. Their configuration per user per user role is really important. So always give an attention to that. That will be really helpful. Same is to about keeping the default user settings in Drupal six. That was bad in Drupal six. People could just register on your site and become authenticated users Drupal seven. That's slightly improved. People can register on your site, but admin approval is required. But still, if you still keep, if your site is a say corporate site where you never ever want anyone to visit and create their accounts, why keep that setting? Because you are subjecting yourself to some kind of spam. There will be spam boards which are looking for that they check whether this is a Drupal site and they try to go to slash user slash register. If they see an open form, they just put in data over there. Same is to about comments will come to that. So review these settings. Do you really need these user settings? If it's not a user driven portal, don't keep those settings. Just review it once and you'll be peaceful. Same is to someone mentioned in our pre session discussion that unused modules, unused settings, don't clutter your site. Well, doing the development, we have a tendency to there is a requirement. Oh, someone, the client wants the blocks to be collapsed. We just go and search. Ah, there are three modules. There is a block collapse. There is a collapse block and there is a block underscore collapse underscore new. So we go, we try out all the three modules. Then some module is working nice for us. Then we realize, okay, I'll just finally use this module and we still keep all the other two modules. You never get rid of them. And then at the end, when you are making, going to make your site live, you see that there is a big, big folder list of like 120 modules. And now you're so tired at that night that you just don't want to go and check which modules are used and which are not used and enable, disable those. Now what is the problem? The problem is that it may not have an impact on performance immediately because those modules are in the code is not used. They are not enabled. But when you are maintaining the code, when you are managing the code, when you are upgrading your site, when you do all the sanity checks on your code, do you really want to keep all that clutter? You don't want to keep. So just get rid of that. Keep only those modules which are you using. Get rid of all the other modules which are, which you are not using. On live sites, configuration settings, don't ever keep any forms which are open to anonymous users without any capture or any kind of protection mechanism. So huge nightmare that you can get any form, including possibly say user registration form, if that is open or comments are like most vulnerable because you want anonymous users to add comments on your site and you keep that form open. So spam boards, they are just on the lookout for such vulnerabilities and they start pouring in spam on your site. So never ever be subject to spam. Always protect using capture, recapture, mollum, any other module that you like, but always protect all your forms. What all these things tell us is that is what Sigmund Freud said, but at that time there was no Drupal. So he used word love. Otherwise he would have said keep Drupal. So basically for all the every module that you install again, they will provide some configuration options and there will be some defaults provided which that module developer thought are sensible defaults. But your site might not need that functionality or might need it in a completely different way. So adding anything, adding any new module, always check the defaults, always check all the configurations which are provided by that module and whether you need that or not and just go and check and change the way you want it. These were all the not to do's about Drupal's configuration settings. Now last couple of sections remaining is let's talk about how not to host the Drupal site. While hosting the site, never ever have just a single environment. Don't just have just a production environment. How so ever small site might appear. How so ever small client might appear. It may appear very easy to just go take a VPS account somewhere or create a AWS account or take a shared account. On my machine, I have all the code base, just do an FTP, SFTP, whatever and the site is live. It's it's all right when you want to achieve a deadline for going on production on a certain date, but it will come back and hit you on some day where client wants some changes and those changes need to be tested somewhere before they go live. So always have at least a development, a staging and a production environment. Now for development and staging, why three environments? Development environment is where you actively do development, including configuration changes, including adding of new views, including changes to your second type blocks, views, whatever you want. That's that's always moving forward in terms of set code and functionality. Now production environment is where it's it's live with client is adding data, comments are happening, lots of things are happening. So that's always having the latest content. So how would you test both of these together need to have a third environment like staging where you put in whatever functionality you want to make live, pull the data from production, test it over there and then only push the functionality to live. So ideally this is the workflow which you should should be using in Drupal. So never have a single environment while hosting. Make sure that you have you are able to create at least two or three environments. For hosting Drupal it's extremely important that you never forget caching in Drupal. Now why we need to do caching in Drupal or what is caching? Now Drupal is all all a database based system. So which basically means that Drupal's configurations as well as data all is stored in the database. What do I mean by configurations? Things like views definitions, things like content and definitions, things like which blocks should be visible where are all stored in the database which basically means that for generating every page Drupal needs to go to database and fire like 50, 70, 80 queries and on any production site going to database for every page request firing 70, 80, 100 queries to get that data and to build that page is extremely tedious for any system. And that's why if you put a Drupal site on production without any sort of caching on a developer machine that all will work fantastic. But if there are even more than like 200 page views per hour and you are not enabling any type of caching, your site is likely to crash or become so slow that people will just start complaining or you will need to reboot server several times. Now Drupal has a built in caching mechanism. Very simple thing you should go do is that just go to the performance page on Drupal and on that just enable anonymous caching and enable block caching. Also you can enable CSS aggregation and JavaScript aggregation over there. So that's Drupal's built in way of doing caching, which is a database based cache, which is still slightly inefficient. If you want more caching, obviously you should go for something like boost or varnish caching. Both are drastically different solutions. But both do similar things. They do a static caching of your site. So boost creates a kind of static HTML files, which is bypass Drupal's database system completely. Varnish creates a caching system in its own memory, but they are super fast ways of delivering your content to anonymous users. If you have of course, you need to work on APC, which is alternate PHP cache and memcache, which will improve your performance for authenticated users as well. If your site is like very widely used by users from across the world and there are budgets considered using even CDNs for faster delivery. So these are all absolutely essential for Drupal's site. Even there are some building mechanisms. If you are using a lot of views, there is a caching mechanism. You can actually cache every view, every display of a view at that display level for certain types. So always, always use caching in view across Drupal various layers, wherever you can. While hosting the site, another factor to consider, do you really need shared hosting? Can you really get away with shared hosting? If the client says that he doesn't have budget for a VPS, just ask him to reconsider. Shared hosting was good for static HTML sites, for good for possibly, but I wouldn't say that they are good even for mom and pop shops, even for corner stores. It's their website, its client's website. As a developer, it's our duty to recommend them, to tell them the best practices, to tell them the possible dangers of going in the shared hosting area where Drupal may work. Now, all the shared hosting servers in the world, Drupal works, but will it be scalable? Will it be performant? Will it be sealed from all the security threats? We don't know. So these were about hosting the site and we'll go to the last section. That's how not to maintain and manage a Drupal site. So everything goes great. You manage, follow all the best practices, you avoid all the bad practices for architecture, theming, design, development, site building, module development, everything. And now site is in production and you are fine. So what should you do or what you should not do at that stage? First thing, never ignore security updates. That was the pain when someone was mentioning that there is a security update every month. So most likely there is a Drupal update like every, I think, last Wednesday of every month. Some new minor version of Drupal comes up. Whether we update our site or not, that's a question. If you're using like 50 or 60 of contributed modules, whether we update that or not. So actually while doing the estimation of project itself for Drupal, it's very important to do this estimation. If you ignore this, maintenance and management of Drupal is an effort. It may not be a huge effort or minor effort depending on your project size, but it is an effort and that should be recognized and your clients should be made aware of that. And security updates, especially or updates which make our site very vulnerable, they should be updated on our site on all the time. You should have resources actually looking into that and working on that all the time while maintaining the site. Never use FTP or non secure FTP, especially from Windows machines using FTP and storing your FTP passwords within that client. It's extremely vulnerable and dangerous practice. Why it's basically make your site your entire environment vulnerable to JavaScript injection attacks. So there are viruses from your Windows machine or from your local machine. Viruses can literally hack into your FTP client and they can just steal your FTP passwords and do whatever they want to do on your hosting environments and your entire set of sites are likely to crash. Always use something like SSS, SFTP, SCP anything with a secured in front of it so that your sites are not vulnerable environments are not vulnerable. And last thing which goes with something like my first point that I made is that don't modify anything on the live site directly. This you will be able to do only if you have multiple environments. So things like say views, if there is a client request that I want to modify a view and add like couple of fields to my view. So how do you modify that? So people say that okay, there's no other way, but I go to login to production site and then I just as a super admin, I go to a particular view and I just modify that view. Now is that the right way of doing things? Just imagine if you have a view with set 20 displays and you want to modify just one display, you log into your site and then you go and you change that things and instead of say apply to this display by mistake you click apply all displays, which basically means that in a single click you're likely to bring your entire site either completely all the views will be screwed up. So that's why never ever do any modifications. Always test those and you should be able to or you could use those testings only if you have multiple environments, which are similar. That's one. Then how do you transfer all the changes from one site, one environment to another environment? Use something called as features. So never keep configurations as configurations of the life site. Use something called as features from your development environment, make the changes, export them to features, put those features on live site and just refresh those features and your changes will be live. So never log into like production site to make changes to configurations. Always transfer configurations via features. That's the best way or you see tools exportables if you are comfortable with that. But that's how your site should be managed and maintained. And the last point which I make before I stop is don't work alone. What do I mean by that? Now Drupal as we can see in this room, people from like at least 15, 20 different nationalities working in different time zones. Globally Drupal is a community 25, 40,000 active developers and couple of million now possibly passive developers workers in Drupal. So be a part of this community. Now we are getting this great great piece of software for free. We are making our lives, our careers using this software. We are building some of the great solutions for our clients and making them make a lot of money using this software all for free. Now this is free because thousands of people like us build a community and they spend their days and nights and hours for building this software. Be a part of that moment. Of course you can be a passive user. Of course you can see as Driss said today morning someone else Joe will do it. Of course people are there doing it. They will keep on doing it. But how can we contribute? Now contribution to Drupal is not not only module development. You don't have to develop like a grand module to be a contributor. Just going and registering on Drupal.org is contribution. Attending Drupal cons is contribution. Now if you are facing a problem using a Drupal module going to the issue queue of that module and reporting that I have a problem is a contribution because unless you report back how will the module maintainer know that there is a problem with my module? If you report a problem and if someone else comes and gives a solution then going there and saying that solution number five worked for me is a contribution to community. How that is contribution because because of your one line that this worked for me 10 other people somewhere in the world will save at least two hours each because they will try out that solution and then going forward providing patches if you solved the problem yourself going and providing patches is a contribution. So don't need to build a full fledged module or even go there and work in sprints for like 24 hours to be a contributor. You can be a contributor by very small steps very small things one step at a time. Keep on doing that and we'll keep on growing this community and keep on doing this great work forever. The credits for this the content is obviously the original idea was from my colleague Tanayasai who is standing here. He did this at Drupal con Drupal camp Delhi and this is just built on top of that whatever I have done and incredible help from my Acquia India and UK teams images. They are all from troll dot me or Meme generator.net so possibly in the source. So I think we have only four minutes five minutes of questions. So quickly I can take a couple any any questions. Yes absolutely cashing views with arguments and arguments we can actually if you do the views cashing settings you enable the cache of query as well as provided output for views views does build on keeps on building the cache based on different arguments. Yeah it maintains it on. Any other questions.