Drupal 8 Custom Module Example Download
Sam Eich
By default, Drupal assumes that any installed module or theme is hosted on drupal.org. This means that, if you are using a custom module (which is probably not hosted on drupal.org), Drupal will return the error you are seeing because it doesn't find any information about the module you are using, on drupal.org.
If you just want to stop Drupal from looking for a module updates, normally because you are using a different method to update it, or because the module is not hosted on drupal.org (for example, a custom module you have on your computer, on Git, Gitlab, or similar services) you can implement hook_update_projects_alter().
With this example code, the custom_module module is hiding itself, but a module can hide any module. For example, if I had a custom_core module that is a dependency for every custom module I use on my site, I would implement the hook using code similar to this.
If you want Drupal checks for updates on a site that is not drupal.org, then the .info.yml file for the module needs to contain the following line. (See the code of the UpdateFetcher class, which is the class that fetches project information from remote locations.)
If the .info.yml file also contains a project: my_custom_project line, Drupal will check for information about Drupal 8 releases of the module from -history/my_custom_project/8.x, not -history/my_module/8.x (This is useful when a module is a sub-module of another module, and both are packaged in the same file.)
You now can include GitHub-hosted repos pretty easily. Here comes an extremely simplified example composer.json that includes MYMODULE hosted on GitHub. The manually added type drupal-custom-module and the added directory take care of the rest. You may additionally add that module to your .gitignore now.
Note: It's best practice to create custom and contrib directories in your modules directory. And to place your custom modules in modules/custom. If these folders exist, Drush will place scaffolded custom modules in modules/custom and Composer will place contributed modules from Drupal.org in modules/contrib automatically.
From the root of your Drupal installation (not necessarily the project root), create a directory within /modules/custom. The custom subdirectory is optional but best practice to make it easier for you to distinguish between community-contributed and custom modules. Depending on your use case (i.e. multisite), you may also create your module directory in sites/*/modules. The modules directories in core and profiles are reserved for the core software, installation profiles, or distributions.
In the previous 2 examples, the core key is removed, replaced entirely by core_version_requirement. 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.
The YAML info file can also specify dependencies on other modules. If our custom module will require code from other modules, whether core or contributed, we can explicitly list them. When dependencies are specified Drupal will not allow your module to be installed unless the dependencies can be satisfied. This may be achieved by first installing other available modules, or Drupal may tell you that you need to download another contributed project before your new module can be enabled.
Dependencies should be a list of dependencies with the format project:module, where project is the machine name of the project as it appears in its Drupal.org project page URL and module is the machine name of the module, which can be derived from the directory name that houses the module's code. Many times the project and the module name will be identical, but sometimes a project will contain several modules with distinct functionality. Use project name drupal for modules in the core/ directory.
You can also define version restrictions on any listing. This will result in a warning on the status report page that a module is incompatible with the core version. (Note: you should probably use the root-level key, core_version_requirement, to specify core version compatibility with your module instead of drupal:system under dependencies.)
In this case we're telling Drupal that our module cannot be installed unless the core Node module is enabled and the contributed modules Webform and Devel Generate are enabled as well. Also, we're indicating with the core_version_requirement key that the module is compatible with 8.7.7 and higher, or Drupal 9. (drupal:system (>=8.7.7) is still supported).
The other main key you may find in info files is configure. Use this only if your module needs to provide particular configuration settings that are exposed to the site administrators. The configure key in your module's info file specifies the route that will be used to navigate to the module's configuration settings form. A link to this configuration form will automatically be added to the module's listing on the Extend (admin/modules) page in the extended information about your module. For example, the Search API module uses this value to provide a link to its configuration form.
If you look at other info YAML files, especially from contributed modules you might notice additional key/value pairs. In particular, Drupal.org's packaging script adds information about the specific version and a datestamp for when that module was generated. None of this metadata is required in a custom module you develop, but can be useful when troubleshooting during development.
The biggest trait of CMSs like Drupal is their ability to create websites without the need for users to delve into coding. However, the real power is unleashed when you get to make your own custom modules and customize them according to your needs.
The first line is the route example.my_page. Route is a symfony component, which maps an HTTP request to a set of configuration variables. In drupal8 route is defined as a machine name in the form of module_name.route_name, here is example.my_page route_name = my_page
We have to create our ModuleController.php according to the PSR-4 naming standard. Create a folder "modules/custom/example/src/Controller". In this folder, create a file named "ExampleController.php" with the following content:
In Drupal 8, hook_menu() is used to define only menu items, not to define page callback functions as in Drupal 7. If we have hook_menu(), we need to make sure that the route and path in example.module should match exactly with the route and path which written in example.routing.yml. In our case, $items['/mypage/page'] in example.module is should be the same path: '/mypage/page' in example.routing.yml. Similarly the route 'route' => 'example.my_page' in example.module should be the same example.my_page: in example.routing.yml
Finally when you enable the module and go to /mypage/page URL, you'll see "Hello world!" text printed from our module. As you can see, creating custom module in Drupal 8 is little lengthier than Drupal 7. But it's really interesting and gives more versatility for customization. It will definitely take Drupal to higher level in software world. Here is the git repo for the example module in case you want to play around with it.
Create a directory for your module in the modules/custom directory of your Drupal installation. For example, if you want to create a module named "mymodule", create a directory called mymodule in modules/custom.
Create a mymodule.info.yml file in your module directory. This file will contain metadata about your module, such as the name, description, version, and dependencies. Here is an example of what your mymodule.info.yml file might look like:
Create a mymodule.module file in your module directory. This file will contain the PHP code for your module. In this file, you can define hooks that alter Drupal's behavior, define routes, controllers, and other functionality. Here is an example of what your mymodule.module file might look like:
I've finally figured that out. My custom module will place an extra tab as a child of the system.admin menu. Every other tab had an icon and I wanted to place my custom module icon there as well.
Forms can be used in collecting data through any source, for example, site or application. They are based on the structure of nested arrays. Drupal 9 Form API is used to create and process forms in custom modules. They are similar to the Form APIs of Drupal 7 and Drupal 8. There are two types of forms:-
The Custom Blocks that come from the GUI are blocks of content similar to node entities. This guide offers a quick overview of implementation of these types of blocks, but is mostly focusing on the Custom Blocks that can be implemented via development of a custom module.
The example here offers the admins to enter a custom text message that will be rendered as part of the block. In the method we first pull all the default configuration options and add an additional field to store custom text messages.
Blocks are an integral part of the Drupal ecosystem and hence of any Drupal website. Knowing how to create and customize blocks is an important skill for any Drupal developer, and we hope we were able to give you some useful pointers in this guide. All code examples are available on our GitHub profile.
As with Drupal 7, the first job is to name the module. We need to create a machine name which will be used throughout the system. Machine names are used in functions and methods in your module. For more information on naming your module, check out [naming and placing your Drupal 8 module] on drupal.org.
In this blog post we will create a simple module that creates a custom page (we'll also touch on passing a url parameter) and then outputting content to the custom page using a custom twig template file. There are lots more we can do in terms of routes etc, so this is quite a basic tutorial in that regards. For this blog post, I do assume that you have some knowledge of object oriented and procedural programming in PHP.
df19127ead