Attenzione: la versione 1.8.2 non è ancora uscita, ma questa è una versione preliminare.
Buongiorno a tutt*!
la versione 1.8.2pr3 di SPIP è disponibile all’indirizzo
Quando questa versione sarà terminata (mancano ancora alcune traduzioni), essa sarà l’ultima versione della serie 1.8, poiché lo sviluppo di SPIP cambia sistema (passiamo dal CVS al SVN), e si apporteranno delle modifiche significative – soprattutto il passaggio dei file che ora hanno estensione .php3 e che diventeranno .php, la riorganizzazione delle cartelle e via dicendo.
Questa versione corregge la maggioranza dei bug (conosciuti) della versione 1.8.1, e in generale dovrebbe essere più affidabile.
Novità principali:
Interfaccia e performance
— Numerosi miglioramenti al fine della compatibilità XHTML nella funzione propre() e a livello dell’integrazione dei documenti nel testo.
— Migliore « accessibilità » delle tabelle.
— Monitoraggio tramite RSS dei forum interni del sito, dei messaggi personali e degli articoli/brevi ecc. proposti per la pubblicazione.
— Opzioni supplementari per la syndication dei siti è possibile « togliere dalla pubblicazione » automaticamente i link che non compaiono più nel file di syndication del sito in syndication, e/o cancellarli dal database dopo un certo periodo. D’altronde, la lettura dei file di syndication può leggere più elementi e in particolare:
- i documenti distanti (podcasting o enclosure, vedi oltre);
- le date di aggiornamento
- le modificazioni dei titoli o del contenuto
— La possibilità, nell’area riservata, de impostare in maniera più fine l’ora (e non più solo il giorno) di pubblicazione dell’articolo.
Gestione dei documenti
— Documenti distanti.
Nel blocco che permette di trasferire un documento associato all’articolo è ora possibile specificare l’URL di un documento «distante», che verrà inserito nel database come se si trattasse di un documento «locale», ma senza che il file stesso sia inserito nella cartella IMG/
Questi documenti distanti sono repertoriati nello stesso modo dei documenti locali: è possibile modificarne il titolo, la descrizione; SPIP controlla la presenza e la dimensione di questi file e, se sono immagini, ne fa una copia localmente per creare le miniature in maniera automatica.
È possibile collegare sistematicamente questi documenti distanti, usando un filtro da aggiungere ai propri modelli: |copie_locale. Questo filtro ha la funzione seguente: dopo aver fatto una copia locale, se necessario, del documento (il che potrebbe richiedere molto tempo se esso perso diversi Mb), esso restituisce l’indirizzo locale del documento.
Infine, SPIP integra questo concetto di documento distante nella syndication: da una parte, esso legge il flusso della syndication che indica i documenti allegati (podcasting), d’altra parte, il modello dist/backend.html pubblica nello stesso formato i documenti associati all’articolo e che non appaiono nel testo dell’articolo (in altre parole, l’equivalente di quel che appare, nell’area riservata, nella parte portfolio / documenti allegati dell’articolo).
— Indicizzazione dei documenti. I titoli e le descrizioni di tutti i documenti vengono indicizzati e quindi utilizzabili in un ciclo<BOUCLE(DOCUMENTS){recherche}{par points}{inverse}>
Se possibile, SPIP tenta anche di indicizzare il contenuto dei documenti (soprattutto per i documenti nel formato HTML, TXT, PDF, RTF e DOC). Questa funzionalità può essere estesa ad altri formati sviluppando degli scripts « estrattori » (è facile immaginare tali script per i formati MP3 o OpenOffice).
— Zip all’upload. Quando si invia un documento « vietato », o in ogni caso non previsto nella tabella spip_types_documents (per esempio un file .php), ora SPIP propone di «zippare» il documento. (In passato esso ignorava silenziosamente la richiesta di upload.)
Calendario nell’area pubblica
Adesso è possibile visualizzare nell’area pubblica i calendari dell’area riservata, e più in genrale di costruire una qualsiasi agenda che sfrutti gli strumenti di impaginazione di questi calendari. Questa possibilità viene offerta da un nuovo criterio di ciclo e da due nuovi filtri.
Il criterio agenda possiede diversi variabili di argomento; i primi due sono
- un nome di campo SQL di tipo datetime (per esempio date o date_redac per la tabella Articles); questo argomento non può essere omesso.
- un tipo di calendario, di cui quelli implementati sono
jour (giorno), semaine (settimana), mois (mese)
oppure periode (periodo); il valore predefinito è mois.
Questi due argomenti devono essere letterali (ovvero, non possono essere calcolati dinamicamente da #ENV o da qualsiasi altro segnaposto). Ad essi fa eventualmente seguito un trio di argomenti supplementari che possono essere indicati da segnaposti:
- una stringa di 4 cifre esatte che indica un anno;
- una stringa di 2 cifre esatte che indica un mese;
- una stringa di 2 cifre esatte che indica un giorno.
Se tali valori sono nulli oppure vengono omessi verranno sostituiti dai valori della data attuale.
Nel caso in cui il secondo argomento ha valore periode, si deve specificare un secondo trio similare; in virtù dell’affermazione precedente, se esso viene omesso verrà considerata la data corrente, e se anche il primo trio è assente il periodo comprenderà tutta la vita del sito (per i siti con molti articoli il tempo di esecuzione rischia di essere eccessivo se altri criteri non limitano il numero di ricerche da effettuare).
Questo criterio si utilizza in un ciclo che ha un campo di tipo datetime indicato come primo argomento.
Esso porta a selezionare in questo ciclo esclusivamente gli elementi di cui questo campo ha un valore compatibile con gli altri argomenti, cioè:
- essere un valore uguale a anno-mese-giorno se il tipo è jour,
- essere un valore compreso nella settimana del giorno indicato da anno-mese-giorno se il tipo è semaine,
- essere un valore compreso nel mese indicato da anno-mese se il tipo è mois,
- essere un valore compreso nel periodo indicato dai due trio di date se il tipo è periode.
Il filtro agenda_memo si applica su:
- una data
- una descrizione
- un titolo
- l’URL di un articolo che ha questo titolo, questa descrizione e questa data
- un nome di classe CSS
- un tipo di calendario (
jour,semaine,moisoppureperiode).
Se il sesto argomento non viene specificato, il filtro si accontenta di memorizzare i primi quattro in una tabella privata identificata dal quinto argomento.
Se invece esso viene specificato, il filtro restituisce l’impaginazione degli elementi memorizzati in precedenza, secondo il tipo richiesto e la classe CSS indicata.
Il tipo periode limiterà la visualizzazione al periodo compreso tra l’elemento più vecchio e quello più recente effettivamente trovati, il che permette di dare nel criterio un periodo molto ampio senza causare una visualizzazione troppo estesa.
L’utilizzo del quinto argomento come identificatore della tabella privata permette di avere tanti calendari per pagina quanto è necessario, con una tipografia differenziata a seconda dei bisogni. Il foglio di stile calendrier.css fornisce 28 stili diversi che è possibile modificare o ampliare.
Infine, il filtro agenda_connu testa se il suo argomento corrisponde a uno dei quattro tipi di calendari conosciuti (jour, semaine, mois oppure periode).
Questo criterio e questi filtri sono utilizzati dai nuovi modelli di layout
jour.html, semaine.html, mois.html periode.html, chiamati dal modello agenda.html che indica nel suo header i fogli di stile e le funzioni JavaScript necessarie (ma sostituibili a volontà). Questi modelli forniscono un esempio rappresentativo di utilizzo.
Nuovi filtri
— Nuovo filtro |inserer_attribut{variabile, valore}, che permette di inserire forzatamente un attributo di un tag HTML.
Esempio di utilizzo:[(#LOGO_ARTICLE|#URL_ARTICLE|inserer_attribut{alt,#TITRE})]
— Nuovo filtro |alterner, che permette di alternare i colori in un elenco (attraverso, per esempio, [(#COMPTEUR_BOUCLE|alterner{1,2,3})]); il tipo di argomenti dà la periodicità dell’alternanza che quindi non è obbligatoriamente una successione del tipo « pari/dispari ».
Avvertenza: poiché questo filtro è puramente «numerico», se viene applicato a [(#ID_ARTICLE|alterner{1,2})], esso visualizzerà 1 per gli articoli con identificativo dispari e 2 per quelli con identificativo pari.
— Filtri di URL «assoluti». Tutti i link proposti da SPIP (a partire dalle scorciatoie [->article 11] o dai segnaposti del tipo #URL_ARTICLE) sono dei link «relativi», che non indicano l’indirizzo completo della risorsa collegata. Ora, per alcuni usi, come per esempio la syndication, è utile avere l’indirizzo assoluto. A tal fine sono stati introdotti due filtri:
- |url_absolue che si applica agli URL: [(#URL_ARTICLE|url_absolue)];
- |liens_absolus che si applica ai testi e che trasforma l’indirizzo dei link e delle immagini: [(#TEXTE|liens_absolus)].
(Il filtro |abs_url riassume questi due filtri in uno solo, e applica |url_absolue sugli #URL_ARTICLE, e |liens_absolus sugli elementi di tipo #TEXTE.)
— Il filtro |reduire_image è ora capace di ridurre le immagini all’interno di un testo, quindi è possibile applicarlo al segnaposto #TEXTE. Altra modifica di questo filtro: se si indica la lunghezza 0 in verticale o in orizzontale, ciò significa che deve essere presa in considerazione per la riduzione solo l’altra dimensione. Quindi [(#LOGO_ARTICLE||reduire_image{60,0})] passerà il logo a una dimensione orizzontale di 60 pixel massimo (la dimensione verticale viene calcolata in maniera da poter mantenere le proporzioni).
Miglioramento della sintassi dei modelli
— I modelli standard passano al formato XHTML 1.0 transitional.
— Un segnaposto #DOSSIER_SQUELETTE permette di distribuire più facilmente dei kit di modelli in maniera che l’installazione nelle sottodirectory sia più agevole.
— #FORMULAIRE_FORUM accetta un argomento che indica la pagina in cui il visitatore che invia un messaggio al forum deve essere reindirizzato. Di default, in effetti, questo posto era diventato #URL_FORUM; tuttavia alcuni usi possono esigere un ritorno alla medesima pagina (sintassi: [(#FORMULAIRE_FORUM{#SELF})]), oppure verso una pagina specifica ([(#FORMULAIRE_FORUM{grazie.php})]).
— Generalizzazione delle costruzioni della forma [(#SEGNAPOSTO|filtro{[(#ALTRO_SEGNAPOSTO|altro_filtro)]})] ad un livello qualsiasi di nidificazione. Questa possibilità è estesa anche ai criteri nei cicli, in tal caso le parentesi quadre non sono necessarie (e vengono rifiutate).
— Per ragioni di uniformità di sintassi, il segnaposto #EXPOSE sostiuisce il vecchio segnaposto #EXPOSER. L’unica differenza tra i due è che è necessario scrivere [(#EXPOSE{on,off})] e non più [(#EXPOSER|on,off)]
— Qualora un ciclo utilizzi il criterio {statut}, l’impostazione predefinita dello status degli elementi collegati a questo ciclo sparisce. In altre parole, se i cicli (ARTICLES) normali continuano a selezionare unicamente gli articoli che hanno uno status uguale a 'pubblicato', un ciclo <BOUCLE_a(ARTICLES){statut=prop}> selezionerà gli articoli proposti.
Similmente, il ciclo <BOUCLE_indy(BREVES){statut IN prop, publie}> selezionerà tutte le brevi proposte o pubblicate; il segnaposto #STATUT permette di visualizzare per ognuno lo status corrispondente (e, per esempio, attribuire una classe CSS differente a seconda dello status).
— il criterio par accetta ora dei nomi di campo SQL specificati in maniera dinamica, in particolare dal segnaposto #ENV, e la loro assenza non causa errori SQL. Inoltre, questo criterio ammette ora la sintassi {!par ...} per ordinare in maniera inversa tutte le colonne indicate (ciò rende obsoleto il criterio inverse, che si applica solo sulla seconda colonna). Per ottenere un ordinamento in ordine crescente per alcune colonne e decrescente per altre è sufficiente scrivere più criteri par.
Tutto ciò permette di scrivere facilmente dei modelli di presentazione di una tabella a più colonne che integra dei bottoni di ordinamento su ogni colonna, come in un foglio di calcolo. Un esempio è riportato qui.
* *
Come al solito queste novità saranno via via inserite nella documentazione.