Citation :
Il faut positionner "Autoriser l'édition des annonces" sur "Oui". Modifier l'échéance passe par l'édition.

Citation :
Où ça??? Ca peut servir à d'autres.

Citation :
C'est un passage obligé, dans la partie "case 'newuser':"...

Citation :
Il y a un autre fichier à modifier en hard (pas de template utilisé) : root/include/registerform.php (c'est la première page du formulaire qui s'affiche quand on s'enregistre).

-

EDIT iLuc :

Compte tenu que le membre à choisi de supprimer sont message,
vous trouverez comment bloquer les moteurs fantômes ici

Perso, pour les raisons que tu évoques, j'ai bloqué la possibilité de changer l'adresse mail par le membre lui-même. Les membres habituels savent demander aux administrateurs (enfin, en général) l'éventuel modif d'adresse tandis que les membres occasionnels se réinscrivent sous un autre pseudo (c'est ce que j'ai pu constater).

Pour les mails qui ne fonctionnent plus lors de l'envoi d'une news, j'invalide juste "envoi de mail par les admin" dans le profil sans supprimer le compte.

Up ???

Citation :
Cette image est-elle sur ton propre hébergement ou sur un serveur distant ?

Le problème était connu avec FPDF (la fonction plante dès qu'il y a une image externe à ton propre site), je ne vois aucune raison pour laquelle cela aurait changé avec TCPDF puisque cela n'a strictement rien à voir avec PHP, ou un bout de programme, mais cela fait intervenir les systèmes anti-intrusions de tout serveur un tant soit peu protégé ... et sauf à ouvrir une porte béante aux hackers de tout poil, je ne conçois guère de solution miracle avec les images non hébergées chez toi directement.

Perso, je n'évoluerais pas vers la 1.56 , ne serait-ce qu'en raison de ce changement de librairie PDF, alors que FPDF était une sorte de standard (tous les modules actuels qui proposent du PDF utilisent FPDF) sur Xoops jusqu'à présent. Il y avait moyen de faire une Class standard pour Xoops avec FPDF et de simplifier la vie à tout le monde, mais d'autres orientations semblent prises, histoire de bien compliquer les choses et de ne rien faire avancer.

Jef_déçu

Voilà mon petit souci : j'ai inséré un bouton du type "UserPage" (du module du même nom... ) dans la barre de boutons du Forum NewBB 2 (v 1.16a actuellement sur mon site). Le but du jeu est de lier un membre à sa page personnelle du module UserPage comme il existe déjà des liens vers www, mail, mp, msn, yahoo, ... etc.

Ce n'est pas l'insertion de ce bouton (ou lien) qui me pose un souci, mais l'optimisation de la requête car, pour l'heure, j'utilise la fonction de recherche du module. Ce n'est certainement pas l'idéal et il doit y avoir mieux à faire.

Voici le code ajouté dans la fonction getUserBar (à la fin du fichier /modules/newbb/language/french/main.php : il faut déjà le trouver le point d'entrée... :-o ) :

Ca fonctionne, le souci n'est pas là, je le répète, mais AMHA, une bonne requête SQL bien sentie devrait nettement diminuer la consommation de ressources qu'en utilisant la fonction de recherche du module. Et c'est là où mes connaissances s'arrêtent (je suis nul en SQL)...

Aussi, un peu d'aide, SVP.


ps: résultats visibles ici http://www.aquaportail.com/topic-1370 ... page-perso-mini-blog.html (voir dans la barre des "boutons")

Je viens d'envoyer une pré-version pour test à Burning d'un nouveau module qui reprend les indications de ce sujet.

On va voir s'il y a encore beaucoup de travail et si ça fonctionne.

Citation :
Je vais essayer de recoder cela pour une page 'racine' avec un fichier inclus (la bibliothèque de reconnaissance des robots). Malgré tout, cela impose de modifier le fichier /modules/systems/blocks/system_blocks.php

A noter que j'en profite pour filtrer (via htaccess) près de 400 robots, aspirateurs de site, logiciels de récup d'adresses mails, etc... Il y en a marre de ces voleurs de bande-passante!