Site updates

Akeeba Solo

Wachtwoord vergeten?

Zie: https://www.akeebabackup.com/documentation/akeeba-solo/system-management.html#password-reset

Site restore with Solo instead of Kickstart

If you made a backup with Solo, you can always restore it with Solo as well, even if you've deleted the .jpa and .log file from the server.

Manual update

If the most recent version of Akeeba Solo Core is a beta version (e.g. 7.0.0.b3), your current Akeeba Solo Core version (e.g. 3.3.2) will not show any more recent versions, even if a more recent stable version (e.g. 3.6.1) is available.

If you want to update your Akeeba Solo Core then, you'll have to do it manually. See https://www.akeebabackup.com/documentation/akeeba-solo/updating.html.

Akeeba Kickstart

applicatie acties vereist na Kickstart
Drupal .../sites/default/settings.php:
  • adapt values for database, username & password
  • mark out the trusted_host_patterns setting - otherwise you'll get 'The provided host name is not valid for this server'
Events ?
Pydio .../data/plugins/boot.conf/bootstrap.json:
adapt values for mysql_username, mysql_password & mysql_database
empty the .../data/cache subdirectory, except for one file: plugins_requires.ser
Joomla no actions required
Forms ?
Foswiki ?

Issues on Joomla!

Restore van KLA op Cloud9 mislukt met volgende error:
SQL=SELECT COUNT(extension_id) FROM `extensions` WHERE `type` = 'plugin' AND `folder` = 'twofactorauth' AND `enabled` = '1'

Oplossing: bij het herstel van de database de geavanceerde opties openen en bij Database tablenaam prefix jos_ opgeven.

Issues on Drupal

Could not upload .xyz/...

Bij het restoren van Drupal-sites van Cloud9 op een WAMP (Windows), krijg je de foutmelding dat de .c9-directory niet kan worden uitgepakt:

AN ERROR OCCURRED
Could not upload .c9/metadata/preview-https:/....c9users.io

Logisch op Windows, maar je kan dat alleen sluiten, waarna het restoren stopt. Alle bestanden zijn uitgepakt, maar de database is nog niet hersteld. Je kunt dat evenwel handmatig initiëren door te surfen naar de directory installation:

http://localhost/<omgeving>/installation/

Waarna de database kan worden hersteld.

Verder is Akeeba niet echt op Drupal gericht, dus na een restore moet je:

in <omgeving>\sites\default\settings.php: $base_url corrigeren en https uitschakelen voor gebruik op localhost

Token T_VARIABLE with value $drupal_hash_salt not found

impossible to finish restore - however, after adapting the settings.php, the drupal site was fully accessible

UnexpectedValueException — DirectoryIterator::__construct(/home/ubuntu/workspace/sites): failed to open dir: No such file or directory

impossible to finish restore - however, after adapting the settings.php, the drupal site was fully accessible

The installer keeps "Initialising" endlessly

On 05/01/2019, I got an irreversible Drupal error:
The website encountered an unexpected error. Please try again later.

Whatever I tried, I couldn't access any drupal pages anymore.

This was probably due to Apache ModSecurity, because the Apache error log stated:

[Sat Jan 05 08:39:36.343681 2019] [:error] [pid 9892] [client 78.22.142.20:54726] [client 78.22.142.20] ModSecurity: collection_retrieve_ex: Failed deleting collection (name "default_SESSION", key "ca587dae2ad39fdd78edde2b299e81b5"): Internal error (specific information not available) [hostname "voxmago.be"] [uri "/"] [unique_id "XDBfOANWSEe0PxIeKPISkwAAAAo"]

When I tried to restore my last Akeeba backup, I had the following issue (both on the development environment as on the live site):
Initialising.png
Finished.png

The provided host name is not valid for this server

After restoring the site, you clear the cache, and get The provided host name is not valid for this server.

#$*@&! or WTF?!, you think, but all you need to do, is to mark out trusted_host_patterns setting:
/** 
 * $settings['trusted_host_patterns'] = array(
 * '^www\.muzitaal\.be$', '^muzitaal\.be$',
 * );
 */

The website encountered an unexpected error. Please try again later.

I got this message on Cloud9 and I first followed the following hint: run update.php.

Then I saw a message stating that the gd PHP extension was missing or needed to be enabled. This could be solved by issuing the following commands:
sudo apt-get autoremove
sudo apt-get update
sudo apt-get install php7.2-gd

Error - Cannot use object of type AModel as array

When moving the Vox Mago drupal installation from 123-webhost to HostingSquad, I encountered this issue (twice, because I retried). However, I could simply click Next and continue the restore procedure without any troubles:

AModel65pct.png

eXplio ► boossy.be

I once made a copy of digitaalwerkboek.be on boossy.be/dwb. For the links to work, proceed as follows:

General issues with backup/restore

drupal folder cannot be deleted / settings.php or other file in ~/sites/default cannot be deleted

HTTP ERROR 500 - 1

After restoring http://wds.boossy.be/d733eindwerk/, which was already Drupal 7.67 to the backup of Drupal 7.53, I got HTTP ERROR 500.

I was able to get a working site by selecting PHP 5.x instead of PHP 7.x.

I only found this out by enabling php error reporting in the drupal index.php. See https://www.drupal.org/node/158043:

To enable error reporting, temporarily edit your index.php file (normally located in your root directory) directly after the first opening PHP tag (do not edit the actual file info!) to add the following:

<?php

error_reporting(E_ALL);
ini_set('display_errors', TRUE);
ini_set('display_startup_errors', TRUE);

You will now be able to see any errors that are occurring directly on the screen. Memory problems may still not be displayed, but it's the first step in a process of elimination.

Then I got:

Notice: Constant DATE_RFC7231 already defined in ~/d733temp/includes/bootstrap.inc on line 258

Fatal error: Only variables can be passed by reference in ~/d733temp/sites/all/modules/commerce/modules/cart/commerce_cart.module on line 1344

Googling the first of these two errors brought me to https://www.drupal.org/project/drupal/issues/2877243, making me conclude rightly that it was due to the php version.

HTTP ERROR 500 - 2

Na het restoren via Akeeba Solo van een Joomla 3.x site kreeg ik een HTTP ERROR 500.

Bleek de FRONTEND / BACKEND links naar de directory ging ipv naar het subdomein (wellicht backup ook gestart vanuit dir ipv sub):

No images on Drupal 8 site after restore