Donc, il ne faut pas de \ dans le mot de passe car search and replace le voit comme un échappment. Je vais donc modifier le mot de passe.

La page du script est déjà pré-remplie: nom de la db, utilisateur, mot de passe, host (sql) et j'ai rajouté le port Mysql  3306

Non, la page n'est PAS pré-remplie (sauf peut-être pour WordPress, la chose ayant une heuristique dédiée à ce CMS). Les champs texte contiennent par défaut des valeurs bidons à titre d'exemple, c'est tout. Tu dois donc tout fournir ;
- name : le nom de ta base de données chez TuxFamily
- user : chez TF, c'est la même valeur que le nom de la base de données
- password: le mot de passe pour accéder à ta db
- host : sql
- port : 3306 -- si tu laisses vide, il se débrouillera tout seul

Tu peux récupérer toutes ces infos dans librefan.eu.org/htdocs/sites/default/settings.php (ligne 215) -- FAIS GAFFE ! Il faut fournir le password sans échappement ; donc si tu as des choses genre \\, \$, \' ou \" dans ton settings.php, il faut enlever le premier backslash.

Problème d'accès à la DB avec l'outil “search and replace” (https://interconnectit.com/products/sea … databases/)
- J'ai mis mon site en offline
- J'ai placé le répertoire “search and replace” dans mon htdocs/ en lui donnant un nom top-secret comme il est conseillé.
- J'ai bien accédé au script sur le web à partir de mon librefan.eu.org

La page du script est déjà pré-remplie: nom de la db, utilisateur, mot de passe, host (sql) et j'ai rajouté le port Mysql  3306

J'ai donc commencé par remplir les deux cases pour remplacer une url par une autre et j'ai cliqué sur le bouton Dry run, ce qui m'a donné cette erreur:

SQLSTATE[28000] [1045] Access denied for user 'db_user'@'192.168.1.72' (using password: YES)

C'est en fait la même erreur que là: http://insyncapp.net/Search-Replace-DB-master/

J'ai vu dans PhpMyAdmin que l'utilisateur est de la forme: db_user@192.168.1.70 ou autre (sans doute une plage).

J'ai bien sûr cherché le pourquoi de cette erreur sur le web rien trouvé d'utile.
En lisant la FAQ de TF, (https://faq.tuxfamily.org/DbMySQL/Fr) j'ai trouvé ça:

mais ça ne doit pas être le problème ici.

Sauf si j'ai mal placé le répertoire de Search and replace? Mais je dois pouvoir y aller depuis librefan.eu.org, je ne vois pas où le mettre ailleurs.

Je n'ai aucun problème avec PhpMyadmin pour aller regarder la DB, ni jamais eu aucun problème de connexion à la DB depuis Drupal.

En attendant, j'ai bien sûr supprimé le répertoire top-secret search and replace et remis mon site en ligne.

Eh non, mais en découvrant le mouvement anti-www, j'ai vu le yes-wecanwww (façon de dire).

Je suis bien rassurée, pensant que mon rejet de www était le fait de mon ignorance arrogante.

Apparemment, avec leur CDN, ils n'avaient pas le choix. C'est avoir choisi un CDN tout fait (Edgecast, comme _Le Monde_ [s1.lemde.fr, s2… etc], pour les photos et les CSS) que je trouvé répréhensible pour ma part. Il me semble qu'avec CozyCloud ils pouvaient se faire un CDN libre et à eux. J'ai regardé une conf sur CozyCloud et ça fait Plateforme as a Service, avec machines virtuelles n'importe où dans le monde, qu'on allume, qu'on éteint au gré des besoins.
J'ai mis un petit mot sur Drupal à ce sujet, à la suite d'un commentaire qui regrettait qu'une solution libre n'ait pas été trouvée. C'est vain, mais peu importe ;-)

C'est presque tout clair, sauf qu'ils indiquent un port pour la DB mysql et je n'ai pas l'impression que chez TF on a besoin d'indiquer un port quelconque.

Chez TF, tu as l'habitude d'indiquer simplement "sql" mais en fait, dans le contexte d'un client MySQL, ça signifie par défaut "sql:3306" (donc hostname sql et le port par défaut pour le protocole MySQL : 3306).

Du coup savais-tu qu'il existait le mouvement opposé ? http://www.yes-www.org/

Normal, pour la plupart des gens qui ont des notions de DNS (ce qui est le cas chez Tuxfamily, je précise), le "www" c'est un non-sens historique bon à jeter.

J'ai bien un avis sur la question, je peux l'exprimer très concisément mais pas poliment...

J'ai regardé https://interconnectit.com/products/sea … databases/
C'est presque tout clair, sauf qu'ils indiquent un port pour la DB mysql et je n'ai pas l'impression que chez TF on a besoin d'indiquer un port quelconque.

Je ne savais pas du tout qu'il y avait un mouvement anti www. C'est amusant de voir qu'au contraire drupal.org est passé à www.drupal.org, je crois que c'est parce qu'ils ont mis Drupal.org sur le CDN d'Edgecast ;-(
Et je vois aussi que tuxfamily.org n'a plus son www et redirige l'ancienne url vers tuxfamily.org

Bon je vais m'atteler à tout ça la semaine prochaine,

Bon week-end à tout le monde

Enfin, tu peux ajuster ton .htaccess. J'ai pris la liberté de jeter un coup d'œil à ton .htaccess ; précisons qu'il s'agit du même .htaccess qu'on peut trouver dans l'archive officielle drupal-7.43, avec pour seule modification pour le moment que tu as décommenté la directive "RewriteBase /".

Commençons par implémenter une redirection HTTP->HTTPS, càd une redirection effective uniquement en HTTP vers l'URL équivalente en HTTPS. Juste en-dessous de "RewriteEngine On", on ajoute :

# If the request comes over HTTP, enforce HTTPS through a 301 response:
RewriteCond %{HTTPS} !on
RewriteRule ^ https://librefan.eu.org%{REQUEST_URI}  [L,R=301]

On pourrait chipoter et générer une 307, théoriquement plus adaptée, mais la 301 a le mérite d'être vieille comme le monde, comprise de tous les navigateurs et de convenir dans 99.99...% des cas.

Enfin, pour forcer les gens à taper librefan.eu.org et non www.librefan.eu.org (rejoignant ainsi le mouvement http://no-www.org/ ), tu peux simplement décommenter les directives suivantes fournies par Drupal :

  # To redirect all users to access the site WITHOUT the 'www.' prefix,
  # (http://www.example.com/... will be redirected to http://example.com/...)
  # uncomment the following:
  RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
  RewriteRule ^ http%{ENV:protossl}://%1%{REQUEST_URI} [L,R=301]

Au-delà des manipulations que je viens de décrire, tu ne devrais pas avoir besoin de supprimer, modifier ou ajouter la moindre directive dans le .htaccess.

Il s'agit de mettre un site fait avec Drupal, entièrement en HTTPS, download.tuxfamily.org compris. et en passant, faire accéder le site uniquement par http://domaine.fr et non pas http://www (c'est juste que je ne vois pas l'intérêt pour moi. J'ai peut-être tort.

Dans la base de données:
J'ai lu que certains n'ont rien trouvé de mieux qu'importer leur DB, et faire search and replace dans Geany ;-)
Est-ce une solution?

URLs générées par Drupal
Oui, j'ai vu en lisant sur Drupal:

$base_url se met dans settings.php, c'est facile.

Ensuite, .htaccess
Dans ce fichier il y a déjà des choses:

# Various rewrite rules.
<IfModule mod_rewrite.c>
  RewriteEngine on

  # Set "protossl" to "s" if we were accessed via https://.  This is used later
  # if you enable "www." stripping or enforcement, in order to ensure that
  # you don't bounce between http and https.
  RewriteRule ^ - [E=protossl]
  RewriteCond %{HTTPS} on
  RewriteRule ^ - [E=protossl:s]

# To redirect all users to access the site WITHOUT the 'www.' prefix,
  # (http://www.example.com/... will be redirected to http://example.com/...)
  # uncomment the following:
   RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
   RewriteRule ^ http%{ENV:protossl}://%1%{REQUEST_URI} [L,R=301]

En décommentant les lignes du dessus comme je l'ai fait, on a fait un tout petit pas. Mais je n'ai pas testé encore ;-)

Sur Drupal, la doc donne une autre idée: https://www.drupal.org/https-information

Donc, je pense qu'ils veulent dire que leur code remplace ceci dans .htaccess

je me demandais si on ne peut pas garder:

RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
   RewriteRule ^ http%{ENV:protossl}://%1%{REQUEST_URI} [L,R=301]

En modifiant protossl  comme ceci:

{ENV:protossl:s}

Mais si on choisit la solution donnée par la doc de Drupal, est-ce qu'il faut utiliser ce morceau?:
 

# Set "protossl" to "s" if we were accessed via https://.  This is used later
  # if you enable "www." stripping or enforcement, in order to ensure that
  # you don't bounce between http and https.
  RewriteRule ^ - [E=protossl]
  RewriteCond %{HTTPS} on
  RewriteRule ^ - [E=protossl:s]

Je vais demander sur Drupal mais il y a tellement de demandes que ce n'est pas sûr qu'une réponse arrive. Je continue de chercher en tous cas.

Bon je rajoute trois idées qui ne semblent pas insensées lu sur le même lien Drupal que plus haut:

un type a simplement fait ça sur Apache:

#redirect all traffic to https
                RedirectMatch permanent ^(.*)$ https://www.example.com$1

mais ça doit pouvoir se faire dans .htacess?
et il a simplement ajouté dans settings.php: 

 $_SERVER['HTTPS'] = 'on';

un type propose:

# Various rewrite rules.
<IfModule mod_rewrite.c>
  RewriteEngine on

  RewriteCond %{HTTPS} off
  RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

  # Set "protossl" to "s" if we were accessed via https://.  This is used later
  # if you enable "www." stripping or enforcement, in order to ensure that
  # you don't bounce between http and https.
  RewriteRule ^ - [E=protossl]
  RewriteCond %{HTTPS} on
  RewriteRule ^ - [E=protossl:s]

un autre dit que ça c'est plus costaud:

# Redirect to HTTPS
RewriteCond %{HTTPS} off
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Il dit qu'il met ça en fin de fichier au cas où, mais j'imagine que ces lignes ne sont plus nécessaires (la 2e est en conflit en tous cas):

RewriteRule ^ - [E=protossl]
  RewriteCond %{HTTPS} on
  RewriteRule ^ - [E=protossl:s]

Une de ces solutions devrait marcher tout de même.
Merci d'avance de vos bons conseils.