The following is documentation that I am in the process of writing for the "Upgrading an Extension Module" section of the docs: https://tripaldoc.readthedocs.io/en/latest/upgrade_guide/module_dev.html As I'm not familiar with Read The Docs, I am contributing it here, which also allows for any feedback. Please feel free to make any suggestions to improve it! When it is ready, Lacey will guide me through the process to add it.
Upgrading an Extension Module
If you have developed an extension module on a previous version of Tripal that you want to upgrade to Tripal 4, the first step will be to assess what kind of components your module can be broken down into. If you haven't already, it is recommended to first become familiar with Drupal 10's object-oriented programming principles. In Drupal 10, your module is composed of any combination of entities, fields, plugins, services, controllers and YAML configuration.
What is a plugin?
You can think of a plugin as defining a type of functionality (e.g. Field, Importer) that has or will have multiple implementations for which a single site may want to use. A plugin is a sort of template or description that can be used in multiple different situations, rather than explicitly coding a single field or a single importer that is only used in one situation.
For example, if your module imports data into a Tripal site, you are most likely going to create an implementation of the Tripal Importer class rather than define your own plugin. A field is an example of a plugin created by someone else that you would want to implement. In order for your module to provide a custom Tripal field, then you are going to be implementing either the Tripal Field plugin or Chado Field plugin.
If your module provided an entity in Drupal 7, it will also provide an entity in Drupal 10, but you will have to determine whether it is a Configuration Entity or Content Entity.
What is a service?
You can think of a service as a class providing a specific service to other classes within your module or other extension modules. A class whose purpose is to provide an API is a great example of a service. A service should only be used if you do not expect or support a site using multiple implementations of the same service. If you do, then you should create a plugin instead. That said, services are more lightweight than plugins and should be seriously considered as an option if you are trying decide between developing a new service or a plugin.
Additional examples of a service includes pulling values from configuration settings,
Making decisions
Keep in mind that your module can be comprised of both a service and a plugin, and/or implementations of other's services and plugins. This process can be overwhelming, and luckily many developers in the Tripal community have a lot of experience with developing in Drupal 8+ (including Tripal 4 itself, which is comprised of many many many different components!). We highly recommend joining our weekly Tripal codefests and joining our Slack channel if you haven't already, and someone will be happy to help you with the decision making process.
The following is documentation that I am in the process of writing for the "Upgrading an Extension Module" section of the docs: https://tripaldoc.readthedocs.io/en/latest/upgrade_guide/module_dev.html As I'm not familiar with Read The Docs, I am contributing it here, which also allows for any feedback. Please feel free to make any suggestions to improve it! When it is ready, Lacey will guide me through the process to add it.
Upgrading an Extension Module
If you have developed an extension module on a previous version of Tripal that you want to upgrade to Tripal 4, the first step will be to assess what kind of components your module can be broken down into. If you haven't already, it is recommended to first become familiar with Drupal 10's object-oriented programming principles. In Drupal 10, your module is composed of any combination of entities, fields, plugins, services, controllers and YAML configuration.
What is a plugin?
You can think of a plugin as defining a type of functionality (e.g. Field, Importer) that has or will have multiple implementations for which a single site may want to use. A plugin is a sort of template or description that can be used in multiple different situations, rather than explicitly coding a single field or a single importer that is only used in one situation.
For example, if your module imports data into a Tripal site, you are most likely going to create an implementation of the Tripal Importer class rather than define your own plugin. A field is an example of a plugin created by someone else that you would want to implement. In order for your module to provide a custom Tripal field, then you are going to be implementing either the Tripal Field plugin or Chado Field plugin.
If your module provided an entity in Drupal 7, it will also provide an entity in Drupal 10, but you will have to determine whether it is a Configuration Entity or Content Entity.
What is a service?
You can think of a service as a class providing a specific service to other classes within your module or other extension modules. A class whose purpose is to provide an API is a great example of a service. A service should only be used if you do not expect or support a site using multiple implementations of the same service. If you do, then you should create a plugin instead. That said, services are more lightweight than plugins and should be seriously considered as an option if you are trying decide between developing a new service or a plugin.
Additional examples of a service includes pulling values from configuration settings,
Making decisions
Keep in mind that your module can be comprised of both a service and a plugin, and/or implementations of other's services and plugins. This process can be overwhelming, and luckily many developers in the Tripal community have a lot of experience with developing in Drupal 8+ (including Tripal 4 itself, which is comprised of many many many different components!). We highly recommend joining our weekly Tripal codefests and joining our Slack channel if you haven't already, and someone will be happy to help you with the decision making process.