5

As a module developer, I'd like to convert some of my Drupal 7 info hooks to YAML discoveries in Drupal 8, but it's not clear to me how to document the schema of a YAML file for consumers. For a hook, of course, I would define hook_whatever() in mymodule.api.php. What do I do for *.whatever.yml? What is core doing?

2
  • Do you want to implement new hook exposed by other module or define new hook in your custom module ? – Anil Sagar Apr 17 '14 at 5:34
  • My custom module already invokes a hook, and I want to replace it with a YAML file. Specifically, I'm replacing hook_shunt_info() with *.shunts.yml. I already have the feature working. My only question is: how do I document it so that module developers who used to implement my hook know how to create a YAML file instead? – TravisCarden Apr 17 '14 at 13:48
1

There is no "documenting" of hooks in D8 except the mymodule.api.php as you've already mentioned(+ impleneting hook_hook_info).

The YAML files are only for:

  • services
  • routes
  • menu local tasks
  • menu local actions
  • libraries
  • module info
  • simple configuration
  • simple configuration schema

Now you've mentioned "info" hooks. In Drupal 8 these are Annotations and their implementations are Plugins. If this is assumption correct then see the documentation in here https://drupal.org/developing/api/8/plugins for plugins - what they are, how they work and how to use them.

1

The closest thing I could find to documentation of what you can and cannot put in the YAML files, are the *.schema.yml files in core. For example, when you create a new content type, the available keys for your node.type.my_content_type.yml file is specified in /core/modules/node/config/schema:

node.type.*:
  type: config_entity
  label: 'Content type'
  mapping:
    name:
      type: label
      label: 'Name'
    type:
      type: string
      label: 'Machine-readable name'
    description:
      type: text
      label: 'Description'
    help:
      type: text
      label: 'Explanation or submission guidelines'
    new_revision:
      type: boolean
      label: 'Whether a new revision should be created by default'
    preview_mode:
      type: integer
      label: 'Preview before submitting'
    display_submitted:
      type: boolean
      label: 'Display setting for author and date Submitted by post information'

This means, you may specify name, type, description, help, new_revision, preview_mode and display_submitted. My guess is that other keys will be ignored.

This answer needs community input, since there is still a lot of uncertainty.

2
  • 1
    In my a config entity i created, other keys are not ignored, and work just fine. So the question i found this page while looking to answer is: do we need a *.schema.yml file at all? To whom is it useful, and is it worth the risk of it being outdated compared to the actual configuration schema in use? – mlncn Jan 21 '18 at 15:27
  • One of the main use cases for config entity *.schema.yml files is for config translation – daniels Jul 11 '19 at 8:25
0
  • Create a folder named mymodule inside sites/all/modules or modules
  • Create mymodule.info.yml and mymodule.module files insides your module "mymodule" folder

Code for mymodule.info.yml goes below

name: My Module
description: 'My Module description.'
package: Custom
type: module
version: 1.0
core: 8.x

If you want to invoke a hook you need to use something like below on some event function..

  \Drupal::moduleHandler()->invokeAll('whateven', array($args));

For Example.. User.module does this for user logout event

/**
 * Logs the current user out.
 */
function user_logout() {
  $user = \Drupal::currentUser();

  watchdog('user', 'Session closed for %name.', array('%name' => $user->getUsername()));

  \Drupal::moduleHandler()->invokeAll('user_logout', array($user));

  // Destroy the current session, and reset $user to the anonymous user.
  session_destroy();
}

Regarding api.php files.. They are just used for documentation purposes to help developers..

Regarding .info.yml files they are required to:

  • Notify Drupal about the existence of a module, theme or install profile.
  • Provide information for the Drupal Web UI administration pages.
  • Provide criteria to control module activation and deactivation and Drupal version compatibility.
  • General administrative purposes in other contexts.

Implementing a hook is still same in Drupal 8 .. Defining a function with module name followed by hook name.

1
  • Although this answer provides useful info on creating a new D8 module, it does not answer the question at all. The question is: How to document the YAML files. And: How does core document the YAML files that may be created by custom module developers? – rudolfbyker Jan 25 '17 at 6:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.