🌍
Français
rub a écrit:
Je n'ai pas encore mis le WIKI mais voila VITE FAIT ce que je veux proposer pour le v1.7.
o Multi-mail
o Mail HTML
o Contenu mail dans tpl
o Inscription NBM lors de l'inscription au site
o Mettre dans mail lien sur nouvelles images, cat. sur la periode choisie
o Pour les lignes x ..., mettre des liens pour accéder directement à la page
o Pouvoir changer le last_send par interface (sur les null ou sur tous, ...)
o Remonter le paramètre (mail HTML, detaillé ou non, contenu full) au user. Si rien défini prendre les valeurs par défault
Mais aussi
o Appliquer des filtres sur l'onglet d'envoi pour reduire la liste et aussi pour ne prendre par exemple que les users d'une certaines langues afin de mettre le contenu personnalisé dans la bonne langue
Sinon:::
Si rvelices (et les autres) aurais-tu une idée/solution, pour executer automatique au chargemementd'une page un bouton "submit" (cesi afin de finir les envois atoppés à cause du timeout).
Oui, tres bonne idée, c'est que j'avais déjà en tête et je me suis posé la même question "comment ne pas afficher à l'écran"!
J'avais pensé à utiliser ob_start, ect... pour récupérer la sortie d'un tpl.
Mais comme tu le dis, il faudrait l'implementer dans l'objet template.
Je n'ai pas encore mis le WIKI mais voila VITE FAIT ce que je veux proposer pour le v1.7.
o Multi-mail
o Mail HTML
o Contenu mail dans tpl
o Inscription NBM lors de l'inscription au site
o Mettre dans mail lien sur nouvelles images, cat. sur la periode choisie
o Pour les lignes x ..., mettre des liens pour accéder directement à la page
o Pouvoir changer le last_send par interface (sur les null ou sur tous, ...)
o Remonter le paramètre (mail HTML, detaillé ou non, contenu full) au user. Si rien défini prendre les valeurs par défault
Mais, je ferais un truc plus clair bientôt et j'attend vos retours pour la v1.7...
Je viens de penser a un truc. Peut-etre pour la version 1.7.
Ca serait sympa que le contenu du mail envoye soit defini dans un template (comme ca on peux faire ce qu'on veut dedans). Ca va peut-etre demander de modifier un peu le code des templates pour que la sortie ne soit pas envoye a l'ecran mais qu'on puisse la recuperer.
Pour contrer le time-out sur l'envoi de mails (par l'exemple l'antivirus qui ralentit l'envoi, ect.), j'ai une solution à proposer.
En fait, il s'agit simplement de faire les envois par paquets de $_POST.
C'est à que dire qu'à chaques $_POST on fait des envois pendant x secondes ou par x envois. Et une fois, qu'on a dépassé le nombre x, on refait un envoi post à la même page pour continuer... et ainsi de suite...
Et ainsi de suite, jusqu'à la fin.
Pour mettre ca en place,il suffit de faire un envoi post invible en faisant un truc du style:
<?php
if (isset($_POST) and (count($_POST) != 0))
{
//print_r($_POST);
//$data = 'txt1='.urlencode($txt1).'&txt2='.urlencode($txt2).'&id='.$id_session;
function _HTTPRequestToString($arr_request, $var_name, $separator='&') {
$ret = "";
if (is_array($arr_request)) {
foreach ($arr_request as $key => $value) {
if (is_array($value)) {
if ($var_name) {
$ret .= _HTTPRequestToString($value, "{$var_name}[{$key}]", $separator);
} else {
$ret .= _HTTPRequestToString($value, "{$key}", $separator);
}
} else {
if ($var_name) {
$ret .= "{$var_name}[{$key}]=".urlencode($value)."&";
} else {
$ret .= "{$key}=".urlencode($value)."&";
}
}
}
}
if (!$var_name) {
$ret = substr($ret,0,-1);
}
return $ret;
}
// Les données envoyées en POST sous forme d'url
$data = _HTTPRequestToString($_POST, '');
// monfichier.php3 est l'URL du fichier devant recevoir la requete POST
$message = "POST /BSF/fichier.php HTTP/1.0\r\n";
$message .= "Content-type: application/x-www-form-urlencoded\r\n";
$message .= "Content-length: ".strlen( $data )."\r\n";
$message .= "\r\n";
$message .= $data."\r\n";
echo $data;
$fd = fsockopen( "127.0.0.1", 80 );
fputs($fd,$message);
fclose($fd);
die('end');
}
?>J'ai fait des tests et c'est très concluant.
Il y a-t-il des objections à cette méthode? Et je crains que oui...
Elle ne pourra pas être implementer dans la 1.6.0 qui va être tagé ce soir.
Ca sera une évolution de la 1.7.0 sauf si il faut passer ca en correction dans la 1.6.0.
rub a écrit:
Si quelqu'un pouvait revoir les traductions que j'ai faite en anglais ca serait sympa (et puis en français aussi).
Merci rvelices!
Effectivement, il n'y a pa photo, en anglais, je suis très nul.
Tu as regardé aussi le fichier help?
rvelices a écrit:
En fait, tu penses quoi de reduire le check_key a 8 (maxi 16 caracteres) ? Le lien qu'il faut cliquer sera vraiment tres tres moche autrement (ca prendra n lignes dans le mail) et point de vue securite ca me semble largement suffisant...
Finalement, je l'ai fait... ;-)
Tout est dans la [Subversion] r1116
J'espère que ca va plaindre et qu'il aura pas trop de bugs.
Si quelqu'un pouvait revoir les traductions que j'ai faite en anglais ca serait sympa (et puis en français aussi).
Je ne pense pas que je vais y retoucher ce week-end...
Bientôt, le WIKI sera à jour avec les évolutions prévues pour la version 1.7.0
rvelices a écrit:
rub a écrit:
Le gros soucis, c'est qu'on perd en fonctionnalité car dans la partie "envoyer" SEULS les utilisateurs à qui IL EXISTE DES NOUVEAUTéS à notifier seront affichés, avec ce que tu as fais, on perd cette notion.
Je ne comprends pas bien ta phrase. Qu'est ce qu'on perd ? EDIT: Oublie. Ja'i compris (meme si je personnellement je ne vois pas l'interet)
Pour couper la poire en deux, j'ai rajouté une options permettant de choisir le mode d'affichage de users de l'onglet send.
J'ai rajouté aussi des options sur le nombre de mails à envoyer d'un coup.
Les options sont dans le fichier confuig_default.inc.php.
rvelices a écrit:
rub a écrit:
De plus, ne fonctionne pas sous FF avec installation standard..
J'ai teste sous FF et IE6. Les 2 marchent. T'utilises quelle version FF ? Ton Javascript est active ?
Toutes les excuses, c'est moi qui est merdé, j'avais oublié de mettre le id dans le form.
Tout fonctionnne...
rvelices a écrit:
rub a écrit:
Le gros soucis, c'est qu'on perd en fonctionnalité car dans la partie "envoyer" SEULS les utilisateurs à qui IL EXISTE DES NOUVEAUTéS à notifier seront affichés, avec ce que tu as fais, on perd cette notion.
Je ne comprends pas bien ta phrase. Qu'est ce qu'on perd ? EDIT: Oublie. Ja'i compris (meme si je personnellement je ne vois pas l'interet)
Car, quand tu as un choix important d'utilisateur, selon les permissions, il se peut que la moitié par exemple n'ont pas de nouveauté et par conséquent, remplisse la liste pour rien.
Et aussi car l'envoi va se faire fractionner pour éviter les timeouts et donc si ceux à qui on a envoyé disparaisse, c'est peut-être mieux.
Sinon, j'ai utilisé les user_field et je vais utiliser une fonction global comme toi pour les query sur la table notification.
Si tu fais des modifs attend mon commit sur le .php et .tlp.
Pour le .js, pas de soucis...
rvelices a écrit:
rub a écrit:
De plus, ne fonctionne pas sous FF avec installation standard..
J'ai teste sous FF et IE6. Les 2 marchent. T'utilises quelle version FF ? Ton Javascript est active ?
J'ai regardé vite fait sur un autre site (phpMyAdmin) et ca fontionne bien. La différence, c'est la fonction javascript retourne true et qu'il passe pas le formulaire en paramètre.
J'ai voulu aussi supprimer les boutons 'checkall/uncheckall' pour les remplacer par des <a utr="" onclick='func; return false;'
Et la aussi, le return false n'est pas pris en compte et la fenetre est rechargée.
J'ai voulu ne pas passer le formulaire en paramètre mais je n'ai pas eu le temps...
Je suis en FF 1.5.0.1 et JavaScript est activé.
rub a écrit:
De plus, ne fonctionne pas sous FF avec installation standard..
J'ai teste sous FF et IE6. Les 2 marchent. T'utilises quelle version FF ? Ton Javascript est active ?
rub a écrit:
Le gros soucis, c'est qu'on perd en fonctionnalité car dans la partie "envoyer" SEULS les utilisateurs à qui IL EXISTE DES NOUVEAUTéS à notifier seront affichés, avec ce que tu as fais, on perd cette notion.
Je ne comprends pas bien ta phrase. Qu'est ce qu'on perd ? EDIT: Oublie. Ja'i compris (meme si je personnellement je ne vois pas l'interet)
rub a écrit:
La make_index_absolute_url ne me servira car je veux faire un adresse complete avec un lien pour se desincrire/incrire aucun rapport avec les catégories.
OK. Je n'ai pas bien compris ce que tu voulais. Je vais regarder de plus pres.
rub a écrit:
Je suis désolé, mais ce soir, je vais commiter avec une nouvelle version ne reprennant tes modifs... et je suis quand même très supris des modifs que tu as faites....
Pas de probleme.
rvelices a écrit:
...
- j'ai fait le tout cocher par Javascript
De plus, ne fonctionne pas sous FF avec installation standard..
rvelices a écrit:
Voila, point par point:
- j'ai fait le tout cocher par Javascript
- j'ai rajoute la fonction make_index_absolute_url($cat_id) dans admin/notification_by_email.php - a toi de l'utiliser.
- dans admin/notification_by_email.php:
- j'ai ajoute la fonction get_user_notifications (qui fait la jointure entre USERS_TABLE et USER_MAIL_NOTIFICATION_TABLE)
- maintenant do_action_send_mail_notification fait seulement le 'send' et non plus le 'prepare' (ce dernier est fait par get_user_notifications)
- j'ai remplace une jointure dans le mode 'subscribe' avec la fonction get_user_notifications
Attenion: quand on utilise USERS_TABLE, il ne faut pas utiliser directement les noms des colonnes, mais il faut passer par $conf['user_fields'] (c'est fait dans la fonction get_user_notifications). Il reste encore des endroits ou t'utilises directement les noms.
Pour l'onglet j'ai plusieurs idees, mais je pense qu'on pourrait faire ca plus tard, une fois toutes les fonctionnalites implementes.
En fait, tu penses quoi de reduire le check_key a 8 (maxi 16 caracteres) ? Le lien qu'il faut cliquer sera vraiment tres tres moche autrement (ca prendra n lignes dans le mail) et point de vue securite ca me semble largement suffisant...
Je suis pas DU TOUT d'accord avec les modifications qui ont été faites, et je ne comprends pas pourquoi tu les as faites alors qu'on n'avait pas discuté et validé avant de faire de les modifications.
Le gros soucis, c'est qu'on perd en fonctionnalité car dans la partie "envoyer" SEULS les utilisateurs à qui IL EXISTE DES NOUVEAUTéS à notifier seront affichés, avec ce que tu as fais, on perd cette notion.
La make_index_absolute_url ne me servira car je veux faire un adresse complete avec un lien pour se desincrire/incrire aucun rapport avec les catégories.
La fonction get_user_notifications peut être une bonne idée et l'utilisation des user_fields est à faire bien entendu.
Pour le check_key à 8, bof, de toute façon, ne sera utilisé que pour la gestion interne et les liens d'inscription/description.
Je suis désolé, mais ce soir, je vais commiter avec une nouvelle version ne reprennant tes modifs... et je suis quand même très supris des modifs que tu as faites....
Voila, point par point:
- j'ai fait le tout cocher par Javascript
- j'ai rajoute la fonction make_index_absolute_url($cat_id) dans admin/notification_by_email.php - a toi de l'utiliser.
- dans admin/notification_by_email.php:
- j'ai ajoute la fonction get_user_notifications (qui fait la jointure entre USERS_TABLE et USER_MAIL_NOTIFICATION_TABLE)
- maintenant do_action_send_mail_notification fait seulement le 'send' et non plus le 'prepare' (ce dernier est fait par get_user_notifications)
- j'ai remplace une jointure dans le mode 'subscribe' avec la fonction get_user_notifications
Attenion: quand on utilise USERS_TABLE, il ne faut pas utiliser directement les noms des colonnes, mais il faut passer par $conf['user_fields'] (c'est fait dans la fonction get_user_notifications). Il reste encore des endroits ou t'utilises directement les noms.
Pour l'onglet j'ai plusieurs idees, mais je pense qu'on pourrait faire ca plus tard, une fois toutes les fonctionnalites implementes.
En fait, tu penses quoi de reduire le check_key a 8 (maxi 16 caracteres) ? Le lien qu'il faut cliquer sera vraiment tres tres moche autrement (ca prendra n lignes dans le mail) et point de vue securite ca me semble largement suffisant...
rvelices a écrit:
Tout d'abord ce que t'as fait est tout a fait integrable (en plus je n'ai vraiment pas un mot a dire la dessus). Comme cette foctionnalite m'interesse, je veux l'avoir pour la 1.6 (perso) et comme t'avais l'air de travailler activement la-dessus, j'ai propose d'aider ...
Ok, ok, je pensais avoir fait de grosses boulettes et j'apprecie ton aide...
rvelices a écrit:
- Je vais d'abord juste faire le simple Javascript pour tout cocher/decocher (les fonctions Javascript sont deja en PWG)
Cool! J'avais essayé de trouver des écrans où il y avait des checkall/uncheck mais sans sussés...
rvelices a écrit:
- Quant a la fonction do_action... biensur c'est n'est pas du Javascript, mais en grande lignes il me semble qu'elle fait 2 choses completement distincts (selon l'aapel): recuperation de la liste des utilisateurs inscrits ou envoi des mails. Je pense qu'on pourrait optimiser si on la coupe en 2 (!!! je me trompe peut etre car j'ai vite regarde !!!)
La couper en 2! Comment?
En fait, le prepare fait la liste des utilisateurs à qui on peut envpoyer un mail de notification. Donc, il nécessaire de savoir s'il existe des nouveautés ou non. Et donc, il faut se mettre dans un environnement $user (pour la forbidden), puis faire les sql pour les news (optimisé dans le prepare par le exits_news qui s'arrête des qu'une nouveauté a été trouvée).
Donc, je ne vois pas comment couper en 2 deux... Mais si tu as une idée, n'hésites pas à la soumettre.
En fait, je pense que pour éviter les requêtes en double, il faut pouvoir recupérer les données completes fait avant le POST dans le code faire après le POST (J'ai essayé des tableaux de tableaux mais bof)... As-tu une idée?
Sinon, on a déjà evoqué plusieurs cookie_path pour avoir le chemin complet d'un lien... J'ai essayé mais ca me donne par exemple ./BSH alors que je voudrais 127.0.0.1/BSF ou plutot http://127.0.0.1/BSF. Peux-tu me donner un exemple pour avoir ce que je veux avec cookie_path.
Si tu veux m'aider, je veux bien des fonctions/ajout de parametre dans functions_url.inc.php pour avoir des chemins complets.
Sur ce qu'il reste à faire, je n'aurais pas le temps de faire tout ce que je voulais ni ce qu'on m'a proposé (x mails pour un utilisateur, ...). Ce que je veux faire avant la dernière livraison, c'est :
o paramètre pour limiter le nombre d'envoi simultané (pb de timeout)
o envoi de mail inscription/déinscription
o ajout d'un lien dans les mails pour que le user puisse faire son inscription/déinscription
Sinon, je voulais des onglets mais d'un point de vue code, je n'ai pas trouvé mon bonheur.
La page est devisé en 3 parties accésible par 3 liens pour le webmaster et un lien pour un admin.
J'aurais voulu faire une présentation de style onglet "classic". As-tu une idée pour ca?