*IN FLUX (April 2016)*

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

All communications with the ICT & Media admins, the data center that hosts the website (see links to FQDNs below), should have ​sysops@clarin.eu in CC.

1. Development workflow

Development follows a three-stage workflow:

1. development: dev-www.clarin.eu?
2. acceptance
3. production: Archive/www.clarin.eu

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

1.1. Tickets

Results (1 - 10 of 23)

1 2 3 →

Ticket	Priority	Summary	Owner	Keywords	Created	Modified
#907	minor	support multi-file upload again	André Moreira		8 years ago	6 years ago
#938	major	Replace clarin_datatable custom code by standard feeds module	Dieter Van Uytvanck		8 years ago	6 years ago
#958	minor	Files missing	Dieter Van Uytvanck		8 years ago	6 years ago
#965	minor	Clean up Drupal redirects	Dieter Van Uytvanck		8 years ago	6 years ago
#967	major	User involvement group pages on new website	Dieter Van Uytvanck		8 years ago	6 years ago
#990	major	Recreate organig group views	Dieter Van Uytvanck		7 years ago	6 years ago
#1002	minor	strip typographic quotes from URLs	André Moreira		7 years ago	6 years ago
#1003	minor	Investigate possibilities to add the content of views to search index	Dieter Van Uytvanck		7 years ago	7 years ago
#1006	minor	Investigate a web-based alternative to google earth for the VLW	Dieter Van Uytvanck		7 years ago	7 years ago
#1029	minor	provide governance view with affiliation field	Dieter Van Uytvanck		7 years ago	6 years ago

1 2 3 →

2. New plans

Branding

3. Important management tasks

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

3.1. Use the working custom Drush version

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

3.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.

4. 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.

4.1. The clarin_eric_config module depends on wysiwyg and other outdated and/or custom modules

For WYSIWYG rich text editing, either wysiwyg or ckeditor is needed. wysiwyg is an extra layer of complexity that allows you to configure various alternative WYSIWYG editing libraries. However, only CKEditor seems current and still maintained among these. The CKEditor JavaScript? library must be installed locally inside the Drupal code base for it to be detected by wysiwyg. wysiwyg conflicts with ckeditor and only supports CKEditor >= 3, < 4. After the emergency (security) update of Drupal from 7.39 to 7.43, WYSIWYG editing stopped working. For some reason, the CKEditor 4 library is/was still inside the Drupal code base. wysiwyg now fails to detect this CKEditor library, and this is ​on purpose, since its version is not supported apparently. CKEditor 4 has been installed via the ckeditor module after that in order to replace wysiwyg. But wysiwyg does not work when ckeditor is installed. Yet wysiwyg is required (depended on) by the custom clarin_eric_config module that is currently unmaintained but essential to site functionality. Thus ckeditor had to be disabled againg and there is no WYSIWYG editor available anymore for the time being. The solution is to update the clarin_eric_config to not depend on wysiwyg or any other unnecessary modules, and then to replace the module wysiwyg with ckeditor.

4.2. Complex redirects

There are a lot of redirects in place in /etc/apache2/. See how we can simplify this.

4.3. 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.

4.4. 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.

4.5. 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.

4.6. 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.

5. Historical situation

5.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.

5.2. Backups

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

5.2.1. Manually, through web interface

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

5.2.2. Manually, from command line

With ​`archive-dump`

drush archive-dump # --no-core

​or:

drush bam

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

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

5.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 

5.4. Common error messages

5.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.

5.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

5.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.

5.4.4. Failed Drupal upgade …

​Restore from backup archive.