 I would like to congratulate and thank everybody for making this con happen. Guys, congratulations. Thank you for volunteering and making this con happen. And everybody who has travelled thousands of miles from some other countries, welcome to India. And I am Meethu Morwani, currently working as a developer at Acquia. And I'll be talking about features and CMI in Drupalate. And the name of my session is Features vs CMI, the Barber for Drupalate. So guys, every once in a while, a revolutionary and a phenomenal product comes in the market. And this time it is our very own Drupalate, coupled with super awesome and fantastic features. So guys, before I start with the technical and all the geeky talks, I would like to know how many of you have used Features module in Drupal 7 before? Oh, we have quite a room for now. And how many of you have explored Drupal 8 of it? I have super smart audience. Okay, so can anybody come up with the usage of Features module? Anybody? Can you come up with something about Features module? Yeah. Okay. Anybody else? There will be nodes on Drupal 1 in all the countries. Okay. Anybody else? Yeah. Exporting configuration between different environments. Any kind of configuration. Yeah, awesome. Yes, so I would summarize what everybody has said. So Features module is used for moving the motivation from one server environment to another. So we use Features module for deployment purpose. Now, we all have the same thing. I think we can start. Everybody knows what Features module is all about. I think we can start about the main talk. So yesterday, I was just going around the campus and I came across a few students. And that made my memory of my school and college days. I remember my teachers. I remember my mentors. I remember my friends. I remember the fun times I've had. And the last thing I remember is the video lessons which I learned through some video capsules. So guys, everything we learned via video capsules leaves an imprint on our heart. So I would be glad if you guys remember what we learned in the session. So from there, just start with a video. So guys, this is a very funny video. Nothing technical here. The message here. Anybody got the message? What this video was all about. I'm not expecting you to say that guy loves the girl. No, I'm expecting a meaningful message to guys who got some of this. You should bundle up the things. Yes. Unless you go for a single item when you read it. Yes. So there are certain things which are meant for bundling. And what if we do not bundle them? As you just saw, we end up in situations which we do not want to be in there. So in order to avoid certain situations, let's start bundling up things. We learn about contribution management and features module. And what are the adjustments made in features module in Drupal 8? And what are the differences? Then how Drupal 8 code is awesome, super awesome with feature module. Then Drupal 8 was still in the development phase. There was a lot of fuss about CMI. Is anybody aware of what is CMI? Yes. And what is the end result of contribution management initiative? Yeah. So CMI stands for contribution management initiative. And as an end result of CMI, we have developed a contribution management system that is used for moving the contribution from one environment to another. So there were certain pain points which every Drupal 7 developer has been grappling with and contribution management helped their developers to solve those pain points. It also facilitates the ease movement of contribution from one server environment to another. And as I just said that there are certain pain points which every Drupal 7 developer has been grappling with to see what pain points have been resolved now by contribution management system. Consistence management system has a consistent approach for storing the contribution. Now once again, everybody come up with the ways, the number of ways in which the contribution was stored in Drupal 7. Where were we storing the contribution in Drupal 7? Yes. In database. But what else? What in database? What? There were certain tables. Yes. Was there any other way a path from a variable stable? Setting dot php. Setting dot php again saved the entire contribution variable stable. In the case? You dollar contribution. Yes. Correct. Yes. So there were multiple ways of storing the contribution in Drupal 7. So every module has to come up with their own way of storing the contribution. There were modules who made their own tables. And there were modules who stored contribution in the variable stable. And there were contributions in suit, sito's, exported by a feature. So there were multiple ways of storing the contribution in Drupal 7. So wherever I was, I would just share my experience. Wherever I was made to work on a new project, it was a pain for me to see where the configuration actually resides. Because there was not a single way. I had to check the variable stable. I had to check the other tables module was provided. So there were multiple ways. Now the configuration management, what configuration management has done? We just have one way to store the configuration. And that is YAML files. Now does anybody aware what is YAML file? Yes. Anybody else? Yeah. And what is the full form of YAML? Yet another mark of language. Yes. So YAML is a format of files. And it is human readable. And the configuration is stored in keyware format in YAML files. And it is human readable. You can just read the YAML file and you will see what the configuration is all about, what it stores. So yes, in the case of configuration management, there is only one way to store the configuration. And that is YAML files. The next. So this is the one screenshot of YAML file. I hope it is visible. It says that name large. So this is a YAML file of our image style. As you can see it has a name. It has a dimension. So just having a look at the YAML file you can clearly find out what the configuration is all about. What it has. So now everything is YAML. Tables, C tools, variable tables. Everything is YAML file now. In Drupal 8. So the next problem which was there in Drupal 7 is just imagine. You have gone with the code freeze. And there are certain things, there are certain changes that you have made. But you cannot push anything on the other deployment environments. How do you take the code there? Is there any way to make your changes there on the environment? To take the local changes on the other environments, development environments, staging environment. Is there a way? But you have hit the code freeze. What else? I am not lying. I do not want any code to go on the environment now. Is there any way? You have to do things manually. But is it easier to do things manually on several environments? It is not easier. Right? But we have better staging of, better configuration staging management system in Drupal 8 now. You have hit the code, you have hit the code freeze. There are certain things that you want to move from one environment to another. You can just export the files from one environment and you can just import them on the other environment. Now I can see so many confusing faces here. Guys, don't worry. We will see a demo here. Whatever I am speaking, we will see everything in the demo. How we can export YAML files from one configuration environment to another environment. After talking a lot about configuration management, what are the pros of configuration management, let's discuss how does this work. So has anybody seen the setting for PHP 5 of a Drupal 8 environment? Anybody guys? So did you know it's a variable there called the configuration management? What is there? What does that variable contain? Anybody? It points to the directory which contains the configuration management. Yes. Yes. So my audience knows everything. Okay. So there is a variable called configuration directory and it stores the path where my entire configuration is stored in the form of YAML files. If I have to take the configuration from one environment to another, another environment will scan that directory and import the configuration from that directory. So it has the path to the direct configuration directory. And just to make the things more easy, we develop and believe in making things simpler, easier. So just rename the directory. You can also rename the directory. In my case, I have just renamed it to same directory so that it makes more sense. Initially it is something called an underscore hash but I have just renamed it to same and have created a directory in the path and it picks up everything from there. Okay. So let's see the demo here. What am I doing here? So the environment is a development environment and I'm just changing the site name here. Change off the lights please. Can I see from back here? Yes. Sorry. Change off the lights. You cannot see from back here. Okay. So we can just put the lights on now. I'll just brief you about what is there in the video. So I'm just changing the site name and the slogan of my current one environment, demo environment. And I will be exporting the configuration and I will be importing that configuration on the other environment and you will see the changes being reflected on the next environment. I have updated the site name on the configuration and the synchronization page. I export the file here. As I can see, system.site.vile if I will have all the configuration related to my site. And just copy the code. The one is the demo of local as you can see. I go on the next environment and this is my site name which is there. This is where configuration management is site. The site is under development tab. I just go there. Just because I'm importing a single file, I'll simply call a single item there. I've pasted my configuration there. There is a batch process that starts while importing the configuration. Once we have all the configuration, we see, yeah. So we successfully imported the configuration and let's see the difference in the site name. Oh, so I have my new site name and slogan there. So yes. So guys, what we just saw in the video is that I exported the file from one environment and imported on the second environment. And all the configuration changes which were there on the first environment are there in the second environment. Now, you just saw in the demo that I just, yeah. So how do you do all the multi-site environment? Multi-site environment. So basically what is multi-site environment? You have everything in sites folder. So over there, you can just import the configuration in under several domains. Every site will have a different layout. Every site is a different database, right? So you just go on a different domain name, import the configuration there and it will pick up everything from the scene directly. What is there in the scene directly? So if you are making a change and if you are just popping that scene directly under all the multi-site category and you are importing it, then all multi-sites will have what is there in the scene directly. So the scene directly is the important key aspect here. Everything which is there in the scene directly will be copied to the database. Yes. Sir, if you have all the common data in the site. Yeah. So we can have a common data result. I couldn't see anything enough. Give you a site so I can open it. Yeah. I can't choose any site. Yeah, so this is what is there in the code. And probably Jeff, can we, I think we can do something custom here to make this more expandable. Yeah, so this is, she's on one site. So if there were multiple sites. Yeah. She's still only importing configurations in one of the sites. So you can import it to each individual site. If you have different configurations to import into different multi-site sites. Can I be automatic? If there are like 100 sites, is there something in code or some particular? No. So for now we do not have anything in code. But I think there will be some constitutive modules as this is a very common requirement to have a multi-site configuration. So this is just what is there. What is Drupal 8 provide out of the box. But yes, there will be constitutive modules which will put your requirement as well. Yeah. Something for that. Yeah. Yeah. So when Drupal 8 development was one second. When Drupal 8 development was in progress, there was an issue which everybody was working on. And the issue is that I want my default configuration to be stored in files. Right. But then we decided that we will be saving the configuration in the database. But yes, just making a change in the settings of creation file. You can say that I want to make my default configuration stored in the form of YAML files. So yes, you can do that. Yes. Yes. Yes. Yes. Yes. We will see that. I have a next slide. So yes. These are just the screenshots. What I did from the export tab. As you can see full archive and single icon there. We can export the entire configuration directory and import it on some other environment. We also have an option to export just a single file which we just did. We have a screenshot for importing. Again, same thing goes here. We can import the full configuration directory. Now what is the result of exporting the full configuration directory? When you do the full archive export, what do you get? What is the end result? You get the cloud of gg file which you get as the end result. It has the configuration YAML files. You place it in the same directory and you are good to go. And the good thing is that this directory can also be version controlled. And I hope, I made this assumption that everybody is aware of this since we cannot just take the configuration from one server environment together without just version controlling it. But I am just repeating it again and just telling it that yes, we can version and process directory and I will get to any version control system that you guys use. And the next tab is the synchronized tab, the one, the question that you are. Over here, you will see all the differences. So there are certain things which exist in the database and there are certain things which exist in the code. So you will see a list of everything there and you can just check the items that you want to import. What are the things that are removed? What are the things that have been added? What are the things that have been changed? So you can see everything and you can make the choice and you can import them. So this synchronized tab will let you see what is the difference? What are the new files that you have imported? And what are the new files that have gone as a result of liquidating the latest code? So what is there? What is there in the whole bunch of imported? It is there in the database. You cannot hold that. You have to do the changes again. So you could also use that to go back to the previous one. Yeah, so everything is version controlled. Yeah. So everything is possible with Git but Drupal. Then when we are talking about Drupal 8.4, once the changes are there in the database, you have to make those changes again. So now everybody is aware of the benefits of confirmation management. Now everybody knows how it works. But still you may end up getting yourself disappointed. And the reason for your disappointment can be the UUID. So guys, do you know what UUID is? Anybody? Yeah. Unique Identifier. Yeah, universally unique identifier. Okay, and this is the perform of UUID. But what is the significance of UUID? Every site has a unique identifier. Yeah, so thank you. So whenever you do a site install, there is a fresh UUID which is associated with the site, which identifies that site. Now when I said that you can move the configuration from one server environment to another, what did I mean? I meant that the second environment should be the clone of the first environment. The UUID should be same, right? So yes, and so we can see if the UUID of the destination site is equal to the UUID of the source site. See environment work, otherwise it will fail. So yes, as we just let's step back a bit and remember what you all guys said, what we all came up with the definition of features. We said that features is used for moving configuration from one server environment to another. But was it intended to do that? Was it built for moving the configuration from one server environment to another? No, it wasn't. Yeah, so we'll talk about features as well. But guys, there is one more thing which you should all cheer about. We have a drug support for this as well, for configuration management. Now, do you consider how many of you believe in better user experience? Everybody believes in better user experience, right? Now, do you consider this as a good approach? I export the configuration, I get the tar dot gz5, I unzip the tar dot gz5, I then manually copy and paste it in the single directory. It is too much of a pain, right? And we believe in making things faster, better. We have a drug support as well. Let's see what I just did here. Probably this is a long video, but I'll just make it faster. This video has everything, how you can version control the board, how you can export the board, how you can import the board. This has everything. So I'll just fast forward it since I'm just changing the configuration, I'm just changing the name of the file. As you can see the environment. I've been asking about automating this. So, trash can be used for automation. We can also make custom trash commands. Yeah, you can make custom trash commands, but why would we make it when they're already available, right? Yeah, but right there are a number of sites that have to write a script. You can, yeah. Yes. So, I have added a new field to a content type. The reason why I did this, because you will see new YAML files, which will be added. So I've changed the site name, slogan, added a new field to a content type. The field is there, the field is the even date field. Is it not clearly visible? Let me try. I think this is the full screen. Okay, I can just say what am I doing here. I'm saving the configuration. And I've added a new field in the content type. I can just repeat everything what is happening there in the video. I see that my article content type has a new field. And what I did here, I did trash-config export, which will export entire configuration into the same directory. I will do the git status now. So this is trash-config export. As you can see, there are new files added and there are files modified. The one in the git are the new files added. Now, does anybody know why the new files got added? Yeah, because I added a new field, right? And every field has two YAML files in Drupal A. So the new files got added. I'm adding them under git. So as you can see, the git status. The other remaining files, which are on track are useless. I'll probably just add the two files. The one that I'm highlighting here. Under git, I've added those two files. I can see the new files and I can see the modified files under the git dip. I've committed the code and I'm pushing the code so that I can pull the code on the next environment. So this is my next environment. I've got the configuration management screen. And I can see the differences here. What are the differences? But I don't want to use the UI. I want to use the brush command again for importing things here. Can I repeat the question? Yes. Yeah. In your environment, is there a brush that you've seen? I don't think so. I'm aware of only two commands, just export and brush config import. You mean to say that if I just want to see the differences? What do you mean by sync here? Same thing. When you create a new field, you have a new configuration. You want to list the stages. So you do crash config sync, the audio server. I am not aware of this. I'm sorry. I'm sorry. I have never seen this. There are two commands which are aware of. One is for exporting and one is for importing. You do not want to do this again and again. We'll just make a default configuration to be stored in ML file. Whatever changes you are doing, it will be there in your ML file. Export that one. Yeah. It's the same one. So let's say you haven't made one and then you want to change it as a text. Can you repeat? I have one field. I created one field. Okay. At the beginning, you have to say you both are on one side. One of them will be created as a part field with a different type. With a different type? Yeah. The same field with a different type? I don't think so that you can do that. If there is a field which is associated with a content type and you want to reuse that field, the entire configuration will be the same because you are reusing the field there. Yeah. No. I don't think you can change the type of the field since the data is already there in the field. Yeah. It works so happily. Yes. So in case if we change the label of that particular field, will it be able to move the changes? Yeah. Label is something that you can change. There is one field which is associated with a content type and you want to reuse the field. We do change the labels. Label is something that you can change but what you cannot change is the type because there are certain values. There may be some values exist in the field and I don't want to lose my data. These are working on the same thing but you have to find the code. So will it be able to see from the interface that all the things whatever the changes one thing is doing and the other thing is working on that. So can it be possible to check what all the things have been done by the second particular? If everything is undergird, I think you can just check out on that submit ID. Not from the perspective of each one of these. No. There is no as such functionality in configuration management. So where you can see what the other team is doing. Probably we can just build a custom code for this. Okay. What are the differences between the other teams? What? I am not sure how are you comparing with installation profile with configuration management system because what is the use of installation profile? Installation profile is just a profile. We have standard and minimal profiles which mean that there are certain set of models which will be installed while you do the site install. And configuration management is entirely a different concept. You know configuration management has all the configurations. Whether it's your content type, whether it's your variables, by the way, we no longer have variables under 2.0. We have configuration. So any configuration which exists on your site, you can take it from one environment to another using configuration management system. So I am not only talking about just one type of configuration, all the configuration which is there on your site. And in Drupal 8, configuration no longer belongs to user, configuration belongs to the site. So all the configuration which is there you can take from one environment to another and it can be controlled and managed by configuration management system. So when you do the site install, you see that there are two options. One is standard and one is minimal. So those two are the installation profiles. And what is specified in the installation profile is the number of modules. So this installation profile will have X number of modules. This installation profile will have Y number of modules. And that is what the installation profile is all about. But probably the recommended way of configuration management... I think this is the solution. So there are 100 ways of doing a thing, but there is only one either way of achieving it correctly. And if we do not want a project to be in less, let's go with the ideal solution, right? Yeah, actually I am a newbie to Drupal 8. So what do you ideal for one configuration site to another copying that when we are exporting or importing the configuration? So if we are having two environments and we are having the same UUID for both of them, then are we using the configuration of what environment? No. So if you are having two environments of a size, it is a mandatory thing that the UUIDs will be safe and you cannot lose the configuration. If you are making a change, you are making that change under git, you are taking that change into the second environment, you are importing it there, there is no way of losing the configuration. If that is something which is intentional, for example, I changed my site name. So if you mean that my previous site name will be lost, but it is not losing it, it is something that I want, it is my requirement, right? So that answers your question. Yeah, Samah. Okay. Items to be imported. So in such case, is there any option? So there are two ways, either you can export the file's single item, right? And there was one more way, which is that full archive. You can take the full archive dump of the configuration which is there in the site. So in that way, all the configuration which is there in your site will be wrapped. Guys, let's speed up a bit. I think it's 12.10 and I have to complete this by 12.30. Can we please come up with the questions at the end of the session? Yeah. Okay, so we have last five minutes or ten minutes for this Q&A. So here, I was just talking about the Rust support that we can export and import the configuration with the Rust as well. So guys, yes. Why do you still think that I'm still standing here and talking to you? After having so many questions and answers, I know this is a very stupid question to ask, but why do you think I'm still standing here talking to you since I've covered everything in configuration management system? Now, you guys are all pro of configuration management system. Why do you think that I'm still standing here and talking to you? Yes. Although we have had a lot of discussion about features, but yes, we'll talk more about features. Okay, so we adopted features based deployment workflow in Drupal when we were working with Drupal 7, right, in the Drupal 7 sites. But as I just said that, it was never meant for deploying things. It was never meant for taking configuration from one server environment to another. If we just go back to the history, how many of you know that what was features developed for and what was the requirement? Why it was initially developed? Anybody? Yes. Yeah, it was. But what was the requirement of the client and which client it was? So if we just go back to the history, when we were working on, yes, Gulab? Yes. And someone else, any one of you guys can just go there and you go there and the block will be there and you go there. So it was basically for bundling things, which you also said. But it was mainly developed for open atrium distribution. Then there was a requirement that we have to bundle up things and we have to take things from one project to another. When I say project, I mean totally a different site and not being one environment, I mean a different project. So yes, it was mainly developed for open atrium distribution and in Drupal 6 days. So yes, we still need features in Drupal 8. Since we will be using features for bundling things now, we will not be using features for deployment. So how many of you have faced problems with features module? Oh my God, everybody. And the result of it can be seen on Drupal.org of the long issue Q of features module. Yes, so can anybody come up with a bug which is there in the features module? But it is not actually a bug, it can be used to face a problem. Anybody? A problem. If you add one view on a particular feature, then you cannot add that particular view into another feature. Then it will create a context that you have to resolve the context. Okay, anything better? Yeah, so probably I will just say one problem which I think everybody might have faced and we considered it as a bug so there is a content type with a feature and the content type is featureized. Now the requirement is there are number of views in that content type. Now the requirement is that I do not need a field anymore. I delete that field. The next step is I update the feature. My updated feature code goes on the next environment. I reward the feature so that I have the code which is there in the features. The database is in sync with the code. What is there in the code? Now what do you think? What is the end result of rewarding the feature? The data will be in the database. The field will be in the database. The field will still be in the database. Yes, the field will be there in the database. And how many of you thought that it is a bug when you started working on features modules in the initial days? Yes. Even I myself thought of it as a bug but it is not a bug since feature assumes that there is a data in that field and it will not delete that field. It was mainly not intended for deployments. It was made for bundling. And since we people of community started using for deployment purpose we ended up being in situation where it took long hours in resolving things and unforeseen situations. So I have a requirement to create a photo gallery. What all things do I need in a photo gallery? Yes, I need a content type and that content type needs an image field. I have the content now since after the content type I have the content now to display all the images I need a view but still my site does not look good. What is still missing? Probably I need a slider. To slide show. Still I do not find it interesting enough. I will create a image style so that all the images are of a desired dimension. So we can add many things and this requirement may go on. So it was features intended for bundling things. You bundle content type, view image style everything in a feature and you just make a feature out of it. There is one project you take that what is the end result of a feature? When I say that a creator needs to create a feature what is the end result of it? We have a module, right? And there are various modules on v.o we can just download and use them on any of the projects it is not a dependent thing which will be a project specific thing, right? So we have a module, we have a feature module which we can just enable on some other site and we will have content type with the image field view everything there. So this was what feature was indented to. Now since we all are aware of what feature indented to do it was used for bundling things what are enhancements and duplicate features? Is anybody aware of where feature module resides? Where is the UI of features module in duplicate? Anybody? Okay. So initially there was one more tab under the configuration management screen but now it is updated it just got updated recently previously it was in configuration management and now it is admin configuration development features we have a new menu link under development tab which is the result of features module So let's just talk about the enhancements quickly, what are the enhancement features in modules? So yes in Drupal 7 when I enabled features module, were there any pre-made features? Were there any pre-made features guys? No. But in Drupal 8 the features are pre-made and you can also configure it So whenever you install a module there will be features like article, page So what is happening in the back end is features is detecting on base of configuration what the content types are there number of content types and all its related configuration will be there in a feature So yes we have pre-made features in Drupal 8 now You no longer have to create a new feature which will have article content type or a basic content type you already have those The next thing is bundles How many of you are aware of the categorization which happens in features module? There are features in one feature I have all the views I can configure it There is a left tab which says views which will have all the features related to views There is one more left thing I can create one more group of content type it will have all the features with content type although it is never a recommended approach to keep all the views in a feature but I am just taking this as an example so that things are clear now The concept of bundles is saying as it was in Drupal 7 of categorization Yes we have the concept of namespaces Now how many of you know that what is the concept of namespace Why do we use namespace Anybody? Yes Yes Anybody else? Yes, so I will make it more clear There is a module named ABC There is one more module Now what if I want to create one more module with the same name ABC Will I be able to do that in Drupal 7? No But you can do that in Drupal 8 We have the concept of namespaces So whenever I associate a namespace with a module that module is categorized under that namespace So I can have one more module with the same name but in the different namespace So namespace prevents the collisions of the modules and of the names So I have created a feature and I want to let's say I have created a feature and I have a bundle called album All the features which are related to album this photo-calibre functionality will be under that feature So if the name of the feature was ABC Now after making it under one method it will be bundlename for ABC So yes namespace is prefixed before the features name This is one of the best things of features module Drupal 8 that production and stage sites need not have the features module You just need features module on one environment when you are creating features your production environment your staging environment or any other environment where you want the configuration to go I have a module there just burning the site, no You just need features on your first environment The last and the most important thing is module UI What if I do not want my site builder to access any of my features I do not want to give my site builder any permission to access features I just want my developer to have access over all the features but not the site builder We have a module of features, UI which I can just turn it off if I do not want anybody to access that UI So yes As I told you before we got one more tab under configuration management screen of features but it is no longer there it is now moved to admin configuration development but previously it was under the configuration management system So the reason is that it shows the conflict I have created a new feature and I have included the YAML files which belong to article content type and as a result of it I get conflict Was there any occurrence when we got the constant root of 7 features Yes Yes When I tried including the configuration which is already there in some other features into my new feature So same thing happened here All the articles and basic page related configuration are there in the female feature and I tried including there in my new feature and as a result of which I got this conflict So this is just a snapshot of how my feature module will look like It is the bundle It is all the collection of YAML files All the configurations are now YAML, everything is under YAML files and there will be 2 directories, instant and optional which will have YAML files Again this is something which feature module will do for you It will categorize few of the YAML files under optional and few of the YAML files under install directory Guys this is the last slide and this is just a way to show that how Drupal 8 is super awesome how it is fantabulous and how it manages to solve Drupal 7 core did not do So Drupal 7 core had a lot of the box support but with the help of feature module yes, we were able to accomplish certain things There were only certain things which we were not able to accomplish with feature module in Drupal 7 which was track configuration changes to inside We were not able to track all the configuration with feature module There were certain things which were not For example we can track variables with the help of stronger but there are certain things which feature no longer supports which feature had no support out so yes and Drupal 8 has all the configuration you can track all the configuration which is there in the site the only thing which Drupal 8 4 is not able and cannot handle its packaging configuration and for that we have features module so Drupal 8 core plus features and your good tool you can track all the configuration track selected configuration you can do everything if you want to collaborate on the same project yes we were able to collaborate on the same project with the help of configuration management system what if you want to collaborate on different projects you can do them with the help of features so yes you can do everything with Drupal 8 core and features and the last slide guys things were bundled up next time thank you guys we learned something from this session and if there are any questions you can follow me up on twitter I have a website you can get in touch with me on email and I have my details written here guys I would be glad to solve your problems thank you do you think that Drupal 8 can import and export on different PHP versions yes in a PHP have you tried importing those Drupal configuration on different PHP versions no I haven't tried this because if I have one environment if I have second environment they will be on a single PHP version because there are chances that my site may break on some other PHP version but in case you have two servers they can be on different PHP versions but there are chances of the site being break right there are chances of site being broken but at least the minimum requirement for Drupal 8 is greater than 5.5.9 you have the greater version so it shouldn't be problem but it can be that in that case we have to look mainly but with the possibility of only the two versions are deprecated it's different than Drupal 7 where with Drupal 7 you were exporting PHP and Drupal 8 you're exporting YAML yes thank you guys for answering the question thank you everybody yeah since you just saw the snapshot what a visual module has you just have YAML in mind you enable a module it is just a module you enable the module you will have other modifications thank you