Please enable JavaScript.

Coggle requires JavaScript to display documents.

Acquia Drupal Developer Certification (4.0: Back end development (coding)…

- - - - Including js libraries to a set of pages: use hooks such as mytheme_preprocess_page or mytheme_preprocess_node or mytheme_page_attachments
      - Including js libraries in one page: use {{ attach_library('theme/library_name') }}
      - Including js libraries to all pages: First include de library in the mytheme.libraries.yml file, then include it to mytheme.info.yml libraries property
        Remember the global-styling and global-scripts name convention when naming it in mytheme.libraries.yml.
        Then on mytheme.info.yml:
        libraries: - nonowni/global-styling - nonowni/global-scripts
      - Remember that you can set dependencies
        For example, Jquery is no longer loaded in all pages, so if you need Jquery to be a dependency for your library, explicitly tell that as the following example does:
        nonowni: version: 1.x css: theme: css/nonowni.css: {} js: js/nonowni.js: {} dependencies: - core/jquery
      - Remember that you can extend a library or override it with libraries-override and libraries-extend keys (this can be done at mytheme.info.yml file
      - You can also add external libraries by using the { type: external} property
- - - - Taxonomy
        You can choose vocabulary to reference and select any term under this vocabulary to reference.
        If a referenced term is deleted, it will disappear from the referenced field
        Available displays are:
        Label
        ID
        Rendered entity
        Link
      - Entity
        You can reference any content you have. For example, you can related one content type to another through an entity reference field. (you can even reference more than one content at time)
        Available displays (formatters) are:
        Entity ID
        Label
        Rendered Entity
      - User
        Users can also be rendered via entity reference field as it its for the others
      - Other
        You can reference both content and configuration entities, such as.
        Content entities
        Content
        Taxonomy
        Custom block
        Comment
        Custom menu link
        User
        Configuration entity
        Content type
        Comment type
        Block (existent core blocks)
        Views
        Menu
        etc
  - - - Basic info
        name
        desc
      - Basic settings
        select one content entity
        then a type
        then a sort type (new, old, unsorted, title)
        (field tags allow you to filter by tags)
      - Page settings (if checked)
        page title
        page path
        path display settings (unformatted list, table, grid, html list) of display modes
        You can include RSS feed here, setting a path to the .xml file and what kind of row style
      - Block settings (if checked)
        display settings
        items per block
        use a pager?
      - REST export (if checked)
        path
      - Configuration common scenarios
        How can I filter a View using terms?
        Add a contextual filter selecting to filter by the field you want (do you need multiple?)
        What's the difference between contextual filters and relationships?
        Relationships are used to embed related content to the response
        Contextual filters are used to filter by dynamic data
        What's the difference between contextual filters vs normal filters
        Normal filters = only static values
        Contextual filters = dynamic filters
        How can I avoid duplicated results (for duplicated matches?)?
        On contextual filters set remove duplication
        How can I eliminate duplications in general on results?
        Aggregator distinct
        How to validate values on contextual filters?
        Using specify validation criterea
  - - - Translating a menu in depth
        
        a) create menu in default language
        
        b) enable menu on content language configuration (custom menu link). not save
        
        c) select your new menu and check all information you want to translate
        
        d) navigate to your menu and click translate menu, adding a new language translation
        
        e) navigate to each menu item and click translate for each one
        
        f) place menu block
      - Translating a block
        You can enable block content translation by block type basis
      - Translating a node
        a) Enable content translation for that content type
        b) Go to the node edit page and click on Translate.
        c) Fill up the fields and hit save
- - - - Bartik and Seven
        Both based on classy.
        
        Bartik is the default Drupal theme
        
        Seven is the default admin Drupal theme
      - Stark
        Intentionally styless (just to show developers how Drupal markup looks like with no styling going on)
  - - - When to use preprocess functions?
        
        Use cases
        
        Add new variables to twig templates
        
        Change variables from a current template
        
        Changing the list of theme hook suggestions for a template file (yes, suggestions are also a preprocess function)
        
        Always remember that preprocess functions are made to manipulate values that go to a twig template afterward
        
        Preprocess functions are called once for each time a template is used.
        
        For example, given the template themes/icecream/templates/node--article.html.twig one might expect to be able to use icecream_preprocess_node__article(). However, in this case only icecream_preprocess_node() will work. The additional suggestions in the template/hook name are ignored.
