Variabili di contesto

Contesto globale

Disponibile in ogni template (layout, sezioni, pagine).

Nota: Gli elenchi globali (campaigns, pages, blogs, articles) espongono solo gli attributi di base. La variabile della pagina corrente (campaign, page, blog, article, project) espone tutti quelli descritti in Oggetti e attributi.

Variabili per tipo di pagina

Il template usato è quello del tipo (es. campaign) oppure quello impostato sul singolo contenuto (campaign.template).

Ringraziamento

checkout_supporter.id e checkout_donation.id sono gli id numerici del sostenitore e della donazione appena registrata, da usare per pixel di conversione e dataLayer.

<script>
  dataLayer.push({
    event: "donation",
    donation_id: "{{ checkout_donation.id }}",
    supporter_id: "{{ checkout_supporter.id }}",
    value: "{{ checkout_donation.amount }}",
  });
</script>

Nota: Nell'anteprima del tema (.../thankyou/__preview__) i due id valgono 0, come il resto dei dati di esempio.

Peer campaign

Il form ha due campi, peer_supporter_name e custom_message. Lo slug viene derivato dal nome (slugify più suffisso numerico se occupato) e non si può cambiare dopo, perché è l'indirizzo che il promotore ha già condiviso.

Il template peer_campaign_form rende tre pagine, distinte da peer_campaign:

• campaigns/<slug>/fundraise/: creazione, peer_campaign è None. Risponde 404, prima di chiedere l'accesso, se la campagna non prevede raccolte personali o è di tipo Lead;
• campaigns/<slug>/<peer_slug>/update/v2/: dettaglio e gestione della raccolta, con statistiche e form precompilato. Il form va inviato in POST a peer_campaign_update_url_v2; dopo un salvataggio riuscito la vista ritorna qui con peer_campaign_updated a True;
• campaigns/<slug>/<peer_slug>/update/: la v1, ancora attiva. Dopo il salvataggio manda alla pagina pubblica e non passa le variabili aggiuntive.

I temi linkano invece /my/campaigns/<id>/, nell'area sostenitore. La v2 resta attiva perché è la action del form nei temi rilasciati prima.

peer_campaign_public_url è assoluto e senza __preview: è l'indirizzo da condividere. peer_campaign_update_url_v2 è relativo e conserva __preview, perché è la destinazione di un form.

Disattivare le raccolte personali sulla campagna madre impedisce di crearne di nuove; quelle esistenti restano pubbliche e modificabili.

Area sostenitore

Queste pagine sono template statici del tema, non usano il motore delle sezioni.

profile è un supporter, donations un elenco di donation e peer_campaigns un elenco di peer_campaign.

Pericolo: In passato le pagine donazioni e campagne ricevevano queryset: un tema che chiama donations.all() va aggiornato, ora donations è già un elenco.

Il dettaglio campagna sta su /my/campaigns/<id>/ e ci si arriva da peer_campaign.manage_url. Usa l'id e non lo slug, perché lo slug di una raccolta personale è unico solo dentro la campagna. Mostra statistiche, link da condividere e form precompilato con nome e messaggio. Il form va inviato in POST a peer_campaign_manage_url (la pagina stessa, con __preview conservato); dopo un salvataggio riuscito la vista ritorna qui con peer_campaign_updated a True. Una raccolta di un altro sostenitore risponde 404.

error vale token quando il link di accesso è scaduto o già usato: un link vale una volta sola e per un'ora. La sessione non scade.

Chi può accedere

Chiunque. Il link parte per qualunque indirizzo valido, anche sconosciuto all'organizzazione: l'anagrafica viene creata quando il link viene aperto. Fa eccezione un indirizzo archiviato, che riceve error=token come un link non valido.

Il tema non deve promettere condizioni che non esistono ("l'indirizzo con cui hai donato") né dire se l'indirizzo era conosciuto: la risposta è sempre la stessa, altrimenti la pagina rivela chi ha donato all'organizzazione.

Pericolo: Il captcha su templates/supporters/login.html è obbligatorio: il form fa partire una mail dal dominio dell'organizzazione verso un indirizzo scelto da chi compila. Il tema deve rendere widget e honeypot.

Suggerimento: Nei form dell'area disabilita il pulsante al submit e mostra uno stato di attesa, così non vengono inviati più volte. Il tema di riferimento usa un data-submit sul pulsante e un listener submit che imposta form.dataset.submitted.

Protezione antibot (captcha)

Le viste con un form pubblico aggiungono al contesto la variabile captcha. Se captcha.enabled è false il tema non deve rendere nulla.

I form protetti sono tre: box lead, checkout e accesso sostenitore. I form dell'area riservata non hanno captcha, perché chi li usa ha già fatto l'accesso.

{% if captcha.enabled %}
<script type="module" async defer src="{{ captcha.script_url }}"></script>
<altcha-widget challenge="{{ captcha.challenge_url }}"
    name="{{ captcha.field_name }}"
    language="{{ captcha.language }}"
    auto="onfocus"></altcha-widget>
{% endif %}

Pericolo: Carica solo captcha.script_url, non il bundle del widget: registra anche l'algoritmo della sfida, che il bundle non conosce. Puntando a mano ad altcha.min.js ogni verifica fallisce con "unsupported algorithm". worker_url non esiste più.

Il campo esca va posizionato fuori dallo schermo (non display:none), con autocomplete="off" e tabindex="-1": altrimenti il browser lo compila e blocca una persona vera.

Pericolo: Leggi endpoint e percorsi degli asset sempre da captcha, non scriverli a mano. Rendi anche form.non_field_errors(): il campo esca compilato produce un errore di form, non di campo.

Note

• Le variabili SEO (seo_title, seo_description, google_tag, ...) sono usate solo nell'header e non sono accessibili nei template del tema.
• La pagina donate usa un template di sistema, non il motore delle sezioni.
• Usa sempre supporter_urls invece di scrivere i percorsi a mano: conserva __preview, così non si esce dall'anteprima del tema al primo clic.

Fonte: https://dev.riseact.org/docs/themes/context-variables. Copia automatica da dev.riseact.org: non modificare qui, le modifiche vanno fatte sulla documentazione Docusaurus.