- #Drupal core version install#
- #Drupal core version Patch#
- #Drupal core version code#
#Drupal core version Patch#
If a particular minor or patch release of Drupal contains a bug or security fix that you want to ensure is in place before your module is installed.Why use a more granular core_version_requirement value? The module is not compatible with versions of Drupal prior to 8.7.7 in the first example and only version of Drupal 9.1 and higher in the second case.
In the previous 2 examples, the core key is removed, replaced entirely by core_version_requirement. Module is compatible with any minor or patch version in Drupal 9, starting with 9.4 and above: name: Hello World Special Module is compatible with 8.7.7 and above, to the latest minor or patch version of Drupal 8 or, any minor or patch version of Drupal 9 or Drupal 10: name: Hello World Specialĭescription: A special silly example moduleĬore_version_requirement: ^8.7.7 || ^9 || ^10
For the value of core_version_requirement, to use a more granular version requirement than ^8 || ^9 || ^10, remove the core key, and specify a semantic version of the Drupal version(s) your module requires with core_version_requirement only. Use the core_version_requirement instead. The core key cannot have a value of 10.x. When using the core_version_requirement key with anything other than core_version_requirement: ^8 || ^9 || ^10, the module should only be tested on Drupal 8.7.7 or later. The core_version_requirement key was introduced in 8.7.7. The core key is only needed for modules that need to run on sites running Drupal versions less than 8.7.7. For a module called hello_world, here are the contents of hello_world/hello_: Drupal module info file name: Hello WorldĬore_version_requirement: ^8 || ^9 || ^10 These are the basics you need in place in order to see your module available on Drupal's installation screen. Used in automated testing, but otherwise ignore by Drupal core. project: The project shortname, if the module is part of a project hosted in. version: The version of Drupal, often the global constant VERSION. The following keys are added by Drupal's packaging system when "preferred-install": "dist" is specified in the project's composer.json. Restricted keys added by Drupal's packaging system Read on for further examples and explanations for these keys. To override this setting (and list all hidden modules), add $settings = TRUE to your site's settings.php. Used most often for modules containing automated tests. hidden: (true) Use if you want to hide your module from the list on Extend. configure: Specify the name of the route to the module's configuration form (a link labeled "Configure" will appear in the module listing on the Extend page if a valid route is provided here). lifecycle: Specify the stability and maintenance status of your module (see below for example values). dependencies: If applicable, provide a list of dependencies required by the module. For example, use Custom to group all your custom modules in a group named "Custom" on the Extend page. package: Lists the module in a group with value specified. description: A brief description of its functionality (appears in the module listing on the Extend administrative page). 
It can be helpful to provide the following optional keys in your module:
core (only required for core 8.7.7 and earlier): The version of core the module works with (replaced by core_version_requirement). core_version_requirement: The semantic version(s) of core compatible with your module. #Drupal core version install#
Point to settings form route with configure keyĮvery info file must contain certain keys in order for Drupal to be able to actually install the accompanying module.Declaring a dependency on 1 or more modules.
#Drupal core version code#
Learn more about Drush's code scaffolding tools in Develop Drupal Modules Faster with Drush Code Generators. Next time you set up a module, try using the command line tool, Drush, which has code scaffolding tools built-in. See Naming and placing your Drupal module () for more information. The modules directories in core and profiles are reserved for the core software, installation profiles, or distributions. multisite), you may also create your module directory in sites/*/modules. The custom subdirectory is optional but best practice to make it easier for you to distinguish between community-contributed and custom modules. Create a directory for your custom moduleįrom the root of your Drupal installation (not necessarily the project root), create a directory within /modules/custom.
0 kommentar(er)
