je suis en train d'essayer CFG multi sur un site en SPIP 2.0.10. Je me rends compte d'un souci avec les liens multi. En effet, le code généré dans la colonne de gauche fait référence à des images dont l'URL relative est du type '../dist/images/triangle.gif'.
Or, avec la réorganisation des fichiers en SPIP 2, ces images ne sont plus accessibles puisqu'elles sont situées dans prive/images.
Par ailleurs, liens_multi produit un formulaire pour afficher le formulaire multi avec le bon cfg_id. Seuls petit souci, cela induit l'affichage d'une URL du type monsitespip.net/ecrire/.
je suis en train d'essayer CFG multi sur un site en SPIP 2.0.10. Je me
rends compte d'un souci avec les liens multi. En effet, le code généré
dans la colonne de gauche fait référence à des images dont l'URL
relative est du type '../dist/images/triangle.gif'.
Ah, oui, effectivement. Il faut mettre find_in_path('images/triangle.gif') par exemple. Pareil pour le créer en dessous.
Par ailleurs, liens_multi produit un formulaire pour afficher le
formulaire multi avec le bon cfg_id. Seuls petit souci, cela induit
l'affichage d'une URL du type monsitespip.net/ecrire/.
Il suffit de mettre le formulaire en methode GET et pas en POST.
J'attends vos éventuels retours avant de faire un commit.
Par contre, je préviens, mais... si un jour quelqu'un a le temps et le courage de s'attaquer à CFG2... j'ai déjà botté cette fonctionnalité en touche. Ça ajoute une complexité à CFG pour une utilisation très faible de cas, alors que depuis longtemps on peut creer des formulaires CFG/CVT qui fonctionnent n'importe où, public ou privé. Dans CFG2, cette fonctionnalité est passé dans une extension «compat». Si tu modifies cfg/inc/cfg.php, essaie aussi de reporter dans cfg2/extensions/compat/inc/cfg.php.
Ce chantier de CFG2 est toujours ouvert : beaucoup de simplifications et réorganisations. Il faudrait trouver un lieu de stockage plus adapté car stocker en vrac dans spip_meta par défaut ne convient pas à tout le monde.
Au passage, j'ai remarqué un petit souci avec #CFG_ARBO qui affiche les résultats en iso-8859-1 quelque soit le charset du site.
J'ai donc ajouté le charset du site comme paramètre passé à htmlentities.
Le 28 janv. 10 à 10:56, Matthieu Marcillaud a écrit :
Il faudrait trouver un lieu de stockage plus adapté car stocker en
vrac dans spip_meta par défaut ne convient pas à tout le monde.
D'accord, mais quels sont les éléments qui plaident contre le stockage
actuel ?
Si je comprends bien les propos d'Emmanuel, l'absence de séparation des métas propre à SPIP et propres à celles des plugins dans SPIP meta le gène car
- de nombreuses données y sont sérialisées et pas facile d'accès du coup
- le tableau en mémoire dans $GLOBALS['meta'] ne cesse de s'accroitre.
Il avait comme suggestion d'ajouter une colonne sur spip_meta pour obtenir
[nom] [valeur] [type] où type serait soit vide (SPIP) soit contiendrait une clé désignant le plugin en question.
D'autres possibilités existent certainement, comme créer une seconde table pour stocker ces données de configuration.
Le 28 janv. 10 à 13:10, Matthieu Marcillaud a écrit :
On 28/01/2010 11:06, Pierre Fiches wrote:
Le 28 janv. 10 à 10:56, Matthieu Marcillaud a écrit :
Il faudrait trouver un lieu de stockage plus adapté car stocker en
vrac dans spip_meta par défaut ne convient pas à tout le monde.
D'accord, mais quels sont les éléments qui plaident contre le stockage
actuel ?
Si je comprends bien les propos d'Emmanuel, l'absence de séparation des métas propre à SPIP et propres à celles des plugins dans SPIP meta le gène car
- de nombreuses données y sont sérialisées et pas facile d'accès du coup
- le tableau en mémoire dans $GLOBALS['meta'] ne cesse de s'accroitre.
Il avait comme suggestion d'ajouter une colonne sur spip_meta pour obtenir
[nom] [valeur] [type] où type serait soit vide (SPIP) soit contiendrait une clé désignant le plugin en question.
D'autres possibilités existent certainement, comme créer une seconde table pour stocker ces données de configuration.
J'aurais bien du mal à fournir une proposition techniquement argumenté, mais puisqu'il faut changer quelque chose autant le faire avant que la sortie de la v2.1, non.