Duplication de site

Général
1

Bonsoir,

J'ai pris la charge de faire évoluer le site d'une asso réalisé avec spip, version 3.0.25.

Je ne connais absolument pas spip, mais j'ai développé quelques sites en PHP.

Avant de faire faire évoluer le site en ligne, je veux le dupliquer en local sur ma machine afin de faire les tests localement et ne pas casser le site officiel.

J'ai consulter pas mal de pages sur le net.

J'ai donc fait les manips suivantes :

  * Purger le cache du site officiel
  * Copier par ftp l'ensemble des fichiers et répertoires du site officiel.
  * Via phpmyadmin (oui, c'est sur une base Mysql), fait une sauvegarde
    de la base
  * Sur ma machine local, debian 8 Jessie, installer spip. La version
    est 3.0.17.
  * J'ai importé la base sauvegarde dans mon Mysql local.
  * Modifier apache2 en local pour pointer sur le répertoire copié du
    site officiel
  * Supprimer le fichier config/connect.php, .htaccess et config/.htaccess.
  * Via mon navigateur, j'ai accéder à la page
    http://localhost/monsitelocal/ecrire/
  * J'ai suivi la procédure habituel.
  * Sur mon navigateur, j'accède donc à mon site local
    http://localhosts/monsitelocal/

Et là j'ai une message d'erreur donc je ne comprends pas la teneur, d'où mon besoin d'aide.

Le message est le suivant :

Les articles constitutifs de la page d'accueil de ce site. (cette page est affichée selon un modèle de mise en page singulier utilisant des pavés).

Bien sur, j'ai cherché sur le net, mais pas trouvé grand chose, sinon d'autres sites qui affichent exactement ce message.

Si vous pouvez éclairer ma lanterne, merci.

Merci de me répondre directement, je ne suis pas abonné à la liste.

Cordialement,

Jose Charters

2

Bonjour

Je ne comprends pas : vous avez récupéré tous les fichiers du site en version 3.0.25 puis installé un spip en 3.0.17 ?
Normalement le fait de récupérer les répertoires et d’importer le dump sql suffisait. Il y avait juste à indiquer les bonnes infos pour la connexion à la base dans config/connect.php.
Supprimer les htaccess n’était pas forcément nécessaire non plus : si la réécriture d’urls est utilisée ça va coincer.

Si vous allez dans configuration /plugins il n’y a aucun message d’erreur ? La liste des plugins activés est-elle la même en local que sur le site en ligne ?

Je ne sais pas à quoi correspond le message que vous indiquez, c’est certainement lié au squelette utilisé.

Il faut également penser à modifier l’url dans configuration/Identité du site.

pw

3

N’y aurait-il pas un problème de version Spip ? Le site réel est en 3.0.25 et sur le site local c’est du 3.0.17. Il faudrait être à la même version déjà !

De : Jose CHARTERS [mailto:jose.charters@free.fr]
Envoyé : jeudi 24 août 2017 20:31
À : spip@rezo.net
Objet : [Spip] Duplication de site

Bonsoir,

J’ai pris la charge de faire évoluer le site d’une asso réalisé avec spip, version 3.0.25.

Je ne connais absolument pas spip, mais j’ai développé quelques sites en PHP.

Avant de faire faire évoluer le site en ligne, je veux le dupliquer en local sur ma machine afin de faire les tests localement et ne pas casser le site officiel.

J’ai consulter pas mal de pages sur le net.

J’ai donc fait les manips suivantes :

  • Purger le cache du site officiel
  • Copier par ftp l’ensemble des fichiers et répertoires du site officiel.
  • Via phpmyadmin (oui, c’est sur une base Mysql), fait une sauvegarde de la base
  • Sur ma machine local, debian 8 Jessie, installer spip. La version est 3.0.17.
  • J’ai importé la base sauvegarde dans mon Mysql local.
  • Modifier apache2 en local pour pointer sur le répertoire copié du site officiel
  • Supprimer le fichier config/connect.php, .htaccess et config/.htaccess.
  • Via mon navigateur, j’ai accéder à la page http://localhost/monsitelocal/ecrire/
  • J’ai suivi la procédure habituel.
  • Sur mon navigateur, j’accède donc à mon site local http://localhosts/monsitelocal/

Et là j’ai une message d’erreur donc je ne comprends pas la teneur, d’où mon besoin d’aide.

Le message est le suivant :

`Les articles constitutifs de la page d'accueil de ce site. (cette `

`page est affichée selon un modèle de mise en page singulier utilisant `

`des pavés).`

Bien sur, j’ai cherché sur le net, mais pas trouvé grand chose, sinon d’autres sites qui affichent exactement ce message.

Si vous pouvez éclairer ma lanterne, merci.

Merci de me répondre directement, je ne suis pas abonné à la liste.

Cordialement,

Jose Charters

4

Le 25/08/2017 à 07:56, p.weber@free.fr a écrit :

Bonjour

Je ne comprends pas : vous avez récupéré tous les fichiers du site en version 3.0.25 puis installé un spip en 3.0.17 ?

Bonjour,

Oui, je comprends bien votre question. Je suis sur Debian et la version Debian Jessie est la 3.0.17. De mes connaissances à travers divers logiciels, les différences de versions mineures devraient rester compatible. C'est pourquoi à priori, cela ne me choquait pas plus que cela. Peut être que SPIP agit différemment.

Normalement le fait de récupérer les répertoires et d'importer le dump sql suffisait. Il y avait juste à indiquer les bonnes infos pour la connexion à la base dans config/connect.php.

Oui, c'est ce que je lis sur le net depuis 3 semaines. Mais chez moi, cela ne suffit apparemment pas.

Supprimer les htaccess n'était pas forcément nécessaire non plus : si la réécriture d'urls est utilisée ça va coincer.

OK, je vais essayer en remettant les fichiers htaccess.

Si vous allez dans configuration /plugins il n'y a aucun message d'erreur ? La liste des plugins activés est-elle la même en local que sur le site en ligne ?

Je pense qu'il est possible qu'il y ait des plugins, mais je n'en sais rien. La société qui a développé le site, ne fournit aucune information.

Je ne sais pas à quoi correspond le message que vous indiquez, c'est certainement lié au squelette utilisé.

Ça c'est sûr, de ce que j'ai compris.

Il faut également penser à modifier l'url dans configuration/Identité du site.

C'est une possibilité. J'ai essayé de voir où cela pouvait être configurer, mais je n'ai pas trouvé d'infos en ce sens.

Quelles sont les paramètres à configurer pour cela et dans quels fichiers ?

Merci.

Cordialement,

José Charters

5

Bonjour,

Oui, je comprends bien votre question. Je suis sur Debian et la version Debian Jessie est la 3.0.17. De mes connaissances à travers divers logiciels, les différences de versions mineures devraient rester compatible. C'est pourquoi à priori, cela ne me choquait pas plus que cela. Peut être que SPIP agit différemment.

Euh, il existe une compatibilité ascendante, l'inverse est risqué. Pour ma part, comme les colistiers, j'aurais récupéré le spip, base et fichiers et aurais tout simplement zappé la version packagée par debian.

En cas d'import d'une ancienne base sur un spip récent, le schéma de la base de donnée sera adapté si nécessaire par SPIP. Dans le cas inverse, par contre, non... C'est donc a éviter.
Donc je recommande chaudement de faire ce qui est préconisé par PW : récupérer tous les fichiers et ne modifier que les infos de connexion à mysql pour faire tourner le tout sur le serveur local.

Ça c'est sûr, de ce que j'ai compris.

En faisant une recherche rapide, avec l'expression : "Les articles constitutifs de la page d'accueil de ce site. (cette page est affichée selon un modèle de mise en page singulier utilisant des pavés)."
Je tombe sur des sites faits avec le jeu de squelettes eva : Le projet EVA - SPIP-Contrib
Cela pourrait être une piste à creuser pour voir comment marche le moulin ?

6

Le 26/08/2017 à 19:40, Vincent a écrit :

Bonjour,

Oui, je comprends bien votre question. Je suis sur Debian et la version Debian Jessie est la 3.0.17. De mes connaissances à travers divers logiciels, les différences de versions mineures devraient rester compatible. C'est pourquoi à priori, cela ne me choquait pas plus que cela. Peut être que SPIP agit différemment.

Euh, il existe une compatibilité ascendante, l'inverse est risqué. Pour ma part, comme les colistiers, j'aurais récupéré le spip, base et fichiers et aurais tout simplement zappé la version packagée par debian.

Bonsoir,

Merci de ces précisions.

En creusant le fonctionnement de SPIP, je me suis demandé où se trouvait les fichiers de bases de SPIP ? La réponse bien sûr, ils sont dans le répertoire courant du site. Hors, J'ai récupéré tout le répertoire du site, donc logiquement, j'ai récupéré également tous les fichiers SPIP dans la version du site.

Pour m'en assurer, j'ai supprimer la version Debian de SPIP. Mon apache pointe sur le répertoire récupéré. J'ai toujours accès à la page comme avant. Donc je suis bien dans la version SPIP du site.

En faisant une recherche rapide, avec l'expression : "Les articles constitutifs de la page d'accueil de ce site. (cette page est affichée selon un modèle de mise en page singulier utilisant des pavés)."
Je tombe sur des sites faits avec le jeu de squelettes eva : Le projet EVA - SPIP-Contrib
Cela pourrait être une piste à creuser pour voir comment marche le moulin ?

Chose curieuse, j'ai maintenant bien accès à la page d'accueil sur mon installation locale. Je ne sais pas ce qui s'est passé, mais je n'ai plus le message dont je vous ai parlé. Bon.

Par contre, j'ai un soucis. La page d'accueil s'affiche bien saut le menu de navigation qui est sous le logo. J'ai creusé, mais je ne trouve pas la raison.

Je suppose que ce doit être un problème d'un paramétrage de apache, ou d'une variable SPIP. J'ai plongé dans le code de SPIP, mais je m'y perds un peu pour l'instant. Quelqu'un a-t-il une piste ?

Cordialement,

José

7

Le 30.08.17 à 22:04, Jose CHARTERS a écrit :

Le 26/08/2017 à 19:40, Vincent a écrit :

Bonjour,

Oui, je comprends bien votre question. Je suis sur Debian et la version Debian Jessie est la 3.0.17. De mes connaissances à travers divers logiciels, les différences de versions mineures devraient rester compatible. C'est pourquoi à priori, cela ne me choquait pas plus que cela. Peut être que SPIP agit différemment.

Euh, il existe une compatibilité ascendante, l'inverse est risqué. Pour ma part, comme les colistiers, j'aurais récupéré le spip, base et fichiers et aurais tout simplement zappé la version packagée par debian.

Bonsoir,

Merci de ces précisions.

En creusant le fonctionnement de SPIP, je me suis demandé où se trouvait les fichiers de bases de SPIP ? La réponse bien sûr, ils sont dans le répertoire courant du site. Hors, J'ai récupéré tout le répertoire du site, donc logiquement, j'ai récupéré également tous les fichiers SPIP dans la version du site.

Pour m'en assurer, j'ai supprimer la version Debian de SPIP. Mon apache pointe sur le répertoire récupéré. J'ai toujours accès à la page comme avant. Donc je suis bien dans la version SPIP du site.

En faisant une recherche rapide, avec l'expression : "Les articles constitutifs de la page d'accueil de ce site. (cette page est affichée selon un modèle de mise en page singulier utilisant des pavés)."
Je tombe sur des sites faits avec le jeu de squelettes eva : Le projet EVA - SPIP-Contrib
Cela pourrait être une piste à creuser pour voir comment marche le moulin ?

Chose curieuse, j'ai maintenant bien accès à la page d'accueil sur mon installation locale. Je ne sais pas ce qui s'est passé, mais je n'ai plus le message dont je vous ai parlé. Bon.

Par contre, j'ai un soucis. La page d'accueil s'affiche bien saut le menu de navigation qui est sous le logo. J'ai creusé, mais je ne trouve pas la raison.

Je suppose que ce doit être un problème d'un paramétrage de apache, ou d'une variable SPIP. J'ai plongé dans le code de SPIP, mais je m'y perds un peu pour l'instant. Quelqu'un a-t-il une piste ?

Cordialement,

José

peut être des plugins non activés? Je ne sais pas quel squelette vous utilisez, mais certains ont besoin du plugoin "menus" pour gérer les menus.

--
Maïeul

8

Le 31/08/2017 à 11:00, Maïeul a écrit :

peut être des plugins non activés? Je ne sais pas quel squelette vous utilisez, mais certains ont besoin du plugoin "menus" pour gérer les menus.

Bonsoir,

Si je comprends bien la structure de SPIP, les plugins se trouvent dans le répertoire plugins.

Je le répète, j'ai récupéré tout le répertoire qui est en ligne. J'ai donc dû récupérer également tout le répertoire plugins.

Par acquis de conscience, je vérifie ce répertoire dans mon répertoire local et celui sur le site. Surprise. Il n'a pas du tout été recopié ???!!!!???

Bon, je le recopie.

J'ai mon menu. Ouf. OK, sauf qu'il n'est pas du tout présenté comme il devrait, sûrement un problème de css. J'ai vu un mail avec un problème de css.

Je cherche à naviguer un peu et je clique sur un des menus. Je n'ai pas accès à la page. L'URL m'indique un fichier qui n'existe pas ??? Est ce un problème d'accès à la base ? Un soucis de génération des pages ? Une mauvaise configuration d'apache ?

Merci de toute aide.

Cordialement,

José

9

Bonsoir,

Si je comprends bien la structure de SPIP, les plugins se trouvent dans le répertoire plugins.

Oui, plugins et plugins/auto pour activer le téléchargement automatique de mémoire. Ceci dit, un plugin peut être présent mais non actif: il peut être activé ou désactivé sur l'interface d'administration...
Un plugin qui n'est plus présent sera d'ailleurs désactivé par spip et devra probablement être réactivé ensuite si l'on remet les fichiers en place, ce qui pourrait être le cas ici.

Par acquis de conscience, je vérifie ce répertoire dans mon répertoire local et celui sur le site. Surprise. Il n'a pas du tout été recopié ???!!!!???

Gag, en effet.

J'ai mon menu. Ouf. OK, sauf qu'il n'est pas du tout présenté comme il devrait, sûrement un problème de css. J'ai vu un mail avec un problème de css.

Non, soit plugin, soit cache je dirais: les css seront assemblées depuis les squelettes et plugins présents. Cela vaudrait le coup par contre de voir quels plugins sont actifs sur les deux sites, et une fois la certitude acquise que les deux sont configurés pareil, de purger le cache, voir de le désactiver le temps des tests.

Je cherche à naviguer un peu et je clique sur un des menus. Je n'ai pas accès à la page. L'URL m'indique un fichier qui n'existe pas ???

A voir selon l'url qui est donnée ...

Est ce un problème d'accès à la base ?

Peu probable.

Un soucis de génération des pages ?

Sauf mauvaise configuration de spip, je ne pense pas.

Une mauvaise configuration d'apache ?

A voir si mod_rewrite est bien activé en cas d'utilisation d'url réécrites, si le vhost contient bien la directive allowoverride:all pour le répertoire de spip, et si le .htaccess est bien présent.
https://httpd.apache.org/docs/2.2/fr/mod/core.html#allowoverride
Un test simple: mettre une chaine aléatoire genre "fkjghkehkje" dans le .htaccess doit provoquer immédiatement une erreur 500 si apache est bien configuré.
Petit rappel au besoin: a2enmod pour activer un module apache sous debian.

10

Bonjour,

lorsqu’on copie un site par duplication des fichiers et clonage de la base de données, la seule opération à faire pour que ça fonctionne à 100% est la mise à jour de l’adresse principale du site dans la configuration (car certains éléments peuvent avoir besoin de cette nouvelle adresse).

Pour être précis je réalise la clonage de la base de données de la manière suivante : export de la base > suppression du fichier connect.php sur le nouveau site / Réinstallation (soit une nouvelle base, soit un nouveau préfixe) > import de la base. Si je fais un export mysql, il faut adapter le fichier pour s’adapter au noueau préfixe. Mais avec une sauvegarde dans l’interface de SPIP je crois qu’on n’a pas ce type de manip à traiter pour la restauration.

Je réalise souvent ce type d’opération dans un sous-dossier du site en production, et je n’ai jamais eu de problème. et cela évite de travailler en local (j’utilise un éditeur avec une synchro ftp qui me permet de travailler à distance comme en local).
Dans le cas d’un sous-répertoire, le fichier .htaccess nécessite une toute petite modification.

Par contre, le fait que tous les éléments n’ont pas été copiés indique qu’il y a un autre problème.

Et tant que vous n’êtes pas certain d’avoir une copie exacte, il peut y avoir des soucis.

Have fun !

.Gilles

11

Bonsoir, Merci pour toutes ces informations. J’ai fait le test simple et cela ne change rien, j’ai toujours ma page avec le menu mal représenté. J’en déduis que mon apache est mal configurer. Pour expliquer ce que j’ai fait, j’ai virer le .htaccess du répertoire principale et du répertoire config. En supposant que lors de la reprise du site en pointant sur répertoire écrire, ces fichiers serait régénérés. Il a bien régénéré le fichier du répertoire config, ce fichier ne contient que deny from all. Par contre, il n’a pas refait celui du répertoire principal. J’ai vu que le fichier .htaccess du répertoire principal du site d’origine est plein d’instruction. Donc cela doit sûrement manquer. Puisque il n’a pas été égénéré, j’ai remis le fichier .htaccess d’origine, cela n’a rien changé. Pour configurer le site, j’ai mis la configuration suivante dans apache : Alias <Directory « /mon/repertore/du/site/local »> Options Indexes FollowSymLinks Require all granted Y a t il une erreur ? Cordialement, José Charters PS : Désolé d’avoir répondu à l’adresse perso plutôt qu’à la liste. Réflexe habituel. Voilà corriger.

12

Le 01/09/2017 à 11:12, Gilles Vincent a écrit :

Bonjour,

lorsqu'on copie un site par duplication des fichiers et clonage de la base de données, la seule opération à faire pour que ça fonctionne à 100% est la mise à jour de l'adresse principale du site dans la configuration (car certains éléments peuvent avoir besoin de cette nouvelle adresse).

Bonsoir,

Merci de ces indications.

Je me doute que j'ai raté quelque chose mais je ne trouve pas. Comment changer cet adresse principale dans la configuration ? Quel paramètre et dans quel fichier ?

J'ai cherché mais pas trouvé quelque chose qui m'indique ce paramètre. J'ai regardé dans .htaccess et dans les fichiers spip_loader.php et spip.php. mais je n'ai pas été inspiré.

Pour être précis je réalise la clonage de la base de données de la manière suivante : export de la base > suppression du fichier connect.php sur le nouveau site / Réinstallation (soit une nouvelle base, soit un nouveau préfixe) > import de la base. Si je fais un export mysql, il faut adapter le fichier pour s'adapter au noueau préfixe. Mais avec une sauvegarde dans l'interface de SPIP je crois qu'on n'a pas ce type de manip à traiter pour la restauration.

C'est bien ce que j'ai fait. Je n'ai pas changer le préfixe. Je ne voulais pas me compliquer la tache et comme c'est sur une nouvelle machine, nouvelle base, je pense qu'il n'y a pas de conflits. Il n'y a pas d'autre utilisation de spip que celle-ci.

Je réalise souvent ce type d'opération dans un sous-dossier du site en production, et je n'ai jamais eu de problème. et cela évite de travailler en local (j'utilise un éditeur avec une synchro ftp qui me permet de travailler à distance comme en local).
Dans le cas d'un sous-répertoire, le fichier .htaccess nécessite une toute petite modification.

Je préfère ne pas polluer le site de production, préférant faire les bêtises en local. Je ne suis pas assez à l'aise avec SPIP pour faire ce type d'opération. Je me dit que travailler en local, je pourrais monter en compétence sans casser ce qui existe.

Par contre, le fait que tous les éléments n'ont pas été copiés indique qu'il y a un autre problème.
Et tant que vous n'êtes pas certain d'avoir une copie exacte, il peut y avoir des soucis.

J'en ai bien conscience.

Cordialement,

José Charters

PS : Désolé d'avoir répondu à l'adresse perso plutôt qu'à la liste. Réflexe habituel. Voilà corriger.

13

2017-09-04 21:45 GMT+02:00 Jose CHARTERS <jose.charters@free.fr>:

Le 01/09/2017 à 11:12, Gilles Vincent a écrit :

Bonjour,

lorsqu'on copie un site par duplication des fichiers et clonage de la
base de données, la seule opération à faire pour que ça fonctionne à 100%
est la mise à jour de l'adresse principale du site dans la configuration
(car certains éléments peuvent avoir besoin de cette nouvelle adresse).

Bonsoir,

Merci de ces indications.

Je me doute que j'ai raté quelque chose mais je ne trouve pas. Comment
changer cet adresse principale dans la configuration ? Quel paramètre et
dans quel fichier ?

Bonjour,

l'adresse principale du site se change lorsque l'on se connecte à l'espace
privé,
Onglet Configuration > Identité du site
Mais il est totalement inutile pour quasi tous les éléments sauf, par
défaut le lien "voir le site" de l'espace privé (à moins que les squelettes
utilisent #URL_SITE_SPIP)

Le message d'erreur "Les articles constitutifs de la page d'accueil de ce
site.." ne provient PAS de spip mais d'un des plugins. Pour éviter cela, il
suffit de renommer dans un premier temps le dossier plugins qui a été
téléchargé (ce qui désactive automatiquement tous les plugins). Le template
utilise certainement ces plugins, donc il faut aussi renommer le dossier
squelettes.

Ensuite, en allant sur l'espace privé, tu peux vérifier que tout fonctionne.

Il ne te reste plus qu'à renommer plugins_sav en plugins pour retrouver la
liste des plugins, puis à les réactiver un par un.
Note bien sur l'ancien site la liste des plugins qui étaient actifs ainsi
que leur réglage, car tu devras reproduire cela sur le nouveau site. Tu
devra aussi refaire une passe sur tous les réglages du site, définis dans
l'onglet "Configuration"

N'oublie pas de renomme le dossier squelettes_sav en squelettes pour
retrouver le design d'origine

.Gilles

14

Le 04/09/2017 à 22:20, Gilles Vincent a écrit :

Bonjour,

l'adresse principale du site se change lorsque l'on se connecte à l'espace privé,
Onglet Configuration > Identité du site
Mais il est totalement inutile pour quasi tous les éléments sauf, par défaut le lien "voir le site" de l'espace privé (à moins que les squelettes utilisent #URL_SITE_SPIP)

Bonsoir,

J’ai fait un grep sur les fichiers SPIP et effectivement je vois bien ce paramètre #URL_SITE_SPIP. Mais je ne vois pas où il est initialisé. J’ai fouillé également dans la base mais pour l’instant, je n’ai pas mis la main dessus.

Le message d'erreur "Les articles constitutifs de la page d'accueil de ce site.." ne provient PAS de spip mais d'un des plugins. Pour éviter cela, il suffit de renommer dans un premier temps le dossier plugins qui a été téléchargé (ce qui désactive automatiquement tous les plugins). Le template utilise certainement ces plugins, donc il faut aussi renommer le dossier squelettes.

Je n’ai plus ce message. Il me semble l’avoir précisé dans un mail précédent. Actuellement, j’ai bien ma page d’accueil qui s’affiche saut que le menu en haut de page n’a pas la mise en forme qu’il devrait avoir et lorsque je clique sur un des menus, j’ai droit à page 404, car la page pointée n’existe pas. Ce qui est vrai. Apparemment, il y a un lien que ne se fait pas.

Ensuite, en allant sur l'espace privé, tu peux vérifier que tout fonctionne.

J’ai oublié de le préciser, mais je n’ai pas accès à mon espace privée. Lorsque je tente de le faire, j’ai un panneau simple qui me dit « Accès Interdit ». Alors que sur le site en prod, j’accède bien à mon espace privée.

Il ne te reste plus qu'à renommer plugins_sav en plugins pour retrouver la liste des plugins, puis à les réactiver un par un.
Note bien sur l'ancien site la liste des plugins qui étaient actifs ainsi que leur réglage, car tu devras reproduire cela sur le nouveau site. Tu devra aussi refaire une passe sur tous les réglages du site, définis dans l'onglet "Configuration"

N'oublie pas de renomme le dossier squelettes_sav en squelettes pour retrouver le design d'origine

Je pense que ce n’est pas un souci de plugin. Mais je peux me tromper.

Cordialement,

José Charters

15

Le 04/09/2017 à 23:08, Vincent a écrit :

Bonsoir,

J'ai fait le test simple et cela ne change rien, j'ai toujours ma page avec le menu mal représenté. J'en déduis que mon apache est mal configurer.

Oui, mod rewrite peut ne pas être activé .
En tant que root:
a2enmod rewrite
servicve apache2 restart
( sinon, dans : /etc/apache2/mods-enabled/ un lien symbolique doit exister vers ../mods-available/rewrite.load )

Cela ne résoudra pas les problèmes de css mais au moins la réécriture d'url marchera. Et effectivement, le .htaccess de la racine n'est pas regénéré et est nécessaire au fonctionnement de pas mal de choses, le réimporter de la prod était une bonne idée.

Bonsoir,

Merci de ces indications.

J’ai fait a2enmod rewrite. J’ai vérifié que le lien dans /etc/apache2/mods-enabled existe bien. Mais cela ne change rien. Je n’ai pas accès aux pages du menu.

Pour configurer le site, j'ai mis la configuration suivante dans apache :

Alias /monsite/ /mon/repertore/du/site/local/
<Directory "/mon/repertore/du/site/local">
    Options Indexes FollowSymLinks
     Require all granted

          AllowOverride All <--- a ajouter pour que le .htaccess marche en + de l'activation de mod rewrite

</Directory>

Idem, j’ai ajouté cette directive dans la configuration apache. Rien ne change.

Cordialement,

José Charters