We use the ​Drupal Content Management System (CMS) for ​https://www.clarin.eu. ​A general, brief overview of Drupal.

Development follows a three-stage workflow:

1. development: tst.clarin.eu?
2. staging/acceptance: staging-www.clarin.eu?
3. production: www.clarin.eu?

Drupal should be managed from the command line with ​Drush. ​Commands for drush.

1. Important management tasks

Execute all drush commands from within /hum/web/clarin.eu/htdocs/.

1.1. Use the working custom drush version

alias drush=/hum/web/clarin.eu/private/drush/drush/drush

1.2. Set website to read-only or back to read-write

drush --uri='http://www.clarin.eu' vset site_readonly 1

the last parameter is 1 for read-only, 0 for read-write.

2. Current issues (2016)

Below are the most pressing issues (defects, misconfigurations, etc.) at hand. These do not include functionality enhancements that are in the pipeline.

2.1. Migrate from multisite setup (multiple directories in sites) to single site setup.

Reasons:

1. Multisite leads to multiple settings.php files and multiple databases for various specific sites.
2. With multisite, it is not clear which content resides where. (e.g. in sites/default/, sites/all/ or sites/clarin.eu/?)
3. Multisite leads to unclarity about which sites are actually used and active.
4. Multisite has caused issues with drush archive-dump backup: stale sites with incorrect settings.php files (e.g. MySQL credentials).
5. drush in general can only deal with specific sites, specified by the --uri parameter. This parameter does not correspond one-to-one to a site directory. For example, ​http://www.clarin.eu actually matches clarin.eu/, but only hopefully/apparently.

2.2. Create fresh and clean Drupal and drush installation

Current problems:

1. It appears that ​Composer or just any OS or PHP package manager hasn't been used to manage Drush and Drupal. An outdated Drush version was hand-installed at /hum/web/clarin.eu/private/drush/drush/drush.
2. install.php still accessible (major security risk!?). In case the website is misconfigured in any way, or if the MySQL table is not accessible, then an install page was offered publically.
3. Editor temp files (e.g. *.swp) lingering around in the htdocs/ root directory. These give public access to contents without reason.
4. Many potentially outdated README-type documents lingering around.

2.3. Use different passwords for Unix root, Drupal admin and MySQL database

Currently, a single password is used, which means that e.g. drush archive-restore has the password to not only the relevant MySQL database (as set in settings.php) but also to the global MySQL settings tables. Since drush has design flaws, this is risky: it has been found to overwrite the MySQL root user password during backup restoration. If someone gets Drupal's settings.php file (e.g., because of a .htaccess problem) and can exploit any PHP/Drupal bug or misconfiguration, he can root the entire OS.

2.4. Update each module piece by piece, not just for security issues

We should use only stable versions of third party modules. Furthermore, we should cut down the number of modules insofar possible.

Current problems:

1. Development versions (betas and even alphas) of modules are currently used in production.
2. These versions are largely outdated according to drush.
3. In addition, a lot of modules cannot be updated by drush. They were customized or are incompatible/unavailable for other reasons.
4. It unclear whether updating the modules would break anything.

3. Historical situation

3.1. Drush availability

Drush is installed in Bas van der Veen and Jurriaan Roelof's home directories instead of in a system-wide $PATH directory. Users from the Unix group clarinadmin can access it. At this moment Bas van der Veen can perform Drush commands (in directory /hum/web/www.clarin.eu/htdocs/sites/clarin.eu or /hum/web/tst.clarin.eu/htdocs) /home/bvdveen/drush/drush status

The current version is outdated (5.8) and should be updated after planned OS upgrade (Feb 2016). Recent drush subcommands may not work otherwise.

In the following, let "${Drupal_root_dir_path}" be the root directory path of the Drupal installation.

3.2. Backups

ICT & Media system administrators are responsible for a regular backup through a filesystem(?) snapshot.

3.2.1. Manually, through web interface

​https://www.clarin.eu/admin/config/system/backup_migrate

3.2.2. Manually, from command line

With ​`archive-dump`

drush archive-dump # --no-core

​or:

drush bam

3.2.3. Manually, from command line (error prone version)

sudo tar -cvJ -C '/hum/web/www.clarin.eu/htdocs' -f ‘bckup_clarin_28oct15’ .

3.3. Which updates are available?

drush -r "${Drupal_root_dir_path}" -s core-status Drupal

Check if a module is listed under ../sites/all/patches. Patches are often integrated in higher non-patch versions of modules. See: ​https://www.drupal.org/patch (manually apply patch: ​https://www.drupal.org/node/534548).

---

# Or: '/hum/web/tst.clarin.eu/htdocs/'
cd '/hum/web/www.clarin.eu/htdocs/sites/clarin.eu/'
drush status
# List patches
drush ups --security-only 
# Apply patches
drush upc --security-only 

3.4. Common error messages

3.4.1. Wrong directory

Command pm-refresh needs a higher bootstrap level to run - you will need to invoke drush from a more         [error]
functional Drupal environment to run this command.

3.4.2. ups failed

The drush command 'ups' could not be found.  Run `drush cache-clear drush` to clear the commandfile cache if [error]
you have installed new extensions.

You did not use Drush 5 or higher. Instead, you could issue:

drush up --security-only

3.4.3. Forbidden to download drupal core

It's forbidden to download drupal core into an existing core. 

drush rf

# In case database migration is needed:
drush updb                              

# Should not show available updates or errors:
drush status                            

• Check website, and disable maintenance mode.
• Possibly, Drupal Features must be reset:

  drush features-list
  # Reset Drupal Features:
  drush fr -y openscience_demo_content openscience_events --force 
  

• In case the previous has failed, indicated by the status being overridden, consult ​https://www.drupal.org/node/986932. A quick fix is to remove and reinstall all Feature modules, but for custom Features (openscience, clarin_eric_config) that will fail.

3.4.4. Failed Drupal upgade …

​Restore from backup archive.