Changes between Version 20 and Version 21 of Webdev


Ignore:
Timestamp:
06/21/16 15:34:55 (8 years ago)
Author:
Sander Maijers
Comment:

update to current situation

Legend:

Unmodified
Added
Removed
Modified

  • Webdev

    v20 v21  
    55We use the [https://www.drupal.org Drupal] Content Management System (CMS) for [https://www.clarin.eu].
    66[http://poplarware.com/articles/drupal_cheat_sheet A general, brief overview of Drupal].
    7 
    8 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.
    97
    108# Development workflow #
    … …  
    2523[[Branding]]
    2624
    27 # Important management tasks #
    28 
    29 Execute all `drush` commands from within `/hum/web/clarin.eu/htdocs/`.
    30 
    31 ## Use the working custom Drush version ##
    32 
    33 {{{
    34 #!sh
    35 
    36 alias drush=/hum/web/clarin.eu/private/Drush/drush.phar
    37 }}}
    38 
    39 ## Set website to read-only or back to read-write ##
    40 
    41 {{{
    42 #!sh
    43 
    44 drush --uri='http://www.clarin.eu' vset site_readonly 1
    45 }}}
    46 the last parameter is `1` for read-only, `0` for read-write.
    47 
    4825# Current issues (2016) #
    4926
    … …  
    5330
    5431For 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 [https://www.drupal.org/node/1853550 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`.
    55 
    56 ## Complex redirects ##
    57 
    58 There are a lot of redirects in place in `/etc/apache2/`. See how we can simplify this.
    59 
    60 ## Migrate from multisite setup (multiple directories in `sites`) to single site setup. ##
    61 
    62 Reasons:
    63 a. Multisite leads to multiple `settings.php` files and multiple databases for various specific `sites`.
    64 a. With multisite, it is not clear which content resides where. (e.g. in `sites/default/`, `sites/all/` or `sites/clarin.eu/`?)
    65 a. Multisite leads to unclarity about which sites are actually used and active.
    66 a. Multisite has caused issues with `drush archive-dump` backup: stale sites with incorrect `settings.php` files (e.g. MySQL credentials).
    67 a. `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.
    68 
    69 ## Create fresh and clean Drupal and drush installation ##
    70 
    71 Current problems:
    72 a. It appears that [https://getcomposer.org/doc/00-intro.md 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`.
    73 a. `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.
    74 a. Editor temp files (e.g. `*.swp`) lingering around in the `htdocs/` root directory. These give public access to contents without reason.
    75 a. Many potentially outdated README-type documents lingering around.
    76 
    77 ## Use different passwords for Unix root, Drupal admin and MySQL database ##
    78 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.
    7932
    8033## Update each module piece by piece, not just for security issues ##