[Résolu] Application Drupal 7 et sqlite locale **relogeable**

Information importante

En raison d'un grand nombre d'inscriptions de spammers sur notre site, polluant sans relache notre forum, nous suspendons la création de compte via le formulaire de "sign up".

Il est néanmoins toujours possible de devenir adhérent•e en faisant la demande sur cette page, rubrique "Inscription" : https://www.drupal.fr/contact


De plus, le forum est désormais "interdit en écriture". Il n'est plus autorisé d'y écrire un sujet/billet/commentaire.

Pour contacter la communauté, merci de rejoindre le slack "drupalfrance".

Si vous voulez contacter le bureau de l'association, utilisez le formulaire disponible ici, ou envoyez-nous un DM sur twitter.

Bonjour à tous,

Je m'intéresse depuis quelques temps à Drupal pour des sites de tailles
petite à moyenne.
Ce qui m'a conduit vers Drupal par rapport à d'autres CMS est :

  • d'une part son aspect (réputé de) quasi Framework,
  • d'autre part le support de sqlite (donc je pars sur Drupal 7 même s'il
    elle n'est pas encore finale),

J'ai acheté et commencé à lire le livre de Yoann Brault :
"Concevoir et déployer ses sites web avec Drupal 2e édition"
que je trouve très bien conçu mais qui ne répond pas (encore, car je n'ai
pas tout lu) à ma question.

Avant de choisir d'utiliser effectivement Drupal, je voudrais m'assurer
que je pourrai facilement (i.e. fréquemment, automatiquement, ...)
passer d'une version de travail locale à une version de production distante
à l'aide de rsync (entre macosx et linux).
Je fais cela pour d'autres applis php/sqlite (100% mimine, sans framework)
et ça marche très bien.

Pour fixer les idées, imaginer une petite appli web de démo (e.g celle du
livre ci-dessus par exemple) contenant directement des données en sqlite,
qu'on puisse simplement télécharger, décompresser et exécuter sur son serveur
local, et cela quelque soit le répertoire d'installation !
Mais on peut aussi imaginer une petite appli du style wiki perso, gestionnaire
de bookmark amélioré, ou simplement la version test (en sqlite) d'une appli
dont la production sera sous mysql...

Bref, la question est : comment rendre une application drupal 7 sous sqlite
relogeable.

Je sais qu'il y a des histoires de cache, mais je suppose que ça doit
bien pouvoir se configurer, par exemple dans une base sqlite séparée pour
pouvoir s'en débarrasser facilement.
J'aimerais bien que tous les chemins soient enregistrée de manière relative
en base.
C'est possible ?

Sinon, comment modifier la base pour supprimer ou mettre à jour ces chemins ?

Je peux accepter de faire une action après un déplacement (de préférence en php
à l'aide d'une url spécifique de l'appli Drupal).
C'est faisable ?

Merci d'avance !
-- Maurice

Version de Drupal : 

Tous les chemins sont stockés de manière relative, donc pas de problème de ce point de vue là. Le mieux serait de quand même vider les caches pour plus de sécurité (avec drush cc all).

Par contre, je ne suis pas 100% certain que faire un rsync d'une base soit 100% supporté. Il est pas impossible que si la base distante est en cours d'écriture lors du rsync, il n'est pas impossible que celui-ci resulte en une base inconsistente. Probablement pas un problème pour de petits sites, mais gardez cela à l'esprit (je ne suis pas le seul à avoir ces inquiétudes: http://serverfault.com/questions/89329/rsync-sqlite-database).

Merci Damien pour cette réponse rapide.

Effectivement, par un grep sur le dump de la base sqlite, je n'ai pas vu de
chemins absolus de fichiers, mais il y a des url absolues mémorisées (par exemple
dans les tables watchdog, locales_source)

Ensuite si je déplace l'appli drupal (drupal-7.0-beta2 actuellement) dans
un sous répertoire (/sub), l'accès à l'appli donne l'erreur suivante :

Fatal error: require_once(): Failed opening required '/select.inc'
(include_path='.:/Applications/MAMP/bin/php5.3/lib/php') in
/big/.../public_html/.../drupal-7.0-beta2/includes/database/database.inc
on line 2180 Call Stack: ...

Je ne connaissais par drush (outil ligne de commandes pour piloter toute
version de Drupal : excellent, merci !)
Mais ça ne résoud pas le problème : les sources sont encore recherchées dans
leur répertoire de première installation.

Ensuite, à propos de ta remarque sur sqlite je suis d'accord, sauf que
dans mon cas, si je veux mirrorer une base sqlite :

  • soit la base source n'est pas modifiée pendant le rsync car je suis
    le seul utilisateur

  • soit c'est pour un backup d'une base sqlite en production vers ma
    machine locale. Dans ce cas, je fais toujours deux rsync de suite,
    et je considère le backup fait quand le rsync me dit qu'il n'y a pas
    eu de changement par rapport à la version précédente.

  • ensuite pour un (petit) site en production, le code de l'appli php
    (dont la référence est ma version locale que je pousse de temps en
    temps en production) est séparée de la base de données sqlite (dont
    la référence est celle qui est sur le serveur en production).
    Le répertoire php de l'appli contient non pas la base sqlite, mais
    un lien (vers un lien) sur la base de données du site.

    De cette manière, mon appli php de travail est exactement la même que
    celle en production, et mes manipulations se résument à peu près à deux
    rsync différents suivant que c'est pour une mise en production de
    l'appli php ou un backup des données sqlites.

Voilà, c'est pour cela que j'aimerais bien intégrer Drupal dans ce mode
de travail (sous forme d'une petite appli test dans un premier temps).
C'est aussi pour cela que je pose cette question maintenant, car je
voudrais essayer de valider ce principe pendant ces prochaines vacances
de Noël ;-)
Sinon, mes tests sur Drupal vont être reportés de plusieurs mois (webmaster
n'est pas ma fonction principale !)

Merci encore pour votre patience.

-- Maurice

Ca y-est !

Damien, d'après ta remarque, une appli Drupal est censée être relogeable par défaut.
J'ai donc continué à chercher. Et puis je me suis aperçu que quand mon appli test
(et sa base sqlite) était déplacée sur une autre serveur ça fonctionne...
...Mais le problème réapparait après un déplacement sur le même serveur.

Du coup j'ai commencé à regarder les caches de ces serveurs.
Il se trouve que les deux machines sont des macs sur lesquels j'ai récemment upgradé
les serveurs MAMP vers leur dernière version qui proposait un cache par défaut.

C'était la cause de mes problèmes : il fallait désactiver le cache coté serveur web.
Depuis tout semble être rentré dans l'ordre.

Donc merci Damien : problème réglé !
-- Maurice