opdavies/oliverdavies.uk
1
0
Fork 0
Code Issues Pull requests Actions Packages Projects Releases Wiki Activity

Update 2017-05-20-turning-your-custom-drupal-module-into-a-feature.md

Browse source
This commit is contained in:
Oliver Davies 2017-05-21 12:26:45 +01:00 committed by GitHub
parent b935c60261
commit a89c270c84
1 changed files with 4 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
source/_posts/2017-05-20-turning-your-custom-drupal-module-into-a-feature.md
View file

@ -8,17 +8,17 @@ tags:
slug: turning-drupal-module-into-feature
---
{% block excerpt %}
Yesterday I was fixing a bug in an inherited Drupal 7 custom module, and I decided that I was going to add some tests to ensure that the bug was fixed and doesn’t get accidentially re-introduced in the future. The test though required me to have a particular content type and fields which are specific to this site, so aren't present within the standard installation profile used to run tests.
Yesterday I was fixing a bug in an inherited Drupal 7 custom module, and I decided that I was going to add some tests to ensure that the bug was fixed and doesn’t get accidentially re-introduced in the future. The test though required me to have a particular content type and fields which are specific to this site, so weren’t present within the standard installation profile used to run tests.
I decided to convert the custom module into a [Feature][0] so that the content type and it’s fields could be added to it, and present on the testing site once the module is installed.
I decided to convert the custom module into a [Feature][0] so that the content type and it’s fields could be added to it, and therefore present on the testing site once the module is installed.
To do this, I needed to expose the module to the Features API.
{% endblock %}
{% block content %}
Yesterday I was fixing a bug in an inherited Drupal 7 custom module, and I decided that I was going to add some tests to ensure that the bug was fixed and doesn’t get accidentially re-introduced in the future. The test though required me to have a particular content type and fields which are specific to this site, so aren't present within the standard installation profile used to run tests.
Yesterday I was fixing a bug in an inherited Drupal 7 custom module, and I decided that I was going to add some tests to ensure that the bug was fixed and doesn’t get accidentially re-introduced in the future. The test though required me to have a particular content type and fields which are specific to this site, so weren’t present within the standard installation profile used to run tests.
I decided to convert the custom module into a [Feature][0] so that the content type and it’s fields could be added to it, and present on the testing site once the module is installed.
I decided to convert the custom module into a [Feature][0] so that the content type and it’s fields could be added to it, and therefore present on the testing site once the module is installed.
To do this, I needed to expose the module to the Features API.