-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
updating organization and updating drupal standards #21
Conversation
…al standards to its own section, and breaking out composer and good general application development + 12factor apps
* [PHP Storm] | ||
* [VSCode] | ||
|
||
@todo this entire section below needs to be reviewed and updated |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This needs a heavy review before it's merged in
* Variables should have the module prefix. | ||
* Custom code, when possible, should be developed as a standalone library that a module can include and integrate with Drupal. This should mean using class namespaces and best OOP practices, and at that point we can use an alternative more flexible autoloading approach, like the one provided by composer. | ||
* We always try to use Drupal functions where they exist. This helps with upgrades (among other things). | ||
* Use `drupal_get_path();` to create a path to a file in your module directory. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This isn't officially deprecated (yet), but it's no longer best practice. The new way to do this is:
$module_handler = \Drupal::service('module_handler'); $module_path = $module_handler->getModule('my_module')->getPath();
* Custom code, when possible, should be developed as a standalone library that a module can include and integrate with Drupal. This should mean using class namespaces and best OOP practices, and at that point we can use an alternative more flexible autoloading approach, like the one provided by composer. | ||
* We always try to use Drupal functions where they exist. This helps with upgrades (among other things). | ||
* Use `drupal_get_path();` to create a path to a file in your module directory. | ||
* Use `path_to_theme();` to create a path to a file in the current theme directory. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now Drupal\Core\Theme\ActiveTheme::getPath();
@jeffgreenberg just looked at your changes, those look good! sorry for the delay |
More to do by me…sorry for my delay ☹
From: Richard Allen <notifications@github.com>
Reply-To: Bixal/techbook <reply@reply.github.com>
Date: Wednesday, January 15, 2020 at 9:09 AM
To: Bixal/techbook <techbook@noreply.github.com>
Cc: Jeff Greenberg <jeff.greenberg@bixal.com>, Mention <mention@noreply.github.com>
Subject: Re: [Bixal/techbook] updating organization and updating drupal standards (#21)
@jeffgreenberg<https://github.com/jeffgreenberg> just looked at your changes, those look good! sorry for the delay
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#21?email_source=notifications&email_token=AOFEFHFVALN24CE64AFZLZ3Q54KIXA5CNFSM4KBMYUL2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJAMQWQ#issuecomment-574670938>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AOFEFHH5GSSEVS2SRMJWNNLQ54KIXANCNFSM4KBMYULQ>.
|
Hey folks, I know we still have work, but I'm going to merge in what we have so far so this doesn't get stale. The branch is still in this repo so feel free to add on to it. |
breaking down standards to technology rather than drupal, moving drupal standards to its own section, and breaking out composer and good general application development + 12factor apps