[spip-dev] PHP non parsé dans les squelettes!!!

Salut,

PREMIERE CHOSE: C'est important, ça fait la x-ième fois que je pose la
question et personne ne me répond. Mes codes PHP qui étaient parsés
dans mes squelettes avec la 1.2.1 ne le sont plus dans la 1.3!!! C'est
quoi la bêtise que j'ai faite???

- Je vais essayer de dév une fonction qui permet à un rédacteur (ou
admin) de récupérer son mot de passe si il l'a oublié. Pour ça je vais
essayer de créer un tag #FORMULAIRE_OUBLIE_MDP et les fonctions qui
enverront le mail avec le mdp à l'auteur. Si vous voyez une faille de
sécurité ds ma démarche (genre tt le monde peut reçevoir le mdp d'un
rédacteur) dites le moi tt de suite, histoire que j'évite des mdp qui
se baladent dans la nature.

En fait il est impossible de récupérer le mot de passe depuis la version

cryptée qui est dans la base (sauf en utilisant un utilitaire de crack
de mots de passe, bien sûr ;-)). Le formulaire devrait donc plutôt
mailer une URL contenant un code spécifique permettant ensuite au rédacteur
d'y entrer un nouveau mot de passe.<<

OK. Noté. Je vais réfléchir à ça.

Je crois pas. Si t'as un le Spip de base et ensuite que tu peux
télécharger sur le site de spip des modules compatibles qui te
permettent des trucs plus pointus et que tout le monde n'a pas
forcément besoin, c'est au bénéfice de tous, débutants et
professionnels:

Je suis d'accord avec l'utilité de la modularisation, par contre c'est

quelque chose qui est difficile à réaliser si on ne veut pas restreindre
le champ des possibilités.

Exemple, si on voulait livrer les mots-clés sous forme de module :

[...]<<

Je parlais pas d'éléments aussi complexes mais de petits trucs comme
une fonction pour envoyer l'article à un ami ou qui rajoute des tags
pas franchement utiles à un novice, etc. Pas des gros trucs mais des
petits trucs qui sont "indépendants" (genre ça marche avec un seul
fichier pour pas compliquer le truc).

Il faut donc un code beaucoup plus souple qu'actuellement, avec un ensemble

de procédures permettant à un module de s'accrocher à telle ou telle
fonctionnalité de base (édition dans l'espace privé, affichage dans
l'espace
public, maintenance technique...).

Et, heu, il y a déjà des tonnes de choses à faire....<<

Je sais je sais. Mais je parlais de la modularisation comme un truc
qui peut apporter beaucoup mais qui pour l'instant n'est pas très
utile aux yeux de tous. Pour moi c'est la solution idéale pour éviter
de développer plusieurs spip, chacun de son côté, avec ses fonctions à
soi et qui soit incompatible avec les autres.

Parce que j'ai la nette impression que c'est ce que font certain et au
final on va perdre du temps et complexifier le machin. Si Jean
développe une fonction envoyer_ami et que personne ne le sait. Paul va
faire la même chose et perdre un temps fou. Et pour les annonces de
ces "patchs" je trouve la liste insuffisante, on perd les messages, et
les nouveaux ne vont pas chercher dans les archives.

Voilà, à+

-- Bohwaz

@ Dioxyde.org <dioxyde@free.fr> :

PREMIERE CHOSE: C'est important, ça fait la x-ième fois que je pose la
question et personne ne me répond. Mes codes PHP qui étaient parsés
dans mes squelettes avec la 1.2.1 ne le sont plus dans la 1.3!!! C'est
quoi la bêtise que j'ai faite???

Adresse du site, adresse du squelette ?

faire la même chose et perdre un temps fou. Et pour les annonces de
ces "patchs" je trouve la liste insuffisante, on perd les messages, et
les nouveaux ne vont pas chercher dans les archives.

Il suffirait de nous donner des fichiers à installer dans
http://rezo.net/spip-dev/contrib/ ou que quelqu'un s'occupe de maintenir une
base de connaissances sur spip (cf. les x mails précédents sur le même
thème) suffisamment fiable/ouverte pour être utilisable.

-- Fil