Bonjour,
Est-ce que la dernière version de Spip est compatible avec la position par défaut à Off de register_globals dans php.ini ?
Merci d’avance pour vos réponses,
Amicalement,
David
Salut Magali,
Est-ce que la dernière version de Spip est compatible avec la position par
défaut à Off de register_globals dans php.ini ?
Oui, depuis longtemps 
Amicalement,
David
De rien
Josiane.
Bonjour à tous !
Travaillant actuellement sur un projet de framework basé notamment sur Spip, nous allons intégrer une couche d'abstraction de bases de données, permettant dans un premier temps le fonctionnement de Spip avec les BDs MySQL, Postgre et Oracle.
Ce sujet a certes été déjà largement abordé dans un thread de cette même liste (consultable depuis les archives à l'URL http://listes.rezo.net/archives/spip-dev/2002-11/msg00040.html), mais les discussions se sont arrêtées sans avoir permis de dégager de réelles pistes...
Voici donc la solution que nous allons mettre en place, en espérant qu'un maximum de ces développements puissent être intégrés à Spip :
- Mise en place d'une première couche d'abstraction, permettant la connexion, exécution de requêtes au travers d'une API unifiée vers les différents types de bases de données.
- Une seconde couche d'abstraction, de plus haut niveau, présentant une API figée de requêtage spécifique à Spip, permettant d'extraire du code de Spip l'ensemble des requêtes SQL, et donc de se dédouaner à ce niveau également de la spécificité des différentes bases. Cette idée a aussi été évoquée sur spip-dev il y a quelques temps, dans le même thread de messages que celui référencé par l'URL citée plus haut.
- Modification du code Spip pour remplacer l'ensembles des spip_query("tartonpion_sql_gnagna"); par des appels à la couche de requêtage haut niveau.
En ce qui concerne la première couche d'abstraction, nous utiliserons PEAR::DB.
Certes cette librairie n'est pas compatible PHP3, et ne pourra donc sûrement pas être intégrée à Spip.
Cependant, l'utilisation de la seconde couche d'abstraction (au niveau requête) rendra le code de Spip naturellement indépendant de la base de données utilisée. Ainsi, cette dernière pourrait tout de même être intégrée à Spip, au prix de la réécriture des implémentations des différentes fonctions de cette couche pour :
1. Cas le plus simple, attaquer directement MySQL depuis cette couche (pas d'utilisation du tout d'une couche d'abstraction de BD)
2. Se greffer sur une autre couche d'abstraction de bases de données, compatible PHP3, et donc intégrable également à Spip
Si vous êtes intéressés pour nous aider à définir des règles permettant l'intégration dans Spip de telles couches, vos remarques / critiques / propositions sont toutes les bienvenues, surtout si elles viennent rapidement!
Antoine.
Travaillant actuellement sur un projet de framework basé notamment sur
Spip
Peux-tu donner des précisions ?
nous allons intégrer une couche d'abstraction de bases de données,
permettant dans un premier temps le fonctionnement de Spip avec les BDs
MySQL, Postgre et Oracle.
Je me méfie des "couches d'abstraction", car je crains que ça n'ajoute
encore un étage au niveau d'exigence requis pour programmer SPIP. Ni ARNO ni
moi ne sommes informaticiens, et on rame parfois comme des bêtes
Une méthode qui aurait ma préférence, et qui permettrait de conserver la
compatibilité php3 (pour MySQL) et le code actuel, serait un module qui
analyse (via des regexp) la requête, et la reformule éventuellement pour
d'autres SGBD (ou pour la couche d'abstraction).
C'est dans cet esprit qu'on a déjà remplacé TOUS les appels de fonctions
mysql par des spip_query() et spip_fetch_array() centralisés dans
inc_db_mysql.php3 : il "suffit" de vous brancher à cet endroit et de
traduire les requêtes. Si certaines requêtes posent problème, le signaler et
proposer des alternatives...
(Pour l'internationalisation, on a suivi ce genre de démarche et programmé le
code nécessaire sans dire "il faut passer par gettext", et ça marche)
Il faudra aussi refaire, sans doute, les procédures d'installation, mais
c'est un autre sujet.
-- Fil
Bonsoir,
je me permets de répondre à la place d'Antoine (Angénieux), vu qu'on
bosse ensemble sur le sujet, il pourra compléter ...
Travaillant actuellement sur un projet de framework basé notamment
sur SpipPeux-tu donner des précisions ?
C'est en gros le sujet sur lequel nous revenons régulièrement depuis
des mois, étendre pas mal de fonctionnalités de SPIP pour répondre à
des besoins souvent rencontrés auquel il ne répond pas pour l'instant.
Par exemple :
- multibase
- multirubricage
- personnalisation
- newsletters
- agenda
- sondages
- ...
Nous reverserons tant que possible un maximum de ces développements à
la "communauté", en espérant en voir une bonne partie intégrée, donc
nous préférons comme d'habitude en parler avant de partir dans de
mauvaises directions.
nous allons intégrer une couche d'abstraction de bases de données,
Je me méfie des "couches d'abstraction", car je crains que ça
n'ajoute encore un étage au niveau d'exigence requis pour programmer
SPIP. Ni ARNO ni moi ne sommes informaticiens, et on rame parfois
comme des bêtes
L'idée est ici d'intercaler une couche d'abstraction "métier" entre
SPIP et une abstraction plus technique, comme je l'avais déjà proposé
dans le thread indiqué hier par Antoine.
Cela nécessite tout d'abord le développement de cette couche métier,
puis la modification de SPIP pour qu'il l'utilise à la place des
requêtes SQL, qui doivent disparaître.
La couche technique sera pour nous PEAR::DB, puisque nous l'utilisons
comme base technique pour tous les composants du framework, mais il
est envisageable de modifier la couche métier ultérieurement pour
qu'elle utilise d'autres couches techniques comme la PHPLib qui est
compatible PHP3.
Quoi qu'il en soit, il faudra bien un jour oublier PHP3 ...
Une méthode qui aurait ma préférence, et qui permettrait de
conserver la compatibilité php3 (pour MySQL) et le code actuel,
serait un module qui analyse (via des regexp) la requête, et la
reformule éventuellement pour d'autres SGBD (ou pour la couche
d'abstraction).
Beurk, pas "beau", et impossible à maintenir.
Il y a un premier problème au niveau des types de données, et il faut
de plus virer les spécificités MySQL telles que (non exhaustivement)
les AUTO_INCREMENT, REPLACE, LIMIT ...
C'est dans cet esprit qu'on a déjà remplacé TOUS les appels de
fonctions mysql par des spip_query() et spip_fetch_array()
centralisés dans inc_db_mysql.php3 : il "suffit" de vous brancher à
cet endroit et de traduire les requêtes. Si certaines requêtes
posent problème, le signaler et proposer des alternatives...
Tu fais bien de mettre le "suffit" entre guillemets, c'est loin d'être
aussi simple que ce que nous proposons.
Il faudra aussi refaire, sans doute, les procédures d'installation,
mais c'est un autre sujet.
Ce sera fait ultérieurement, en effet, cela risque d'être plutôt
complexe, et c'est moins nécessaire pour l'instant ...
-Nicolas
Bonjour à tous,
J’ai besoin de renvoyer un lien vers un article de mon site qui a une autre carte graphique et qui se nomme article2.
Ca doit être tout bête mais je n’y arrive pas 
Est-ce que quelqu’un pourrait m’aider ?
En vous remerciant,
Laurence
http://www.avoir-alire.com