Drupal

• uses lando or docker to create the stack (mamp or lamp)

how drupal does it

People often think of a website as a collection of static pages, perhaps with some functions like a blog or a news engine thrown in to round it out. When they go to manage their site, they are thinking in terms of a tree-like hierarchy of pages that they will edit.

Drupal, however, treats most content types as variations on the same concept: a node

Static pages, blog posts and news items (some possible node types) are all stored in the same way and the site's navigation structure is designed separately by editing menus, views (lists of content) and blocks (side content which often has links to different site sections).

Node: static pages, blog post, news items - a set of related bits of information. site nav - seperate views: lists of content blocks: side content which often links to different site sections

think xhtml

nodes = htm - the meaningful structure of the information menu system/taxonomy/views - creates the information architecture the theme system controls how it looks to site visitors

Since these layers are kept separate, you can provide a completely different navigation and presentation of your content to different users based on their specific needs and roles

Pages can be grouped differently, prioritized in a different order and various functions and content can be shown or hidden as needed.

comments can be enabled on any content type (or node) you choose - be it blog posts, news items, book pages (which provide basic wiki features), or any other type you may create. Drupal's modular system is limited only to the imagination of the site builder.

1. nodes - data pool
2. modules - functional plugins - part of drupal core (ship with drupal) or contributed modules allow you to customise data items on node types or add new fields to nodes
3. blocks an dmenus. blocks are an output from a module can be placed in regions in template. Blocks can be configured to output in various ways, as well as only showing on certain defined pages, or only for certain defined users. Menus are navigators in Drupal, which define the content coming in each defined menu path (relative URL). Menus are a core element of Drupal which provide links to all the pages created in Drupal.
4. Next are user permissions. This is where settings are configured to determine what different kinds of users are allowed to do and see. Permissions are defined for various roles and in turn, users are assigned to these roles in order to grant them the defined permissions.
5. On the top layer is the site theme (the "skin"). This is made up predominantly of XHTML and CSS, with some Twig variables intermixed, so Drupal-generated content can go in the appropriate spots. Also included with each theme is a set of functions that can be used to override standard functions in the modules in order to provide complete control over how the modules generate their markup at output time. Templates can also be assigned on-the-fly based on user permissions.

This directional flow from bottom to top controls how Drupal works. Is some new functionality you want not showing up? Perhaps you uploaded the module into the system but have not activated it yet and this is making everything downstream non-functional (as in "A" in the diagram above).

Maybe the module is installed and activated, but you still don’t see what you want on your site. Did you forget to place the block, as in "B"? Or are your user permission settings conflicting with what you want and your users are not set to see the output as in "C"?

Additionally, as mentioned earlier, getting the kind of granular control you want over the details of the XHTML module outputs requires understanding this flow. Are you using a module that does exactly what you want, only you wish the markup was just a little bit different? Maybe you’d like it to use different tags, or you’d like to assign a CSS class to something? You accomplish this by copying the output function from the module and pushing it up to the functions document in your theme. Modify the code there and when the system goes to output, it will see your customized function and use that instead.

Base-Level Directories

The following detail the directories provided with every Drupal 8 installation. Thanks to StackExchange for the original discussion.

• /core - All files required by Drupal's out-of-the-box usage (core), except for files that have an explicit reason to be included in the base (/) directory.
• /libraries - All third party external libraries leveraged by Drupal, such as a WYSIWYG editor. This folder is not included by core, but used with many contributed modules.
• /modules - The directory into which all custom (created by you) and contributed (created by community) modules go.
  • Splitting this up into the sub-directories contrib and custom can make it easier to keep track of the modules. You can create subfolders for organization to match your development, storage, usage standards.
• /profile - All contributed and custom installation profiles.
• sites/[domain OR default]/{modules,themes} - Site specific modules and themes can be moved into these directories to avoid them showing up on every site. Identical to Drupal 7.
• sites/[domain OR default]/files - The storage of site-specific files. This includes files uploaded by users (such as images) and site configuration (active and staged). 
• /themes - All contributed and custom themes and subthemes. Please note that subthemes do require the base theme to be installed here as well.
  • Splitting this up into the sub-directories contrib and custom can make it easier to keep track of the themes. You can create subfolders for organization to match your development, storage, usage standards.
• /vendor - Backend external libraries that Drupal core depends on (examples being Symfony, Twig).

Core Folder Directories

In addition, the folder structure in the /core directory has changed as well.

• /core/assets - Various external libraries used by core (includes jQuery, underscore, modernizer, etc.).
• /core/includes - Base-level functionality that Drupal uses through other /core folders.
• /core/lib - Drupal core classes.
• /core/misc - Frontend code that Drupal core depends on.
• /core/modules - Drupal's core modules.
• /core/profiles - Drupal's core installation profiles. These are /Minimal/, /Standard/, /Testing/ and /Testing/ multilingual installation profiles.
• /core/scripts - Various command line interface (CLI) scripts, mostly used by developers.
• /core/tests - Drupal core tests.
• /core/themes - Drupal core themes.

Composer Build Directories 

When using composer to download and manage your Drupal project, Drupal core and base level directories will be adjacent to a vendor directory.

• /vendor - Various external composer php packages
• /web - parent directory for the above base-level and core directories

lando drush cex - export

lando drush cim - import

lando drush @docker uli - one time admin login export PATH=$PATH:/usr/local/bin COMPOSER_PROCESS_TIMEOUT=600 composer install

Created on: 13th October, 2022

Last updated: 13th October, 2022

Tagged With:

• drupal