One of the most useful features of Drupal 8 is the migration framework in core, and there are already plenty of plugins to work with different sources that are available in contributed modules.
When writing your own code, it must always be debugged. As migrations can only be started with Drush, the debugging can be a bit challenging. And it gets even more interesting when you develop your website in a Vagrant box.
In this tutorial, we will go through setting up xDebug and PhpStorm to debug your migrations.
UI to control the the form elements provided by the bootstrap_forms theme
In this tutorial, I'm going to explain how you can use the new Group module to organize your site's users. Group is extremely powerful Drupal 8 module.
At the basic level, Group allows you to add extra permissions to content.
At the more advanced level, this module is potentially a Drupal 8 replacement for Organic Groups.
TGIF! We hope the work week has treated you well.
The social media share module allows the user to share current page to different social media platforms. It is rendered as block, you can place it anywhere of your site. It is flexible to share any page of the site whether it is node, term , panels, view pages so on.
This post is an excerpt from the topics covered by our DrupalCon Dublin training: Drupal 8 Development - Workflows and Tools.
During the recent Nuvole presentations at Drupal Dev Days Milan 2016 and Drupalaton Hungary 2016 we received a number of questions on how to properly setup a Drupal 8 project with Composer. An interesting case where we discovered that existing practices are completely different from each other is: "What is the best way to deploy a Composer-based Drupal 8 project?".
We'll quickly discuss some options and describe what works best for us.What to commit
You should commit:
- The composer.json file: this is obvious when using Composer.
- The composer.lock file: this is important since it will allow you to rebuild the entire codebase at the same status it was at a given point in the past.
The fully built site is commonly left out of the repository. But this also means that you need to find a way for rebuilding and deploying the codebase safely.Don't run Composer on the production server
You would clearly never run composer update on the production server, as you want to be sure that you will be deploying the same code you have been developing upon. For a while, we considered it to be enough to have Composer installed on the server and run composer install to get predictable results from the (committed) composer.lock file.
Then we discovered that this approach has a few shortcomings:
The process is not robust. A transient network error or timeout might result in a failed build, thus introducing uncertainty factors in the deploy scripts. Easy to handle, but still not desirable as part of a delicate step such as deployment.
The process will inevitably take long. If you run composer install in the webroot directly, your codebase will be unstable for a few minutes. This is orders of magnitude longer than a standard update process (i.e., running drush updb and drush cim) and it may affect your site availability. This can be circumvented by building in a separate directory and then symlinking or moving directories.
Even composer install can be unpredictable, especially on servers with restrictions or running different versions of Composer or PHP; in rare circumstances, a build may succeed but yield a different codebase. This can be mitigated by enforcing (e.g., through Docker or virtualization) a dev/staging environment that matches the production environment, but you are still losing control on a relatively lengthy process.
You have no way of properly testing the newly built codebase after building it and before making it live.
Composer simply does not belong in a production server. It is a tool with a different scope, unrelated to the main tasks of a production server.
After ruling out the production server, where should the codebase be built then?
Building it locally (i.e., using a developer's environment) can't work: besides the differences between the development and the production (--no-dev) setup, there is the risk of missing possible small patches applied to the local codebase. And a totally clean build is always necessary anyway.
We ended up using Continuous Integration for this task. Besides the standard CI job, which operates after any push operation to the branches under active development, performs a clean installation and runs automated tests, another CI job builds the full codebase based on the master branch and the composer.lock file. This allows sharing it between developers, a fast deployment to production through a tarball or rsync, and opportunities for actually testing the upgrade (with a process like: automatically import the production database, run database updates, import the new configuration, run a subset of automated tests to ensure that basic site functionality has no regressions) for maximum safety.
Slides from our recent presentations, mostly focused on Configuration Management but covering part of this discussion too, are below.Tags: Drupal PlanetDrupal 8DrupalConTrainingAttachments: Slides: Configuration Management in Drupal 8
Continuing on his thread exploring the rules of games, game dev Stieg Hedlund I compares and contrasts similar issues in other media and shares lessons learned. ...