Developing on our server

We have development environments available with cloned and sanitized copies of *.drupal.org. If you'd like one of your own and have a decently good reason, or to access one of the existing ones and collaborate with others, here's how to get started:

Getting connected

1. Make sure your public SSH key is uploaded to your git.drupalcode.org account (instructions) and then ask for your public key to be manually added to the devwww server.
2. If there is no development site which you can use, you need to request a development environment. Be sure to include a bit about your skills and plans (ideally, links to specific issues you're planning to work on)
3. Once you have access, ssh with your user id to devwww.drupalsystems.org to access files, e.g.
   ssh yourusername@devwww.drupalsystems.org.
   You'll be asked to verify a fingerprint, the current (March 2024) fingerprints are 
   • RSA key SHA256:en8PZrbIjEmYlgFIwq/WLMm0eDWfy7xLIXfs8WraCxQ
   • ECDSA key SHA256:ltTvJ0GxPQRAEwKeOskTeG+YVhIeYBjkHpvt2afo8kg
   • ED25519 key SHA256:d33cXZqWbHzCifQM7Io56jTCFlHO/MWEIlgeEkcwqSU
4. Development environments are subdirectories of /var/www/dev on the server. Directory name looks like: [your project or username]-drupal.dev.devdrupal.org.
   For example: /var/www/dev/metrics-drupal.dev.devdrupal.org.
   Directory name is also the URL of your development site:
   http://metrics-drupal.dev.devdrupal.org/.
5. Any development site will prompt you for an initial password when you try and access it in browser. That user/pass is 'drupal/drupal'.
6. On your development site you will want to log in as user/1 to be able to do stuff:

   Dries is user/1 for Drupal.org. For Groups.drupal.org it's moshe weitzman. Other sub-sites might have different user/1.

   You can find out the information about user/1 by running drush uinf 1

   • ssh to devwww.drupalsystems.org and go to your /var/www/dev/XXX-drupal.dev.devdrupal.org/htdocs folder
   • run drush uli
   • Copy and paste the resulting URL into your browser to be logged in as user/1.

Making changes

If you want to make a diff of your changes you will need to replace the relevant module/theme with a Git clone:

drush pm-download --package-handler=git_drupalorg libraries

Some projects may already be a Git clone, you can checkout the appropriate branch Now you can use Git to update code, work in branches, and make patches for issues.

The reason for this is because the drush make for each site is a snapshot of the modules and themes on the live site at the time the dev site is created. Therefore you are not working with code that you can create a diff from.

Notes & tips

• Use drush from the htdocs directory:
  • Get a reset password link to log in to Drupal: drush uli [username]
  • Access the database: drush sql-cli
  • Clear caches: drush -v cc [all|etc]
  • Run cron: drush -v cron
  • Clone a module for development: drush pm-download --destination=sites/default/modules --package-handler=git_drupalorg drupalorg. Projects in sites/default override sites/all after drush cc module-list && drush -v cc all.
• You can add & update contrib projects, for development only. The process for deployment for the live site is different. You will need to include the specific modules and versions in deployment instructions.
• Your environment will not be automatically updated as Drupal.org changes. You can have it completely rebuilt when needed. Before doing that save any local changes as patches in the issue queue or in Git branches.
  Instructions: Re-imaging a copy of your Drupal.org development environment.
• Add ForwardAgent yes to ~/.ssh/config on your local computer to use your SSH keys on the server. This will let you push to Drupal.org Git repositories
• See instructions on the child pages about using tools like FUSE with sshfs to mount or sync the website files locally; This may be a more convenient option for editing files if you are not comfortable editing in a terminal window.

Local development

Local development for Drupal.org is not supported.

However, if you have the ability to successfully run a local development environment, go ahead. Support will be limited. People have had issues with successfully getting the large DB imported; and server configuration differences can lead to problems. Always push code back to devwww for review by others, and testing in a production-like environment.