- - - - Cache bins
        
        Default: when none is specified.
        
        Bootstrap: Used for when the cache needs to exist during all the bootstrap duration. It's invalidade frequently.
        
        Data: Data varying by path or context
        
        Discovery: Used for discovery system for things like plugins, views, etc.
        
        Render: Rendered HTML strings such as page or block
        
        Creating a custom cache.bin
        
        Remember .services.yml
        
        tags {name: cache.bin}
        
        factory: cache_factory.get
        
        Cache bin storage can be changed on settings.local.php file
      - Cache context
        Cache contexts vary the cache based on contextual information. This could be the day of the week, the current user's last login date, or the value of a setting in the administrative UI. Cache contexts are analogous to the HTTP Vary header.
        A practical example from Drupal core: the teaser of a node is rendered differently for users in different timezones because the "authored on" date field is displayed using a localized time. So the cache contexts for the teaser would be ['timezone'].
        Check out some of the types available here: https://github.com/WidgetsBurritos/d8-studyguide/blob/master/4-back-end-development/4.6-performance.md#cache-contexts
      - Cache tags
        Cache tags vary the cache based on the data that was used to build the element. For example, entities, users, or configuration.
        In short, cache tags are just strings used to make cache invalidation more precise. This way even if you have multiple cache bins around the application you can invalidate several items on-demand bypassing these cache tags.
        Using cache tags you could associate some cached data with a specific node. When that node is edited, and the content of it changes, the related cached data becomes outdated and no longer valid.
        
        Use invalidateTags to invalidate cache by tags
        
        Use getCacheTags instead of trying to memorize all patterns or paths.
        
        Tags look like this: ['node:5', 'user:3', 'file:4', 'config:filter.format.basic_html']
      - Performance modules on core
        
        BigPipe
        
        Make things faster due to D8 new render pipelines and render api
        
        Uses placeholders to know what parts of the page cache or not
        
        The process:
        
        Personalized parts are turned into placeholders
        
        BigPipe flushs the initial page then stream all the replacements for placeholders (this way not blocking page rendering)
        
        Internal page cache
        
        Comes with D8 and enabled by default
        
        Useful por small or medium sized projects
        
        Caches for anonymous
        
        Not recommended when dynamic data is showed to anonymous users (per-session, shopping cart, dynamic, etc)
        
        Dynamic page cache
        
        Cache pages, minus the personalized parts
        
        Respects cache context
        
        Requires no configuration
        
        Uses page metadata to figure out what to cache
        
        Cache pages for any user (authenticated and anonymous)
      - Deletion/Invalidating cache
        
        Invalidation: Marks cache as invalid instead of deleting it.
        Use this method when the cache is somehow still useful to the callers while waiting for a fresh update. If the cache was updated short ago, it can be a sign that invalidation is a better alternative
        Invalidation is useful to protection against stamped. Instead of having multiple requests updating the cache, there will be one responsible for update it, while the other requests use stale data when no fresh update comes.
        
        Deletion: Completely removes items from the cache
        Use this method when cache is no longer useful. For example, if the item that is referenced in the cache was deleted.
      - Debugging cache errors
        You can debug cacheable responses (responses that implement this interface, which may be cached by Page Cache or Dynamic Page Cache) by setting the http.response.debug_cacheability_headers container parameter to true, in your services.yml. Followed by a container rebuild, which is necessary when changing a container parameter.
        That will cause Drupal to send X-Drupal-Cache-Tags and X-Drupal-Cache-Contexts headers.
      - Render cache vs Response cache
        
        Caching thought process
        
        1) If I'm rendering something, that must be cached
        2) What is the representation of the thing I'm trying to cache? These are the cache keys
        3) Does this representation vary per combination of permissions, URL, interface language or something? These are the cache contexts
        4) What causes the thing I'm caching to become outdated? Like things it depend on, so if it changes should my representation? Those are the cache tags
        5) If the thing you are caching has a limit of time for that representation, use max-age to set a limit. Default is permanent, 0 means no cacheability at all
        
        If you are using cache for not render things, you can use the \Drupal::cache() service (like for example to store responses from a Twitter API)
        
        Response caching
        
        Once the complete HTML for a page is rendered, the cacheability metadata used by the Render API bubbles all the way up to the Response object. Response caching is the act of storing the complete response for later use. This way future requests can bypass all of the logic necessary to build the page and simply return a cached version -- assuming it's still valid.
        
        Render caching
        
        Aka fragment caching.
        Caches fragments of the render array from the innermost to outwards
        Uses cacheability metadata (cache keys, cache tags, cache context and cache max-age)
        Caches the tree
      - Bubbling
        is what ensures that if a child element is changed the whole tree is re-rendered
      - Cache keys
        Cache keys are unique identifiers for a specific variation of a thing that is being cached. This provides the cache API with the information it needs to be able to retrieve the specific item from whatever storage is being used for cached data.
  - - - Definitions
        
        Plugin Manager each plugin type is managed by a plugin manager service
        
        Plugin discovery: A plugin manager defines a plugin discovery method for discovering plugins that implement that type. The most used plugin discovery are:
        
        Annotations : namespaces; most Drupal core modules use it
        
        YAML: plugins are listed in YAML files; local tasks and local actions. Useful when all plugins use the same class.
        
        Static
        
        Hooks
        
        Plugin discovery methods are classes that implement the DiscoveryInterface
        
        Plugin annotation class:
        The annotation serves two purposes. It allows our plugin type's annotations to use the keyword Sandwich instead of just Plugin. And it provides a place for us to document the properties that someone might define in an Sandwich annotation.
        
        Plugin factory: A plugin manager also defines a plugin factory that is responsible for instantiating the plugins of that type.
        Some of the provided Plugin Factories are:
        
        DefaultPluginFactory (simplest one)
        
        ContainerFactory actually the most used one (core uses it as well). It extends DefaultFactory. It's also a better alternative since provides access to the container (it uses the create() function)
        
        'MapperInterface' = uses getInstance() to return the plugin with more flexibility. Used on mail manager, for example. Loading a plugin instance based on application's state and configuration instead of via its unique ID. This is useful when you need to infer the plugin to use based on contextual data.
        
        Factories use the createInstance function that receives a plugin_id and some arguments to instantiate the correct plugin class
        
        Plugin Derivatives: allows a single plugin to be presented as multiple plugins. Example: the Menu module allows each menu to be presented as a block using a block plugin derivative.
        It's useful for plugins that need to dynamic generated. Since each plugin is a PHP class with static information, how could we possibly know each Menu that needs to be implemented? For this cases, we use a derivative, which allows us to create a deriver class and put there all logic to dynamically create plugins
        In your plugin class, on the annotations, you set what deriver class you handle it. Then use getDerivativeDefinitions to loop all plugins and setting dynamic info (which is described in the annotation of the plugin class) to each field (like admin_label or id)
        Advantages?
        
        Reducing the amount of hardcoded plugins
        
        allow an unknown number of plugins exist with a base configuration
        
        Plugin Mapping: allows to map a configuration string to a plugin instance, having the plugins instantiated without any additional code
        
        Plugin Collection: allows a lazy way to instantiate multiple plugin instances from a single plugin definition
        
        Plugin Type: plugins of a grouped in a plugin type, generally defined by an interface
        Remember that new plugin manager = new plugin type.
        Some things to consider if a new plugin type is needed or not: As a rule of thumb, anytime you want to provide a list of different choices for accomplishing the same task you should probably be considering plugins.
        
        What are plugins
        
        An object-oriented way to extend Drupal functionality. Some of the Drupal core.
        
        A plugin is a unit of functionality
        
        Some of the Drupal core systems that use plugins are:
        
        block system
        
        entity/field system (field formatters, field types, etc);
        
        Image effect;
        
        Search page types.
      - How to
        
        Creating a plugin of an existent plugin type
        
        Create a class that extends the plugin type base class if it has one (e.g BlockPluginBase)
        
        Have the right annotation documentation header
        
        Be in the right place (for example, if creating a new block plugin, your plugin class must be at mymodule/src/Plugin/Block)
        
        Tip: find an existent working plugin and copy to your folder as a starting point
        
        Define a new plugin type you need to:
        
        Create an interface for the plugin (like for example MyModulePluginInterface`)
        
        Your interface must implement one of these interfaces: PluginInspectionInterface, ConfigurableInterface, DependentPluginInterface, ContextAwarePluginInterface, PluginFormInterface or ExecutableInterface
        
        Define an abstract base class that will implement your interface and have some code there (your base class must extend PluginBase, which already implement some of these interfaces above)
        
        Choose a method for plugin discovery
        
        Create a plugin manager/factory class and service
        
        Used to discover and instantiate plugins. Steps:
        a) Choose a namespace (e.g Plugin/Block);
        b) Define an annotation class (should extend \Annotation\Plugin);
        c) Define an alter hook (and document it on .api.php).
        d) Define a plugin manager class (should implement PluginManagerInterface or extend DefaultPluginManager class)
        
        Define a service for your plugin manager (container and .services.yml)
        
        Plugin collection
        
        If applicable you must create a class that extends LazyPluginCollection. If your plugin collection has configuration (which usually has), you also must to implement EntityWithPluginCollectionInterface
        
        Defining a new plugin type (simple)
        
        Defining a plugin manager and deciding on a discovery mechanism -- generally annotated class discovery
        
        Create a new annotation class to document your plugin type's annotation
        
        Create an interface that all instances of your new plugin type should implement
        
        Define a base class that others can extend when creating new plugins
        
        Create one or more instances of plugins of your new plugin type
        
        Perform tasks with plugins
        
        Instantiate the plugin manager service (from the container, using the machine name);
        
        Use methods getDefinition or getDefinitions to have a single or a list of definition of all plugins
        
        Use method createInstance to instantiate a specific plugin
        
        Call methods on the plugin instance to do things
    - - Services and the Dependency Injection Container
        
        What are services?
        
        Services are kind of useful classes that can be used anywhere. Examples of services are Database, Emaling, etc.
        How to inject the service into the container?
        
        If you are developing a custom module that has a custom service, you need to create a service and place it in the correct namespace (usually Drupal\mymodule\Service), then create a mymodule.services.yml file that usually looks like this:
        services: mymodule.service_name: class: Drupal\mymodule\Service\MyServiceClass arguments: ['@database'] # an example of how to inject a service into another service
        By doing this you can access your service anywhere from the container.
        Tip: You can consult your module services on a mymodule.services.yml file or consult even core services by checking core.services.yml file.
        
        What is a container?
        
        Container is like a hub for services. All services that need to be used (anywhere in the code by other classes) must be declared in the services container and accessed by its a machine_name.
        How to retrieve a service from a Controller
        
        Remember:
        
        Your controller must extend ControllerBase
        
        You must override static create() function receiving the container as parameter
        
        You must return a new static passing the service you want to retrieve from the container like this `$container->get('service_name')
        
        You must get it from the constructor method
        
        How to retrieve a service from another service
        
        Remember:
        
        You must declare your service in the mymodule.services.yml file
        
        Then on the arguments property, you set the machine name of the service you want to inject in the constructor like this arguments: ['@database']
        
        Create a property in your class that must receive the injected service
        
        How to access a service from a .module file
        
        You need to access it statically, like this: `\Drupal::service('service_name')
        
        What is dependency injection?
        
        Dependency injection is a pattern introduced by Symfony (and adopted by Drupal) to inject a service in a given class. Usually this process.
        
        Best practices
        
        Prefer using dependency injection than \Drupal class because it facilitates unit testing
        
        Makes easier self-documentation on classes
        
        Define an interface for your service then create a class that implements it
        
        Service tags
        
        Service tags are used for grouping services and indicates a specific behavior of it. When a service indicates the usage of a service tag it must implement an specific interface related to that tag. Some common examples:
        event_subscriber (used when you ned to create event subscribers), cache.bin, access_check, etc.
        
        Discovering existent services
        
        drupal console with drupal debug:container
        
        api.drupal.org
        
        read the code .services.yml files
    - - Implementing a custom logger
        
        Remember to:
        
        Use on services.yml tags: { name: logger }
        
        Create the class that must implement LoggerInterface
    - - Render arrays
        
        Render array is an array that contains information about data to be displayed, containing hints of how it should be converted to HTML instead of hardcoding HTML markup
        
        Data and hints of how content should be rendered
        
        It's a better alternative than hardcoding HTML markup
        
        Examples: if you need to render a list or table from your container, you are going to use the Render array
        
        Elements vs Properties
        
        Properties
        Has the #
        Examples of the main properties:
        #theme, #type , and#markup`. Each one of these has its own set of properties.
        Elements
        Non # elements
        May have its own properties
        
        #theme
        
        Used to set a theme (template) that will handle the output in a more flexible way. You can also set variables to it. An example of #theme is node (remember to use theme hooks)
        Common values:
        
        table
        
        item_list
        
        time
        
        link
        
        links
        
        #markup
        
        Used to pass text or minimal markup. If more markup is needed is preferable to use #type and #theme
        
        #type
        
        Used to render elements to specify what type is. It has its own properties. An example is textfield. Remember to use the machine name of the form/render element here
        
        #plain_text
        
        Used to pass text that needs to be escaped. If #plain_text and #markup are set, #plain_text will be prioritized
        
        Common properties
        
        https://drupalize.me/tutorial/render-arrays?p=2766
        
        hook_theme
        
        Modules define theme hooks by implementing hook_theme(); this determines the name of the Twig template file that will be used as well as any variables that will be passed to the template file. If the hook_theme() implementation defines a new variable 'first_name', then in a render array you would provide this data using the property #first_name.
        Twig docblocks
        
        Are useful to identify what variables are injected in a template. If theme is item_list look for the item-list.html.twig template
        
        Who uses it?
        
        Modules: Content must always be returned from a custom module to a user using the render array
        
        Themes: The generated HTML output can be edited by themers on a .theme file
        
        Renderers
        Work for rendering from the innermost element to outwards
        
        Main content renderes:
        
        HTML
        
        Modal
        
        Dialog
        
        Ajax
        
        Why arrays?
        
        More efficient than strings, since PHP has poweful functions to handle arrays than have to manipulate strings
        
        Makes easier to access specific content
        
        More flexibile, allowing to output the same data in different forms than we could if we had already html markup formatted with strings
      - Render elements
        
        It's part of the Render array. Each element should be a renderable array
        Most used in forms (each field is a different render element)
        But also can contain complex logic
        Defined by core and contributed modules
        As module developer you will set data to it; As a theme developer, you will most edit the output, set classes to it, etc
      - Render pipelines
        
        Is the process of getting the HTTP request converting it into a valid response.
      - Render caching
        
        Some render logic can be complex and expensive, for that reason the render array use cache. You can also read and set cache configuration to the ['#cache'] key
    - - Are hook functions that can be placed in the mymodule.install that executes update changes. Usually those functions are prefixed with numbers that is used for Drupal version identification.
        These functions run once. Examples of changes are:
        
        Updating any database schema related thing
    - - Menu links
        How can I add a new menu link to my new custom module??? With Menu links :D
        
        The most common type of link. You can use it to create a new menu link
        
        File must be named as mymodule.links.menu.yml
        
        You can set parent route
        
        Syntax looks like:
        mymodule.link_name: title: Menu link title # required route_name: mymodule.route_name # for external resources use the url key parent: system.admin_config_system
        Other common keys are: description, expanded and weight
        
        Use hook_menu_links_discovered_alter to alter existent menu links dynamically throught the &$links parameter
      - Contextual links
        What if I want to add a new link to that tooltip that appears when I click on the edit pencil? Contextual Links :)
        
        Contextual links are the links that appear when an editor click on the pencil button of a node. Some common actions are Quick edit, Edit, and Delete.
        
        File must be named as mymodule.links.contextual.yml.
        
        For this kind of link appear you also need to set the ['#contextual_links'] to the render array
        
        Syntax looks like:
        mymodule.route_name: title: Link name route_name: mymodule.route_name group: node weight: 10
        You can also use two hooks to alter a contextual link data:
        
        hook_menu_contextual_links_alter() to alter more structural data of each link, such as changing the title
        
        hook_menu_contextual_link_view_alter() to alter the render array of the contextual item. For example: to add a new class
      - Action links
        When you ask: How can I add a new action button on admin? Here is your guy.
        
        Are the links that appear on the admin and imply in a button such as the Add Article one.
        
        Files must be named as mymodule.links.action.yml
        
        Syntax looks like:
        node.route_name: route_name: node.route_name title: Link title appears_on: - system.admin_content
        Use hook_menu_local_actions_alter to change local actions
      - Local tasks (tabs)
        What if I want to add a new tab to when an editor is seeing the content? Local Tasks :)
        
        Local tasks are the tabs that appear for editors when they are viewing a node, for example. Some common examples are the Edit, Revisions, and Delete tabs.
        
        File must be named as mymodule.links.task.yml
        
        Syntax looks like:
        examples.menu_example.tabs: title: Sou uma tab route_name: examples.menu_example.tabs base_route: examples.menu_example.tabs
        Other keys such as url, parent_id and weight are acceptable as well
        Hook hook_menu_local_tasks_alter is acceptable to change local task data
    - - What are events
        
        Is a way of allowing the various Drupal subsystems to communicate with one another in a object oriented way
        Allow communication in a decoupled way
        Mediator design pattern
        Uses Symfony event dispatcher component
      - Examples of Events that you can subscribe to
        When a request starts
        When a configuration is save
        Who can dispatch events?
        
        Drupal core
        
        Contributed modules
        
        Your custom modules
      - Basically two functionalities
        
        Subscribe to events in order to execute custom logic when determined thing happen in the system
        
        Dispatch an event whenever you want to other components to implement custom code when something happens in your code while remaining independent
      - Discovering existent Events
        
        Search for @Event in the codebase. Its a convention to document classes that are events with this keyword
        
        Using Drupal console drupal debug:event
        
        Using devel/web profiler
      - Implement a EventSubscriber
        
        Create a EventSubscriber/MyEventSubscriber.php class
        
        Implement EventSubscriberInterface
        
        Override getSubscribedEvents and return an array of arrays containing the events you want to subscribe to and the corresponding method to implement it (remember to use constants instead of hard-coded string)
        
        Create and implement your method
        
        Tip: to redirect URLs from an Event you must use GetResponseEvent $event object and use setResponse(new RedirectResponse ($absolute_url)
      - Implement a new Event (src/Event)
        
        Create a new final class (like NewDeveloperEvents) to document your event name in constants like this const EVENT_NAME = 'modulename.event_name' (document the constant withEvent`)
        
        Create the Event class itself (like NewDeveloperEvent), which must extend Event class, and have properties, construct and getters (pretty much a simple class, with no much implementation needed)
        
        Dispatch that event
        
        Inject EventDispatcherInterface
        
        To dispatch an event you must to first instantiate the event like this $event = new CustomEvent($prop, $prop2)
        
        Then dispatch the event like this $this->eventDispatcher->dispatch(NewDeveloperEvent::EVENT_NAME, $event); (remember to use constants instead of hardcoded strings)
    - - Translating interfaces (dynamic strings + static strings)
        
        Good practices when translating strings for interface
        Example of how to use placeholders: $this->t('Hello, @name. How are you doing?', ['@name' => $name']);
        
        Never concatenate dynamic variables with static strings (use placeholders);
        
        Use cases:
        
        :value' = use when working with thehref` attribute
        
        @value = for most values (special caracteres will be converted into html entities)
        
        %value = for paths (html will wrap it with <em> tag)
      - Translation tips
        
        StringTranslationTrait makes a $this->t() available on controllers, forms and everywhere that uses this trait
        
        This function accepts:
        a string to be translated; placeholders; context options
    - - Creating Entities
        
        To create a custom entity you must place it at /src/Entity
        
        Extend ContentEntityBase or ConfigEntityBase
        
        Implement an interface with your base class that will dictate the behavior of your class
        
        Define annotations
        
        If module name != entity type, prefix the entity type name with the module name
        
        Type hint with interfaces when possible
        
        Entities fields are usually short and prefixed with is, get, or set
        
        Methods that can have their values changed should not use setters
      - Working with Entity API
        
        Remember to retrieve it from injected service $this->entityTypeManager->getStorage('node')
        From there you can use load, create, delete, save, etc
        
        https://github.com/WidgetsBurritos/d8-studyguide/blob/master/4-back-end-development/4.4-essential-apis-entity.md
  - - - Semver cheatseet:
        ^1.2.3 is >=1.2.3 <2.0.0
        ~1.2.3 is >=1.2.3 <1.3.0
  - - - Simple configuration
        
        Think of it as module configuration settings.
        Suitable for storing settings as boolean values, integers, or text strings in one or more key/value pairs. Simple configuration can only be dependent on the module providing them.
        
        Can be stored in mymodule/config.install/modulename.settings.yml.
        
        if multiple, can also be organized as modulename.config.prefix.yml
        
        Not required to have .schema.ymll file (though is recommended)
        
        Uses configuration system and data is stored in database
      - Configuration entity
        
        Configuration entities are Entities such as Content entities
        
        Discovered by annotation like plugins
        
        Needs to define schema.yml (mymodule/config/install)file containing key/value pairs
        
        Needs to define default values
        
        Uses configuration system and data is stored in database
        
        Configuration entities don't have fields
        
        Extends ConfigEntityBase php class
        
        When to create new config entities?
        For example, if you need to empower a user to create and configure one or more times, in order to be used in some other configuration form. Are more administrative related, since it's suitable for configuring stuff.
        Examples of configuration entities include date formats, vocabularies, image styles, roles, menus, views, Pathauto URL patterns, and text formats.