[Magento 2] CLI Helpers

magento2-cli-guide.md

https://www.drupal.org/node/2209627/revisions/view/9770853/10538567

This document is a reference for evaluating the completeness of examples modules. It is marked as belonging to the 8.x-1.x branch, but it applies to all examples.

It's meant to evolve, so please comment and update if necessary.

Examples Module Checklist QA

Functional tests of all paths defined by the module. Functional tests which submit forms and verify that they behave as expected. Functional tests of permission-based restrictions. Unit tests of code which is not presentational (think 'model' in 'model-view-controller'). Pass coding standards tests. (See: STANDARDS.md) Documentation

Provide docblocks and inline comments for as much code as possible/reasonable. Make docblocks usable by api.drupal.org. Clearly explain why code exists and what patterns are being used. Define a group for the example module, using @defgroup. The name of the group should be the module name. The main @defgroup docblock should: Provide an overview of what the module does and how it works. Allow a total Drupal newbie to understand whether they're even looking at the right documentation. Give enough overview that an advanced user could read it and have a basic understanding of the API in question. Provide links to general topics and d.o documentation, using @see and @link. Usability

The Examples project only supports core Drupal APIs with examples, so no contrib modules should ever be dependencies of Examples modules. The user should not have to install anything else. A top-level README file will explain how to use the examples, and provide pointers to sub-module READMEs if they exist. Sub-module READMEs should only describe unusual installation or configuration instructions. We anticipate not needing these. In-code documentation is the main source of knowledge. Users should be able to browse all in-code documentation on api.drupal.org. Provide an in-site documentation page at path examples/[module name], which appears in the default menu. At minimum, this page exists so that users who have enabled the module will have something to see and read, rather than assume the module does nothing or that they made a mistake. As much as possible, use twig templates for large text blocks in controllers. #2660058: [meta] Convert controller content to twig {% trans/endtrans %} templates per module Other paths provided by the module should follow the pattern examples/[module name]/[feature].

magento2-cli-helper.md

I'd like to see a few more people become active comaintainers, some with commit privileges. I'd like to see specific people take responsibility for specific modules.

First, please be aware that it doesn't take commit privileges to help maintain this suite. It just means taking time in the issue queue, committing patches, developing new modules, and supporting people.

For committers, here are some proposed practices:

Examples is a teaching project. The idea is to do the simplest possible thing that can explain a technique in the Drupal API (and make it easy for people to copy and paste to get started solving their own problem.) Keep it simple! Comment well. Don't show off fancy PHP or programming techniques unless they help people understand best practices. Try to use variable names and function names that make sense and disambiguate the usage. Every example module should have three basic means of access: Viewing and studying the code. Experiencing the code (enabling the module and following the menus). Note that every module should have at least one menu entry at examples/module_name that at the very least gives people a clue what to do next. api.drupal.org will be used to present and explain the code, and people use it directly, so make sure your doxygen is good. All work should be done in the issue queue. In other words, don't just commit stuff without showing the activity and explaining it in the issue queue. If you're going to fix something or improve it, do it in the issue queue. Wait until the tests come back green before committing. (If you think someone will help out and comment on the issue, wait for them as well. In many cases that won't happen. However, if several of us are comaintaining, maybe it will happen more often). All of this code ends up on api.drupal.org, so please make sure to use excellent and helpful doxygen comments. All work that involves new features or solves specific problems should have related tests, just like we do in core. Let's take every opportunity to improve the test suite. Use Drupal coding standards, and please run coder on your work. Please read the project page to get a clear idea of the philosophy proposed there

magento2-cli-snippet.sh

bin/magento setup:install \
--use-secure=1 \
--base-url=https://blueridgeknives.localhost/ \
--base-url-secure=https://blueridgeknives.localhost/ \
--backend-frontname=adminlocal \
--db-host=127.0.0.1 \
--db-name=<database> \
--db-user=root \
--db-password=magento \
--admin-firstname=<firstname> \ 
--admin-lastname=<lastname> \ 
--admin-email=<email> \
--admin-user=<user> \
--admin-password=<password> \
--language=en_US \
--currency=USD \
--timezone=America/New_York \
--session-save=db --use-rewrites=1 \
--session-save-redis-host=redis \
--session-save-redis-port=6379 \
--session-save-redis-db=2 \
--cache-backend-redis-server=redis \
--cache-backend-redis-db=0 \
--cache-backend-redis-port=6379 \
--page-cache-redis-server=redis \
--page-cache-redis-db=1 \
--page-cache-redis-port=1 \
--search-engine=elasticsearch7 \
--elasticsearch-host=127.0.0.1 \
--elasticsearch-port=9200 \
--elasticsearch-index-prefix=<index_prefix> \
--elasticsearch-timeout=30 \
--elasticsearch-enable-auth=false