Let.s consider a Case Study: backup of papierlogik website on drupal and OVH servers

1) Put webite in configuration/maintenance mode

2) Backup database from webcloud/hebergement/database/papierlogik – bouttons 3points a droite: sauvegarder maintenant

    => the database will be sent to you by email. Store it with your website files

3) Copy-paste all your files to your local backup along with the datable. These can next be used to reinstall your website on the OVH distant server as seen above. Best practice is to use ssh to zip you files and download them at once.

Note: using these backup to install the website locally ( e.g. WAMP) or in an other server from another web server provider may lead to issues with unicode to be modified. Be careful with options when saving the database.

 TO ADD: more info on specif unicode

RESTORE A BACKUP VERSION ( Still papierlogik study case)

1) Gather your directory backup and corresponding database.

– Empty your destination folder
 – In the case of Drupal installed with composer: add composer.phar again as seen above.
– Copy/paste the database on your local/distant root folder.

IMPORTANT: at least on ovh if deleting and recreating the database DO NOT CHANGE the database name, user name or password before having restored your site.

r 

1) Create your root folder directory for your website.

•  If your website is local (using e.g. WAMP, MAMP,..), this is the folder that will contain  the data on you own  computer.
• If you wesite is on a server, make sure this is the root for your website and not for your doman or another website on your domain.

 2) Add Composer.phar application to build Composer for your Drupal Install

Your Drupal install already contains parts of the Composer dependencies in the Vendor folder. But it takes a composer.phar application for your computer or you server to setupand manage Composer for your website.

On a distant server you should install composer.phar in your server root folder in a folder bin via ssh.

– To create the bin folder and go there:

    mkdir -p ~/bin

    cd ~/bin

– To create composer.phar, option 1 with curl:

curl -sS https://getcomposer.org/installer | php

– option 2 with wget if curl is not available:

wget https://getcomposer.org/composer.phar 

Verify the installation:

• After running the command, you should now see composer.phar when you type ls.

• Test it by typing:

  php composer.phar --version

   3) Use composer to create a new fresh drupal website in you directory

Case Study: update from Drupal 9 to Drupal 10

https://www.drupal.org/docs/updating-drupal/updating-drupal-core-manually

https://www.drupal.org/docs/upgrading-drupal/upgrading-from-drupal-8-or-later/how-to-upgrade-from-drupal-9-to-drupal-10

https://www.drupal.org/docs/upgrading-drupal/upgrading-from-drupal-8-or-later/how-to-upgrade-from-drupal-9-to-drupal-10#common-issues

https://www.bounteous.com/insights/2023/02/22/upgrading-drupal-10-and-beyond-composer/

Case study: backup of papierlogik site folder and database from distant site on OVHserver  (to be recovered in the same environment)

Create from scratch for drupal9:
https://www.valuebound.com/resources/blog/creating-custom-form-drupal-9

or use the WebForm Module:
https://www.drupal.org/project/webform

3 

Solving HTTP 500 internal error can be critical to save you website after and adventurous but failling upgrade.
This happened to me a few times involving the loss of a project or hours to find a solution.
Since these early experiences, I learned ssh can be an efficient tool to track issues and modify files to get the website back in order.

Especially with a CMS like drupal, integrated control tools such as drush and composer are fairly convenient for this task along with some vibe coding on AI.
I am profittting this new issue on my papierlogik website; while trying enable new modules installed in RC mode with the help of Gemini Flash, that does not do so well so far as it lead me to this crash.

A first try consists in using drush to disable the conflicting modules just installed:

drush pmu commerce_autosku token

Another method is to try running Drush using its local path:

php /homez.916/cellucomvi/bin/composer.phar exec drush pmu commerce_autosku token

If you still get an error, it might mean Drush wasn’t fully installed as a dependency within your Drupal project, or there’s another issue. In that case, we need to fall back to the manual method to disable the modules and get your site back online.

Fall back to Option 2: Manually Disable Modules (via core.extension.yml)

This is the most reliable way to get your site back if Drush isn’t immediately cooperating.

1. Connect to your server via SSH using PuTTY.

2. Navigate to your site’s configuration directory. This path can vary slightly but is usually within web/sites/default/files/config_HASH/sync/ or web/sites/default/config/sync/.

From your Drupal root (~/drupal_papierlogik), try to find it:

1. • cd web/sites/default/files/
     ls -d config_*/sync/
     

      

     • This should output something like config_somerandomstring/sync/. Note that full path.

     • Then cd into it:

       Bash

       cd config_somerandomstring/sync/
       

        

       (Replace somerandomstring with your actual hash).

   • If config_*/sync/ doesn’t exist, try:

     Bash

     cd /home/cellucomvi/drupal_papierlogik/web/sites/default/config/sync/
     

      

2. Edit the core.extension.yml file:

   Bash

   nano core.extension.yml
   

    

3. Locate and Delete the Module Lines:

   • Find the lines that look like this (they might not be next to each other):

     YAML

     commerce_autosku: 0
     token: 0
     

      

   • Carefully delete these two entire lines, including any leading spaces.

   • Save the file: Press Ctrl+X, then Y to confirm saving, then Enter.

4. Clear Drupal’s caches (crucial after manual config changes):

   • Since we’re assuming Drush isn’t working, you’ll need to use your browser.

   • In your web browser, go to: yourdomain.com/core/rebuild.php

   • This page should appear, and you’ll click the button to rebuild the cache. If it still gives an HTTP 500, try clearing your browser’s cache for your site, then refresh.

5. Check your website in the browser. It should hopefully be back online.

Voici la bonne séquence d’opérations pour supprimer un module inutile ou obsolete, par example avant une mgration vers une nouvelle version majeur de Drupal (à ce jour Prod en d10 et dev en d10-d11)

DEPUIS LA RACINE DE VOTRE SITE VIA SSH (CMD, PUTTY…)

1. Désinstaller les modules avec Drush : Vous avez déjà fait cette étape, ce qui a supprimé les données des modules de votre base de données

2. Supprimer le code avec Composer : Vous êtes sur le point de le faire. Cette étape retire les fichiers des modules de votre serveur.

3. Mettre à jour la base de données (updatedb) : Cela s’assure que toutes les modifications de la base de données liées à la suppression des modules sont bien finalisées.

4. Vider le cache (cr) : C’est une étape cruciale pour s’assurer que Drupal ne fait plus référence aux fichiers qui viennent d’être supprimés et que les changements sont pris en compte.

Application case with Gemini to prepare migration from d9 to d10