|
|
|
|
|
Iscrizione alle categorie, chiavi di lettura, pubblicazione posticipata
Un ambito che va analizzato bene è quello della spedizione via email delle notifiche provenienti dalle categorie a cui si è iscritti. Nel caso delle newsletter funziona bene (a parte il discorso ancora in sospeso del testo dentro alla mail), ma mi sorgono dei dubbi relativamente alle situazioni più complesse. Ad es. cosa succede se la categoria è sotto chiave di lettura? Attulamente Situx spedisce le notifiche fregandosene. Come dire: se un'utente si è iscritto alla categoria, necessariamente possiede la chiave, altrimenti non avrebbe potuto vedere il link per iscriversi. Ma cosa succede se la categoria viene messa sotto chiave dopo che alcuni utenti si sono iscritti? Succede che la notifica gli arriva (con magari dentro il testo) ma poi se vanno sul sito non vedono l'articolo, neanche se fanno login, perché non hanno la chiave. Brutto.
E poi cosa succede se uno pubblica un articolo con data posticipata? Attualmente Situx spedisce all'istante le notifiche fregandosene. Forse invece dovrebbe spedire le notifiche al momento dell'uscita programmata dell'articolo.
Forse la soluzione potrebbe essere quella di non spedire all'istante le notifiche ma accumularle dentro al database. Poi fornire una funzione del tipo: "Ci sono notifiche. Spedisci ora" oppure "Non ci sono notifiche in coda".
Questo consentirebbe all'autore dell'articolo di tornarci sopra con calma finche non è tutto a posto e, a quel punto, spedire le notifiche.
Pensiamoci
Pubblica una novità Segnala via email Iscriviti alla categoria "Segnalazioni" Abbonati al Feed della categoria "Segnalazioni" Altre pulci dalla categoria "Segnalazioni"
Non mi convince l'ultima soluzione, la cosa migliore mi sembra una pagina con un bel pulsante "Invia aggiornamenti" o "Invia newsletter"
Però il cloud computing non mi convince, non vorrei appesantire la navigazione.
Invece potremmo fare una pagina apposta, raggiungibile solo dall'amministratore, con dentro un sistema javascript/ajax che conta il tempo e dice al server di spedire. L'unica cosa che l'amministratore deve fare è tenere aperta questa pagina. Anche di notte se vuole.
Ecco uno stratagemma per non usare cron. C'è un javascript che tiene il tempo e ad intervalli regolari un ajax (lanciato da qualunque browser, visitatori/amministratore) dice al server di spedire le mail (o qualche altra azione).
Beh, buona idea.
Bisogna verificare che non se ne accumulino troppe, verificare quante mail è possibile inviare
Per fare un controllo automatico una volta al giorno bisognerebbe servirsi di un programma che si chiama cron. Ma non mi sembra che aruba te lo lasci usare. A dire il vero dovrei indagare, non sono sicuro.
Comunque c'è un'altra soluzione: la "posta in uscita". Un archivio in cui si vanno ad accumulare le varie notifiche (in base alla data di pubblicazione dell'articolo e non a quella di creazione).
L'amministratore dovrebbe cliccare "invia" con la frequenza che ritiene. Però niente di automatico, ahime.
Ho cambiato idea le mail di pubblicazione articolo devono essere spediti in base alla data di uscita.
La soluzione delle notifiche può essere valida ma anche se ci fosse un controllo automatico una volta al giorno non sarebbe male!
Sono d'accordo la mail deve essere inviata al momento della pubblicazione dell'articolo.