Piwigo.org

rub · 2006-03-29 10:36:20

rub a écrit:
rvelices a écrit:
- il y a un moyen tout simple (en utilisant JavaScript) de cocher tout ou rien et ceci sans refaire une demande au serveur
Je voudrais bien connaitre le moyen en JavaScript, par contre, je ne penses qu'on utilise et qu'il faille utiliser le JavaScript pour le dev de PWG, c'est pour ca que je suis parti sur des submit.

Au temps pour moi! On utilise bien du JavaScript.
Va-y tu modifier les sources, pour tout cocher/décocher. Tu peux faire la modif quand tu veux, il faudra simplement qu'on fasse des merges à chacun de nos commits.
Sinon, ce WE, je n'aurais pas le temps de travailler sur PWG, donc tu pourras faire ce que tu veux.

rub a écrit:
rvelices a écrit:
- la fonction do_action_send_mail_notification ...
Quelle serait ta solution pour ne pas faire les requêtes 2 fois?

C'est en JavaScript aussi que tu veux le faire?

Changement de "Au temps pour moi" à la place de "Autant pour moi"!

Dernière modification par rub (2006-03-29 10:43:53)

rvelices · 2006-03-29 15:10:38

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 ...
- Je vais d'abord juste faire le simple Javascript pour tout cocher/decocher (les fonctions Javascript sont deja en PWG)
- 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 !!!)

rub · 2006-03-29 17:58:31

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?

rvelices · 2006-03-30 04:01:53

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...

rub · 2006-03-30 10:01:33

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....

rub · 2006-03-30 12:53:28

rvelices a écrit:
...
- j'ai fait le tout cocher par Javascript

De plus, ne fonctionne pas sous FF avec installation standard..

rvelices · 2006-03-30 15:27:39

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.

Dernière modification par rvelices (2006-03-30 15:37:41)

rvelices · 2006-03-30 15:29:01

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 · 2006-03-30 15:55:59

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 · 2006-03-30 23:13:52

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...

rub · 2006-03-31 13:03:29

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.

rub · 2006-04-01 03:11:07

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

rub · 2006-04-04 11:59:09

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?

rub · 2006-04-06 19:35:11

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:

Code:

<?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.

rvelices · 2006-04-14 03:46:52

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.

Piwigo.org

Annonce

#46 2006-03-29 10:36:20

Re: [1.5.0] Notification des news par mails en complément du RSS

rub a écrit:

rvelices a écrit:

rub a écrit:

rvelices a écrit:

#47 2006-03-29 15:10:38

Re: [1.5.0] Notification des news par mails en complément du RSS

#48 2006-03-29 17:58:31

Re: [1.5.0] Notification des news par mails en complément du RSS

rvelices a écrit:

rvelices a écrit:

rvelices a écrit:

#49 2006-03-30 04:01:53

Re: [1.5.0] Notification des news par mails en complément du RSS

#50 2006-03-30 10:01:33

Re: [1.5.0] Notification des news par mails en complément du RSS

rvelices a écrit:

#51 2006-03-30 12:53:28

Re: [1.5.0] Notification des news par mails en complément du RSS

rvelices a écrit:

#52 2006-03-30 15:27:39

Re: [1.5.0] Notification des news par mails en complément du RSS

rub a écrit:

rub a écrit:

rub a écrit:

#53 2006-03-30 15:29:01

Re: [1.5.0] Notification des news par mails en complément du RSS

rub a écrit:

#54 2006-03-30 15:55:59

Re: [1.5.0] Notification des news par mails en complément du RSS

rvelices a écrit:

rub a écrit:

rvelices a écrit:

rub a écrit:

#55 2006-03-30 23:13:52

Re: [1.5.0] Notification des news par mails en complément du RSS

rvelices a écrit:

rub a écrit:

#56 2006-03-31 13:03:29

Re: [1.5.0] Notification des news par mails en complément du RSS

rvelices a écrit:

rub a écrit:

#57 2006-04-01 03:11:07

Re: [1.5.0] Notification des news par mails en complément du RSS

rvelices a écrit:

#58 2006-04-04 11:59:09

Re: [1.5.0] Notification des news par mails en complément du RSS

rub a écrit:

#59 2006-04-06 19:35:11

Re: [1.5.0] Notification des news par mails en complément du RSS

Code:

#60 2006-04-14 03:46:52

Re: [1.5.0] Notification des news par mails en complément du RSS

Pied de page des forums