Log inRegister

Site updates

  • In geval van Drupal, eerst de modules, dan de core!
  • In geval van !PhpJabbers-tool, versienr. vind je hier: app/config/options.inc.php: PJ_SCRIPT_BUILD

Akeeba Solo

Wachtwoord vergeten?

Zie: https://www.akeebabackup.com/documentation/akeeba-solo/system-management.html#password-reset
  • methode 2 werkte voor mij
  • met het 2de vermelde wachtwoord
  • volgens mij had het te maken met de overgang van PHP 5.x naar 7.x…

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.
  • just put your .jpa file back in the backups directory
  • go to the Akeeba Solo Core UI and choose Manage Backups
  • scroll down to the description/profile line containing the date and time/profile of your backup
  • click on the 'i' icon to the right of - Backup Archive information
  • check the What was it called? value and make sure the backup you put in the backups directory, is (re)named that way - maybe you renamed the file for clarity (vm-pydio8.2.2-'181227-1140.jpa ◄► site-www.voxmago.be-20181227-114003.jpa)
  • when it's got the right name, check the check box in front of your backup and click the Restore button
  • the rest is child's play

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:

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:


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] [client] 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):
  • Extract files OK
  • Restoration and Clean Up: Run the Installer: the installer keeps "Initialising" endlessly:
  • If you click → Next however, you can go on with the restoration of the site's database - the connection info is even filled in correctly on the live site
    so the restore finishes correctly
  • the finished screen is not skinned correctly, however:

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:


eXplio ► boossy.be

I once made a copy of digitaalwerkboek.be on boossy.be/dwb. For the links to work, proceed as follows:
  • if there is an existing - in this case dwb - database, drop it
  • copy the .jpa together with the kickstart files to /domains/boossy.be/public_html/dwb
  • create a wordpress subdirectory
  • launch the kickstart.php
  • at (2) Select an extraction method, choose the wordpress subdirectory as Temporary directory
  • the files are extracted in the root
  • go on with the installer: Run the Installer
  • in the Backup Information screen, /srv/htdocs/www.digitaalwerkboek.be/wordpress/ is mentioned as Root directory
  • click Next and fill in the database information
  • click Next and keep the Site Parameters as they are
  • click Next and accept the replacements to be made

General issues with backup/restore

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

  • set the permissions of the above folder (=default) to 755.

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:


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

  • simply clear the cache!
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback
This page was cached on 29 May 2024 - 13:37.