Giới thiệu Drupal Site là Platform khá tốt

Through my experience working on OpenChurch and several large multisite projects over the years, I have come to appreciate the benefits of building Drupal sites using custom install profiles. More recently, I have introduced the idea of standing up all our sites this way, regardless of whether or not the end result will be a multisite or single site install.

>> Giới thiệu Warm Introduction to the Drupal Community

>> Hướng dẫn build a Blog trong Drupal 8: Using Views

Ask yourself, how many Drupal sites have you built starting with the “standard” Drupal site install profile? Now ask yourself, how “standard” are those sites you have built? I propose we take a different approach to Drupal site development.

I laid out my approach in a recent presentation at NYC Camp. In this brief tutorial we will cover the same material and show you step-by-step how to treat your build as if your Drupal website was a robust platform.

STEP 1 - STORE ALL CONFIGURATION IN CODE

Many of us have been using Drupal Features for quite some time. The Features module allows you to store most Drupal configuration in code. Drupal 8’s configuration management makes this even easier. In order to treat your site like a platform, dump all panels, views, content types, variables, vocabularies and anything else that isn’t content to code (@see caveats later).

STEP 2 - DRUSH MAKE (OPTIONAL)

Use Drush make to better maintain your modules and libraries. In the future this will probably be Composer, but for now Drush make is used on Drupal.org and is fairly easy to learn. Run drush make-generate locally to automatically create your initial drush make file which you can then modify. This is going to make it much simpler to keep track of your module versions and it makes patching easier as well.

STEP 3 - CLONE THE STANDARD PROFILE

Writing a custom install profile is actually not that hard. Never written one before? Just clone the standard profile in your Drupal “profiles” directory.

STEP 4 - UPDATE THE PROFILE’S .INFO FILE TO INCLUDE YOUR FEATURES

While you are in there, remove any modules that you don’t think you will need. In the future if you add more Drupal Features you will again modify this file.

STEP 5 - TEST OUT YOUR NEW CUSTOM INSTALL PROFILE!

Did you realize you were already done? Just run /install.php or drush si -y yourprofilename and you get to see your complete Drupal site minus content. Your views, panels, variables, etc. should all be there. There are some caveats to this that we will explain in a minute.

EXTRA CREDIT: CREATE A DEMO CONTENT MODULE

We now have a clean install of our site! That’s great, but we have no content. In order to pass acceptance testing, we need to prove that whatever feature we just built works as expected, which usually requires some kind of content. Now, we could just add the content manually on a test environment but wouldn’t it be great to have some good test content that could be stood up from scratch?
Admittedly, this is a more advanced step, but still worth considering. Note that the UUID Features module will let you export content but also presents chicken and egg problems when content references other content.

What I do instead is just use node_save(), and taxonomy_term_save() in the profile’s .install file which is actually not that hard.

Package what you need in a demo content module and then you can have a representative copy of your site that you can stand up at any time.

BENEFITS

Isn’t it great that we can stand up our entire site structure from scratch? Think about automated testing, think about easier team collaboration. Want to use your platform as a multisite? No problem! For developers, you don’t need to swap a bunch of database dumps to work on the site, just spin it up from scratch using drush and start developing immediately. It’s also more maintainable. Next we will talk about making updates to your platform.

MAKING CHANGES

You will, of course, need to make updates to your site. In the early stages of a project you can just continually rebuild the site by running a clean install. Once you have a staging site with real content you will need to create update hooks as well (as needed). It’s important that your platform’s configuration exists the same way both when updated or installed from scratch. In this way you are treating your platform like it’s a contributed distribution on Drupal.org.

SOME CAVEATS

With Drupal, some configuration does not export easily. You can usually work around this problem, by exporting the configuration yourself. Some items are judgment calls. Are main menu items configuration or content? Technically they are content but I usually create the main menu items I know we’ll have on launch in the .install profile. Are your taxonomy terms content or configuration? Again, technically they are content. But oftentimes landing pages depend on particular taxonomy term values which makes it a gray area. For those terms, I will create them in my install profile. hook_install and hook_update_N can work-around most issues.

FINAL THOUGHTS

You might be wondering, will all of these steps still apply to Drupal 8 builds? The answer is yes. With Drupal 8 you don’t necessarily have to use the Features module to manage exporting configuration to code. It’s entirely up to you to decide how you want to manage that configuration. The important thing is to remember that you still want everything representing your application to be defined in code so that it can be stood up from scratch.

In my opinion, treating your Drupal site like a platform is a superior approach because it requires you to think about all of the various configuration you are using for your website. Developers will ensure that all the site’s appropriate settings and structure are captured in code. This not only makes development easier, it also simplifies the process for moving the site from environment to environment.

Questions? Feedback is welcome. Hit me up @drupalninja on Twitter or ask below in our comment section