J’utilise depuis des années Paheko (ex Garradin). Comme je viens d’ouvrir un compte Framaspace, j’aimerai transférer ma comptabilité sur Framaspace.
Malheureusement la restauration sur Framaspace me donne systématiquement un message d’erreur (413 Request Entity Too Large) pourtant ma base sql ne fait que 32,9 Mo, ce qui est inférieur à la taille maximale de 512 Mo.
Que faire ?
Malheureusement, Framaspace ne supporte pas encore officiellement l’import (pour différentes raisons techniques). Ce n’est en rien dû à Paheko lui-même.
Nous travaillons à résoudre des bugs au fur et à mesure. Cf cette actualité qui annonce une mise à jour prévue le 25/02.
Je ne suis pas sûr que cela règle votre problème, il faudra tester. Mais pour l’instant, le plus probable est de partir du principe que vous ne pourrez pas bénéficier de cet import dans l’immédiat.
Ok, merci pour la réponse. On va donc patienter en espérant une résolution heureuse du problème…
Bonjour Serge
Malheureusement, la mise à jour de ce matin ne réglera pas votre problème.
En effet, nous avons choisi spécifiquement de désactiver l’import de base de données sur la version déployée ce matin, et ce pour deux raisons :
- Paheko ne vérifie pas que les versions de Paheko installées sont identiques entre la BDD source et l’endroit de destination, ce qui semble rendre le Paheko complètement inutilisable lorsqu’on arrive avec une version de BDD plus récente que le Paheko installé chez nous.
- il est possible qu’on vienne à mettre en place des paramètres directement dans la BDD initialement, donc les imports de BDD n’auraient pas ces paramètres, qui pourraient alors être écrasés
Conclusion (au moins à court et moyen terme) : l’import d’anciennes bases Paheko n’est pas possible dans Paheko-dans-Framaspace.
Un peu HS, mais le « bon » côté des choses, c’est que ça limitera peut être le nombre de personnes qui voudraient arrêter leurs dons à Paheko pour les reporter sur Framaspace, car les 2 services ont tous les 2 besoins de financements.
1 « J'aime »
Heu je suis pas sûr de ce quoi il est question, mais Paheko vérifie bien sûr avant de faire une restauration que la version de la BDD est gérée par le Paheko installé, sinon ça serait l’enfer tu risquerais de casser ton installation ^^
C’est effectivement le comportement que l’on croit avoir observé, quelqu’un ayant importé une BDD avec une version différente de la version sur Framaspace rendant le Paheko HS. Hélas je n’ai plus le mail en question qui donnait le détail de l’erreur et le nom de l’espace en question pour vérifier.
Mais si tu dis qu’il y a prise en charge, alors le souci est peut-être plutôt que la version de la BDD importée était inférieure, mais que les upgrade de BDD n’ont pas pu se faire, à cause de ENABLE_UPGRADES = false ? Est-ce que ce cas peut correspondre ?
ENABLE_UPGRADES ne change qu’une chose : la possibilité de télécharger une mise à jour du code et l’installer à la place du code existant. Ça ne gère en rien les migrations de base de données (désolé pour le vocabulaire qui peut porter à confusion du coup).
Si la restauration casse quelque chose c’est qu’il y a un souci, mais normalement Paheko vérifie que la BDD est bien une BDD de Paheko, que c’est une version qu’on gère (donc pas une version supérieure, et pas une version < 1.3.0), qu’il n’y a pas de souci d’intégrité ou de foreign keys qui foirent, et ensuite seulement le fichier est copié, mais seulement après que le fichier de BDD original soit renommé, ce qui fait que tu as toujours un backup vers lequel revenir en cas de souci.
On a pas mal de gens qui migrent de/vers Paheko.cloud, et pas de souci constaté récemment. S’il y a un souci, c’est corrigé rapidement bien sûr 
Autre précision : par défaut, quand tu télécharge la BDD via l’interface web, ça rajoute un hash SHA1 de la BDD à la fin : si tu ouvre et modifie le fichier avec un outil externe, ça supprime le hash, ou le rend invalide.
Le défaut depuis la 1.3.13 est de refuser la restauration d’un fichier qui n’a pas de hash valide. C’est pas fait pour sécuriser quoi que ce soit (il suffirait de modifier la BDD avec un outil externe et remettre un hash à la main), mais pour décourager les utilisateurs de modifier la BDD à la main et ensuite se plaindre qu’il y a des bugs (dûs à leurs bidouilles dans la BDD).
Les gens en auto-hébergement peuvent bien sûr désactiver cette vérification et bidouiller comme ils veulent
Mais du coup en théorie tu ne peux pas importer n’importe quel fichier de BDD, il faut forcément que ça soit un fichier généré par Paheko.
J’ai pu retrouver l’accès au log en question grâce à un collègue (désolé pour le formatage) :
Une erreur s'est produite
LogicException
Database version is higher than installed version.
in .../include/*init.php*:/475/
|*471* Utils::redirect(ADMIN_URL . 'upgrade.php'); *472* } *473* *474* if (version_compare($v, paheko_version(), '>')) { _*475* throw new \LogicException('Database version is higher than installed version.');_ *476* } *477* *478* if (Config::getInstance()->timezone) { *479* @date_default_timezone_set(Config::getInstance()->timezone); |
in .../www/admin/*_inc.php*:/7/
→ require_once /(0 arg.)/
|*3*namespace Paheko; *4* *5*use Paheko\Users\Session; *6* _*7*require_once __DIR__ . '/../../include/init.php';_ *8* *9*function f($key) *10*{ *11* return \KD2\Form::get($key); |
in .../www/admin/*login.php*:/15/
→ require_once /(1 arg.)/
0
string(22) ".../www/admin/_inc.php"
|*11*use Paheko\UserException; *12* *13*const LOGIN_PROCESS = true; *14* _*15*require_once __DIR__ . '/_inc.php';_ *16* *17*$app_token = $_GET['app'] ?? null; *18* *19*if ($app_token) { |
On a bien paheko_version 1.3.12 dans le contexte, donc je suppose que que la personne a importé une base de données en version 1.3.13.
Merci du retour, effectivement la vérification de version ne se faisait qu’après restauration dans ce cas, je viens de corriger : Paheko: Check-in [3190552505]
1 « J'aime »