Step 1. https://ddev.readthedocs.io/en/latest/
Install (OSX):
Homebrew
Docker or Colima
Install DDEV
First Project:
user@users-MBP Sites % mkdir gt_test
user@users-MBP Sites % cd gt_test
user@users-MBP gt_test % ddev config
Creating a new ddev project config in the current directory (/Users/user/Sites/gt_test)
Once completed, your configuration will be written to /Users/user/Sites/gt_test/.ddev/config.yaml
Project name (gt_test): gt
Setting up a private filesystem requires some under-the-hood configuration, so the following is recommended only for someone who already understands filesystems and editing configuration files.
These instructions are tailored for the OIT Web Hosting Plesk servers, but can be adapted to other configurations. Instructions are based on using the Plesk GUI, but you can also accomplish all of the Plesk related steps from an SSH connection if you are more comfortable in a command line environment.
A Drupal module called Access Filter combined with a private filesystem can be used to limit file access to campus and VPN IPs only. For most cases, that's just as good as using forced logins via CAS authentication without the headaches of having a user account created on your Drupal site for every person who accesses one of your protected pages or files.
At some point, you or your content manager will have a need to share files via your unit's Drupal website, but what is the right way to do this?
The following information is currently targeted to those site admins who have a site built on a custom theme implementation or have written custom modules for Drupal 9.
If you are using the standard Drupal 9 Drupal Express provided by Institute Communications, you should wait until they release a new version of the Georgia Tech theme package before trying to upgrade to Drupal 10.
A list of things to be watchful for when upgrading to Drupal 10 (to be expanded in the near future):
Here's a quick reference guide to working with the new configuration management system. You'll need this if you want to build a module that adds its own configuration to Drupal during its installation process:
Here's how to whitelist HTML tags in your module output that are normally stripped out by the XSS filter:
$tagList = array('input');
return array(
'#markup' => $buffer,
'#allowed_tags' => array_merge(\Drupal\Component\Utility\Xss::getAdminTagList(), $tagList),
);
And here's how to allow data URLs in your module output for displaying images with data that you've already pulled in from a data source (code updated 2017-12-11 to a better format that avoids whitescreening in certain use cases):
Drupal 7 began forcing mySQL to act like a traditional SQL server so that all SQL code used in Drupal will be highly compatible with other database systems like PostgreSQL or SQLite. This means that mySQL statements that syntactically work in other contexts may produce errors under Drupal 7 or 9. Drupal 8+ adds the 'ONLY_FULL_GROUP_BY' restriction, which can potentially cause custom mySQL code that worked in Drupal 7 to fail with errors in Drupal 8+.
Here's the exact settings being used in Drupal 8:
The following method is a little more round-about, but doesn't require as much coding knowledge as the previous method. The main downside is that it may be difficult for someone in the future to figure out where your custom PHP or embed code has been stored, since this is a non-standard and uncommon method.
Scott Jacobson, Desmond Gardfrey, and Eric Sembrat were able to get Georgia Tech's MediaSpace working as an oembed provider for Drupal media. Below is the method they developed.
Add the OEmbed Providers module