Pause/Relance

[trebla]

Dans quelle mesure peut on avoir un bouton de Pause des envois et de Relance avec une conservation en memoire du dernier mail envoye (en comptage)...
Dans le cas de probleme, ce serait pratique de pouvoir relancer une newsletter a partir de ..15687 par exemple, plutot que de recommencer depuis 0

[Matthieu]

Es-tu sur un serveur dédié ou mutualisé ?

[trebla]

Serveur dedie

[Matthieu]

Ok, je peux voir pour faire un mod qui tournerait grâce à une tache CRON dans ce cas, et tu n'aurais plus qu'à renseigner l'heure et la date d'envoi ...

[trebla]

Salut... On parle bien d'un bouton sur la page d'envoi... Je ne vois pas ce que le CRONjob vient faire la !
Je parle d'un bouton, genre en dessous de la ligne de comptage qui pemettrait de faire "pause" et "Continuer". Cela veut dire que si on veut rester devant son PC pendant l'envoi et que l'on doive aller faire une course, on fait "Pause" et des que l'on revient, on fait "Continuer".

La "Relance" peut etre consideree comme autre chose. C'est a dire, que l'on se delogge, on eteint le PC et le Lendemain ou 5 heures plus tard, on va sur l'historique qui n'a comptabilise QUE ce qui est reellement parti et a ce niveau la, on fait "Relance" ou "Abandon", si on veut creer une nouvelle newsletter.
Partant du principe que l'on ne peut pas creer une nouvelle newsletter, sans avoir solde la precedente (soit "Relance/Abandon)
Mais si tu peux faire en sorte que des newsletters puissent rester en Standby et continuer a en faire d'autres : Pourquoi pas !

[Matthieu]

Euh techniquement, non, l'explication est le principe du client serveur ...

en clair, la newsletter est stockée en mémoire vive (RAM) du serveur qui héberge ton site. Dans la page send_newsletter où il passe de 20 en 20 (par défaut), ce que tu vois n'est que le résultat de l'action qui vient d'être faite : le serveur traite les emails de 20 à 39, il envoie les mails, fait les compte et envoie le tout, sous forme HTML, à toi, qui es le "client" de l'histoire.

Mettre en pause signifie de dire au serveur "attends 5 min" (ou X minutes, peu importe), mais comme tu ne vois que du décalé (pas du temps réel) il faudrait que cette action intervienne directement sur les processus du serveur, ce qui est faisable sans doute sur un dédié (via l'utilisation de commande system, exec ou autre) mais pas sur un serveur mutualisé, ce qui empêchera 90% des utilisateurs de NewsletTux de s'en servir.

D'autre part, faire une pause signifie écrire les données en RAM quelque part, parce que la session ne peut être mise en pause, elle est valable un certain temps (par défaut, je crois que c'est 3600 secondes consécutives) et sans nouvelle action de ta part pendant 3600 secondes consécutives, le serveur la détruit automatiquement, perdant de ce fait toutes les données qu'elle contient. Encore une fois, je crois qu'on peut modifier ce chiffre soit directement dans la config du serveur (mais pas réalisable sur un serveur mutualisé) soit via une commande ini-set donnée dans un autre topic, mais pareil, très peu (pour ne pas dire "aucun") de serveurs mutualisés l'autorisent.

C'est difficile de faire un script qui puisse cibler le plus de personnes possibles ...

Concernant le Cron, c'est pour te permettre de le lancer sans être devant ton navigateur, le serveur cron s'occupant de le faire à ta place (utile pour le lancer à 3h du matin par exemple)

J'y réfléchis ...

[trebla]

Est-ce-que si l'envoi de la newsletter etait stockee sur une table temporaire qui se viderait au fur et a mesure des envois, cela reglerait le probleme. cela donnerait probablement d'autres possibilites, comme par exemple precharger une newsletter ou plusieurs et decider de les envoyer quand on veut.
La table contiendrait les donnees de la newsletter ainsi que les adresses associees a celle ci.
En fait, il faut trouver la combine pour ne pas etre en memoire vive pour n'etre dependant du serveur qu'au moment de l'envoi. Si on faut "pause" le serveur arrete completement en realite, mais la table a memorise jusqu'a quelle adresse elle a vide.

Je suis loin d'etre un programmeur php, je suis juste un utilisateur et j'essaie de reflechir.
Excuses si je dis des betises techniques.

[Matthieu]

non, ce ne sont pas des bêtises, et avec ma réflexion j'en suis arrivé à peu de choses près au même stade ...
Le souci c'est que dans l'actuelle version 213, quand tu es en "session base de données" dans la config, la session PHP (donc la mémoire vive du serveur) ne contient que des nombres, donc c'est vraiment pas ce qui consomme toute la mémoire.

La seule différence entre ce que j'ai pensé (et que tu as imaginé de ton côté) et l'actuel système est que les emails sont rapatriés au fur et à mesure des envois, et non tous au début puis écrits...

[trebla]

Pour repondre a ton dernier post concernant la difference. Il devrait suffire de faire le contraire, cad : remplir la table temporaire dans un premier temps et de la vider au fur et a mesure et a mesure des envois. Cela permet donc en plus de precharger des jours a l'avance cette table et de l'appeler quand on veut, de faire pause/continuer ou relance de ce qui reste de son contenu.

Il faudrait seulement prevoir un laps de temps pour que la table se charge et qu'ensuite on procede a l'envoi, donc juste une etape supplementaire apres on peut choisir de laisser en standby, programmer une date et heure d'envoi ou envoyer directement, ou mieux encore... elle charge et envoie en meme temps en supposant que le chargement est plus rapide que l'envoi.

Ce serait pas mal, Non ?

[Matthieu]

ouais, je pense que je vais partir de là.le pb c'est que pour toi, rapatrier 53 mille mails d'un coup, ça passe pas. Donc au final, on sera limité par les ressources du serveur.

Sinon t'as toujours le moyen de scinder tes abonnés en 2 listes de 25 mille, et de faire un double envoi (ok, c'est pas terrible, mais techniquement si tu bloques à 99% des 53000 ya pas de raison pour que ça bloque à 25000)

Et pour switcher automatiquement 25 mille abonnés d'un profil 1 à un profil 2, ça se fait en une commande SQL, donc c'est pas le plus difficile. Mais je conçois que c'est plus une solution "système D" que réelle solution.

par contre pour ce qui est de programmer une heure d'envoi, ce n'est pas possible sur un serveur mutualisé. Mais on pourrait le mettre en place sur un dédié, je préfère pour cela passer par un mod.

[trebla]

Pas mal comme option.
Concernant une grosse quantite, je pense qu'il faudrait trouver une autre solution. Si moi j'ai 53000, tu pourrais avoir une utilisateur demain avec 150000. Tu as un creer un mod qui permet d'exporter les users avec des criteres (avec inscription, avec permission...). En fait je pense tout simplement qu'il faut se resservir de ce genre de script et rajouter en fin un import dans la fameuse table....

[Matthieu]

FYI, je l'ai ajouté dans la FAQ : Comment scinder une liste d'utilisateurs en plusieurs profils

Je planche sur une solution... Désolé si ça prend un peu de temps mais je n'ai plus assez de batterie pour passer dans une autre dimension afin de réaliser plus de 24h par jour ... 

[trebla]

J'attends avec patience.... Je sais que tu dois etre surcharge... de toutes facons, ce n'est pas une modif vitale.

[Matthieu]

Dans l'attente t'as toujours moyen de scinder les abonnés, mais bon.

[trebla]

Salut Matthieu,
Penses tu pouvoir t'occuper de cette fonction.... avant de passer a encore autre chose ?