Ho finalmente trovato in node.module, la parte di codice che dovrei correggere, ma purtroppo non conosco il php.
Mi spiego: quando una notizia è troppo lunga, viene fatto un abstract a cui segue "Leggi tutto".
E' possibile al "Leggi tutto" fare in modo unire il titolo del nodo? Si eviterebbe il problema di una stessa frase che porta a due links diversi (sconcerta i non vedenti).
Dovrei aggiungere a ' 'title' => t('Read more'), &node->title in modo che compaia la frase "Leggi tutto verbale del xx.xx.xxxx"
Grazie a tutti per l'infinita pazienza.
/**
* Implementation of hook_link().
*/
function node_link($type, $node = NULL, $teaser = FALSE) {
$links = array();
if ($type == 'node') {
if ($teaser == 1 && $node->teaser && $node->readmore) {
$links['node_read_more'] = array(
'title' => t('Read more'),
'href' => "node/$node->nid",
'attributes' => array('title' => t('Read the rest of this posting.'))
);
}
}
return $links;
}Premesso che quello ceh vuoi fare è da evitare il più possibile, dovrebbe essere sufficiente andare a scrivere:
'title' => t('Read more') . $node->title,'title' => t('Read more'),Grazie Mavino.
Il tuo suggerimento funziona e con lo screen reader capisco dove sto andando.
Perchè dici "quello che vuoi fare è da evitare il più possibile" forse a video non sta troppo bene. Bisognerebbe nasconderlo a video, tanto lo screen reader legge lo stesso e questo è importante.
La classe "nascosto" l'ho creata nel css, ma non so come usarla nel php.
Puoi suggerirmi come?
Grazie per la tua disponibilità
dico che sarebbe da evitare perché stai andando a modificare direttamente un modulo ufficiale, quindi ad ogni aggiornamento perdi le modifiche, per di più lo steso modulo serve anche ad altri moduli, quindi anche negli altri vedrai "Leggi tutto verbale del xx.xx.xxxx" nonostante, magari, si tratti di un nodo di tipo page che non riguarda verbali, generando un pò di confusione nel visitatore.
Come prima opzione per non sbatterti molto potresti creare una copia del modulo node, installarla in /sites/all/modules/ e farci le modifiche che ti servono (ovviamente il modulo dovrai chiamarlo.. che ne so verbali e quindi andare a modificare tutte le chiamate delle funzioni e del DB).
Ciao luisasasi, secondo me, sei fuori strada.... NON devi variare il modulo node.module perchè è SBAGLIATISSIMO come ti han già detto. Per fare quel che tu desideri ci sono soluzioni che non impattano sul modulo.
Una di queste è quella di prendere il template "node.php.tpl" e sostituire "print $links;" con:
<?php
print l('Leggi tutto...', '/node/'.$node->nid, array('title'=>$title));
?>Oppure, se il codice sopra ti sembra ostico puoi usare una cosa tipo:
<?php
print $node_url
?>
<?php
print $title;
?><?php
print $title;
?>P.S.
IMO, ripeto IMO, è sbagliato anche fare una copia del modulo node, perchè si rischia di far entrare "dalla finestra" gli haker. Ti faccio un semplice esempio: viene scoperto un bug di sicurezza su node.module. Tu aggiorni drupal, ma l'aggiornamento non serve a nulla perchè il bug rimane 
Ciao
Gianni
già, ma è il minore dei mali 
La soluzione migliore sarebbe creare un modulo ceh faccia uso fi form_alter per andare a sistemare le cose che servono + alcune funzioni di temizzazione per andare a sistemare la visualizzazione, poi è ovvio anche che se uno usa un modulo derivante da un altro su cui hanno trovato dei bug come minimo dovrebbe andare a controllare se anche il suo è afflitto e vedere se andare a metterci mano. 
Quel che voglio dire è che se decido di variare il modulo node, in futuro sono incasinato con gli aggiornamenti. Ma sono i soliti identici casini che mi ritrovo se sdoppio il modulo. In entrambi i casi devi andare a vedere le modifice del node.module e riapplicarle al nuovo modulo (o al modulo node.module variato)....ma se devi andare a vedere le modifiche e riapplicarle sul tuo modulo sdoppiato.... tanto vale non sdoppiarlo, almeno ho una rogna in meno 
Ovviamente sono vedute differenti
, ma personalmente, se devo fare variazioni sul nodo, preferisco di gran lunga creare un nuovo tipo di nodo ed ereditare tutto dal nodo standard (in questo modo non ho doppio codice, ma un codice unico gestito da node.module + il codice personalizzato per il nuovo tipo che lo posso personalizzare come meglio credo). Il mio nuovo tipo di modulo, erediterà anche tutte le "proprietà" del nodo (se metto il modulo upload, il modulo tiny o quant'altro)
Comunque sia, per la modifica di un link (come nel caso specifico), la soluzione è agire sul template del nodo (comodo ed indolore
) o, se si vuol andare di fino, sbizzarendoci anche sulla singola pagina, si può andare a variare template.php, decidendo i singoli tempalate da lanciare a seconda del caso.
Ciao
Gianni
Pienamente d'accordo, solo ceh clonando il nodo e facendo le modifiche sul nodo copia non influisco sul funzionamento di altri nodi che potrebbero appoggiarsi a node (moduli decisamente molto usato
)
, ma personalmente, se devo fare variazioni sul nodo, preferisco di gran lunga creare un nuovo tipo di nodo ed ereditare tutto dal nodo standard (in questo modo non ho doppio codice, ma un codice unico gestito da node.module + il codice personalizzato per il nuovo tipo che lo posso personalizzare come meglio credo). Il mio nuovo tipo di modulo, erediterà anche tutte le "proprietà" del nodo (se metto il modulo upload, il modulo tiny o quant'altro)Anche io, ed è quello che consiglio a chiunque abbia un minimo di conoscenze di fare, solo ceh dato che poichè l'utente non sapeva concatenare due string (e per suea ammissione non conosce PHP) dirgli di svilupparsi un modulo come minimo lo avrebbe sconvolto 
) o, se si vuol andare di fino, sbizzarendoci anche sulla singola pagina, si può andare a variare template.php, decidendo i singoli tempalate da lanciare a seconda del caso.Perfettamente d'accordo (quando possibile).
__________________Gasp! Non pensavo di causare un guaio tanto grosso! Ringrazio tutti.
Mi pareva una bella soluzione perchè quando la notizia "veniva troncata" perchè lunga, a fine nodo compariva "Leggi tutto - Verbale del xx.xx.xxxx" oppure "Leggi tutto - Gita scolastica a..." , mentre in pagina completa no, quindi mi pareva tutto OK.
Ho rimesso subito il modulo ufficiale e ho provato le due soluzioni che mi ha suggerito Gianni.
La prima:
Una di queste è quella di prendere il template "node.php.tpl" e sostituire "print $links;" con:
<?php print l('Leggi tutto...', '/node/'.$node->nid, array('title'=>$title)); ?>
Appare Leggi tutto... su tutti i nodi, anche quelli non troncati e non collega al nodo con la notizia intera.
La seconda:
<a href="<?php print $node_url ?>" title="<?php print $title; ?>"><?php print $title; ?></a>
Appare Il titolo del nodo, ma questo succede anche sulle pagine non troncate e quindi non va bene perchè genererebbe maggior confusione.
Ora, non so bene come funzionano gli aggiornamenti, ma se ho ben capito, tutte le volte che si fa un aggiornamento sicurezza segnalato da Drupal.org, debbo rimodificare il modulo. Creo ulteriori bug?
Grazie a tutti
Ma quale guaio? Io stimo mavimo e non vedo insulti nei nostri post 
Ho esperesso solamente la mia personale opinione circa l'inutilità di copiare il modulo node, solo per variare un link, quando la cosa si può fare via template...... ma ho messo molti IMO e molte faccine.... come dire "opinione personale e senza offesa".
A me sembra normale scambiare opinioni e vedute tra programmatori.... è una delle basi dell' OpenSource e non credo che mavimo si sia risentito.
Brava.... questa è già una via accettabile rispetto al copiare un modulo (anche se personalmente NON la seguirei perchè del tutto illogica rispetto alla filosofia di Drupal). Ma considera anche la via elegante che è quella che ti ho postato (riveduta e corretta):
.... al posto di:
<?php if ($links): ?>
<div class="links"><?php print $links; ?></div>metti:
<?php if ($page == 0): ?>
<div class="links"><?php print l('Leggi tutto...', '/node/'.$node->nid, array('title'=>$title)); ?></div>e dovresti raggiungere il tuo scopo senza scomodare modifiche sul codice.
P.S.
X mavimo.... rispondo solo ad una tua riga.
Anche se fai un nuovo tipo di nodo, non influenzi gli altri nodi, inoltre puoi definire nuove proprietà (un giorno, giuro che faccio un piccolo tutorial).
Io trovo, la nostra discussione interessante.... ce ne fosse di gente come te, con cui posso scambiare opinioni di programmazione dei moduli!!! In questo forum qualcuno che personalizza moduli c'è, ma siamo in pochi. Mi sembrerebbe stupido non discutere di problematiche come quella venuta fuori in questo post 
Ciao
Gianni
Confermo che non mi sono offeso (casomi ce ne fosse bsogno
), ma anzi...
Pre quanto riguarda il fatto che non influenzi altri nodi andando ad agire sul modulo node non lo trovo proprio corretto... nel senso che poichè ogni cosa è un nodo anche modifiche che sono banali potrebbero andare a influire con le funzionalità di qualche modulo, ovvio poi che più le modifiche sono pesanti tanto più è facile che influisca con altro.
Per esempio alcuni moduli dipendo in maniera esplicita da altri (Forum richiede Taxonomy tanto per citarne uno), quindi finché si tratta di modifcare la funzione di theming la probabilità di fare danno è minima, ma se vado ad agire su altre funzioni.. chi può saperlo? Per questo motivo IMHO è meglio duplicare il nodo in modo che si lascia la versione originale al suo posto così se qualche altro modulo si appoggia ad esso non faccio danno, mentre sulla copia posso fare tutte le modifche del caso senza farmi paranoi sui possibili risultati e limitanto i possibili probemi; ovvio che devo avee un idea di cosa faccio, altrimenti potrei cancellare record dall tabella errata e quindi tanto vale 
Nel caso specifico la cosa migliore è agire sulle funzioni di theming, in altri casi consiglierei di scrivereun modulo, ma ècomunque necessario ceh l'utente sappia farlo, altrmenti la via meno pericolosa èl cpia edl modulo e Find & Replace per rearne la copia funzionante 
Ma infatti tu NON modifichi il nodo, ma ne erediti le proprietà ed i metodi, creando una nuova tipologia di nodo. Immagina la programmazione ad oggetti, rapportata a Drupal (che poi di questo si parla). Come da una classe puoi crearne una nuova che eredita le proprietà ed i metodi del padre... allo stesso modo, con drupal, tu puoi fare una nuova tipologia di nodo che eredita le proprietà ed i metodi del nodo padre. Se al nodo "padre" (chiamiamolo così), aggiungi nuove proprietà, te le ritrovi nel nodo figlio..... se qualcosa cambia nel nodo padre, la variazione si ripercuote nel figlio. Il contrario NON è vero.
Giusto per farti un esempio concreto: devo creare un tipo di pagina che ha in più N campi, chessò: data di inizio validità e data di fine validità (voglio far in modo che QUELLE pagine siano visualizzate per un periodo che voglio io)..... come faccio?
1) vario node.module .....e vabbè, fin quì siamo entrambi d'accordo che non è il sistema giusto 
2) sdoppi node.module e cambi il suo interno..... ok, funziona, però ti ritrovi tutta una serie di funzioni IDENTICHE con nomi diversi. Oltretutto se c'è un bug su node.module, te lo ritrovi anche sul tuo modulo
3) crei un nuovo tipo di nodo chiamato "pagina con scadenza". Questa userà le funzioni del nodo, a cui aggiungeremo una serie di campi ed una funzione per verificarne la scadenza. Non ho funzioni doppie, eredito le proprietà ed i metodi del nodo e, se nel nodo correggono qualcosa, si ripercuote anche nel mio. Tuttavia, il mio nuovo nodo, non può influire su node.module (se non di proposto.... ma non son masochista
)
Da nessuna parte troverai scritto di sdoppiare node.module per variarne le proprietà, ma casomai di creare una nuova tipologia. Ed una nuova tipologia, prevede un numero estremamente ridotto di funzioni, perchè molte sono già "proprietà" e "metodi" di tutti i nodi.... si tratta di aggiungere quelle proprietà e metodi nuovi, di cui, quel nodo specifico, ha bisogno. Quest'esempio è chiarissimo:
http://api.drupal.org/?q=api/file/developer/examples/node_example.module...
La forza di drupal stà proprio nel suo paradigna ad oggetti...... drupal non è scritto in con oggetti e classi, ma la sua struttura lavora con le stesse filosofie. Quindi è inutile sdoppiare nodi, ma si devono estendere o crearne di nuovi partendo da padri. Drupal è un CMS ad oggetti!
Per lavoro ho dovuto creare 5 nuovi tipi di nodi: gare, contratti, telefoni, avvisi ed eventi. Capisci che sono 5 nodi che fanno le più svariate funzioni. Tutti sono figli del nodo, ma nessuno pesta i piedi all'altro, come nessuno pesta i piedi a qualsiasi altro modulo di drupal.....anzi.... essendo tutti e 5 figli del nodo, ne ereditano le proprietà così:
installato il modulo upload, questo lo posso attivare indistintamente su tutti (o su quelli che voglio), idem per tiny. La taxonomia, essendo proprietà dei nodo, è diventata anche proprietà dei miei nodi (ovviamente se l'attivo) e così pure per il nodo teaser..(non ricordo il nome), che permette di farmi il teaser personalizzato.... ma è così per tutto il resto. Se viene scoperto un bug sul nodo, non devo impazzire a variare 6 moduli.... semplicemente aggiorno drupal come ho sempre fatto.
Queste cose che scrivo, le ritrovi su un bellissimo documento di drupal che parla proprio del paradigma ad oggetti di Drupal (che ora non trovo perchè la ricerca non funziona).
IMO, è molto molto molto più probabile far grandi casini, sdoppiando il modulo node.module.... sia casini di gestione (nuovi aggiornamenti), sia casini di codice ridondante, sia casini che se nel modulo node.module, c'è un bug di sicurazza, quel bug è amplificato alla N.... sia casini nel senso che ti ritrovi N nodi di tipo uguale, il cui comportamento è condizionato da N moduli... ma quì, immagino che quando dici "sdoppiare" intendi anche creare una nuova tipologia di nodo..... e quì si ritorna sull'inutilità dello sdoppio
(a che serve creare una nuova tipologia e gestirla con N funzioni/api uguali?)
Ovviamente ogni uno la pensa come vuole, ma ci tenevo a dire la mia. Comunque scriverò una guida personale per dimostrare la semplicità e la flessibilità che il "paradigma ad oggetti" di drupal produce.
P.S.
Lo ridico e lo risottoscrivo a scanso di equivoci.... stimo molto Mavimo e i discorsi sopra li faccio con lui perchè lo ritengo un ottimo programmatore, con cui si può parlare anche di argomenti tecnici (invece dei soliti "mi da errore di memoria", "come si installa drupal" ecc... ecc...
senza offesa per nessuno.... che poi son le domade che abbiamo fatto tutti all'inizio)
Personalmente non ho altro da aggiungere..... ho fatto appositamente untesto lungo, per non tornarci sopra... non avendo altro da dire 
Ciao
Gianni
Mi sa che non ci siamo capiti 
Sono d'accordo con te al 10000%, se ho scelto Drupal è proprio per la modularità e la possibilità di sfruttare (almeno in parte) i paradigmi della OOP. Detto questo si parlava se convenisse sdoppiare il modulo node e fare le modifiche su questo piuttosto che andare a modificare direttamente il modulo node originale senza sdoppiarlo. IMHO è meglio andare a creare una copia del modulo node e agire su questo proprio per non andare a inficiare il corretto funzionamento del modulo ufficiale e i moduli che si appoggiano ad esso.
Se invece parliamo del fatto che non è necessario andare a creare una copia del nodo.. bhè sono d'accordo anche io, anche perché se è necessario creare un nodo a parte si possono andare ad utilizzare tanti hook per andare a modificare il comportamento (o meglio alcune funzionalità) del nodo base senza dover apportare modifiche al modulo originale (vedo form alter tanto per dirne una).
Scusa se torno un attimo su un punto che mi sta particolarmente a cuore, anceh se sono quasi certo di andare OT 
Drupal si basa su un concetto di OOp alquanto particolare, proprio per il fatto che non è veramente strutturato in classi. Sinceramente trovo la scelta operare con una simile strategia ha dei vantaggi, ovvero anche il primo che passa che conosce un pò il PHP ma non sa nulla dell'OOP nel giro di qualche giorno sa programmare e andare a crearsi un modulo, di contro porta a dei rallentamenti abbastanza vistosi su progetti molto ampi. Un utilizzo vero di classi sarebbe IMHO auspicabile, anche se ormai non ci spero nemmeno, inquanto si tratterebbe di riscrivere buona parte del core e mi sembra un lavoro immenso per la comunità. Un esempio banale dei vantaggi è l'uso delle funzioni di ereditarietà (e perché no anche eredità multipla
), che ora manca totalmente se non ricorrendo all'include più le chiamate alle funzioni, oppure il vero override delle funzioni. Usando classi template e virtual si arriverebbe ad avere una struttura dei moduli molto più razionale.
Lo scotto da pagare? Che uno deve avere veramente idea di quello che fa e non può buttare giù codice a casaccio (sinceramente quando vado a vedere il sorgente di alcuni moduli mi si accappona la pelle
). Ok, forse la mia visione è troppo deformata dal C++, ma credo che se si proseguisse verso una vera implementazione dell'OOP il balzo in avanti sarebbe notevole, visto che sarebbe anche il primo CMS a farlo 
[...cut] e agire su questo proprio per non andare a inficiare il corretto funzionamento del modulo ufficiale e i moduli che si appoggiano ad esso.No, ci siamo capiti, ma abbiamo visioni diverse 
Per me NON conviene mai sdoppiare un modulo del core. Al limite creo un nuovo tipo di nodo e metto lì la mia modifica. Vabbè, opinioni diverse o fraintendimenti (il brutto di chat e forum) 
Ovviamente non è OO, ne ha solo raccolto la visione.... ma è notevole come funziona 
Per la velocità hai ragione, ma purtroppo, proprio per sua natura, deve caricarsi tutti i moduli e su questi deve andare a lanciare le eventuali funzioni di hook.... se i moduli son tanti è un bel lavoro. Ci vorrebbe un sistema di razionalizzazione nel caricare i moduli ma è cosa assai difficile da fare seriamente. Riuscire ad evitare il caricamento dei moduli non utilizzati in quel momento.
Indubbiamente..... se l'OOP viene applicato ai concetti del cms.... tipo nodo = oggetto, taxonomia = oggetto e così via. Altrimenti preferisco tenermi drupal 
....ma la vedo dura pure io 
Ciao
Gianni
@luisasasi:
Hoilà, anche a me interessa molto la questione di accessibilità e posso garantirti che con drupal e pochissimi accorgimenti si raggiunge tranquillamente il WAI-A, per l'AA e AAA le cose si complicano non poco, ma i motivi sono sopratutto dati dal fatto che non esistono temi sviluppati appositamente con questi interessi, in ogni caso tienimi aggiornato sugli sviluppi, a settembre (quando reinizierò a insegnare) avrei intenzione di realizzare un sito scolastico basato su Drupal e anche da me ci sono parecchi disabili e quindi le funzionalità di accessibilità anche per non vedenti / disabili motori mi interessano molto.
@giannigiusti:
Per quanto riguarda la velocizzazione del caricamento moduli pare che ci si arriverà con la versione 7, quando verrà abbandonata la retrocompatibilità con PHP4 con conseguente pulizia di un sacco di funzioni "sporcate" dalla necessità di usare versioni di PHP vecchie. Un articolo al riguardo era uscito un pò di tempo fa nella HP di http://drupal.org, andando a vedere gli articoli vecchi dovresti trovarlo senza troppi problemi.
scusate, ma con:
<?php
print l('Leggi tutto...', '/node/'.$node->nid, array('title'=>$title));
?>non viene fuori la seguente frase nel link?:
Leggi tutto...
mentre lei non voleva far stampare così nel link?:
Leggi tutto verbale del xx.xx.xxxx
per cui dovrebbe scrivere, se non sbaglio:
<?php
print l('Leggi tutto '.$node->title, "node/$node->nid");
?>P.S.: Luisa, hai per caso qualche sito da farci vedere (sviluppato con drupal e pensato anche per persone diversamente abili)?
I problemi che incontro con l'accessibilità e drupal, sono sostanzialmente nel rendere i temi accessibili. Drupal in se e per se restituisce solo struttura e quindi, quindi queste son per forza di cosa accessibili (escludiamo un attimo il singolo modulo e le tabelle che meritano un discorso a parte). Per i temi, io parto sempre da Aberdeen o pushbutton. Poi mi son personalizzato tinyMCE, in modo che elimini tutti i tag non XHTML strict, in modo che il redattore possa scrivere xhtml strict in modo grafico..... il problema è che poi il redattore si scorda di gestire gli acronimi, a volte il testo alternativo e il tag title, utile per restituire uteriori informazioni sui link. Un problema grosso, per quanto stupido, è il tag target dei link.... in xhtml strict (il formato preferenziale della legge.... transizionale sarebbe tollerato solo in fase di transizione tra il vecchio sito ed il nuovo), la proprietà target NON è consentita.... per fare un apertura di una nuova pagina (oltre che segnalarla) è necessario usare javascript, il che è assurdo. Per questo ho tolto del tutto aperture di nuove pagine.
Attualmente stò correggendo una marea di problemi che mi son trascinato dietro dal vecchio sito (ho 700 pagine!!! e non è stato facile riconvertirle).... finalmente son riuscito a far capire al capo l'importanza di finire tutte quelle cose che abbiamo lasciato indietro nel passaggio dal vecchio al nuovo. Verso Novembre, vi mando il link al nuovo sito, reso il più possibile accessibile, con 5 moduli che si interfacciano ad un sito istituzionale provinciale, in cui confluiscono delle informazioni centralizzate da tutti i comuni della provincia.
Anch'io non amo cambiare completamente tema per i disabili. Per ovviare a ciò, ho usato un tema liquido, strict e con colori ad un contrasto visibile a tutte le problematiche di daltonismo..... e quì ho fatto i salti mortali per trovare colori che andavano bene al capo e che fossero abbastanza contrastanti in tutte le problematiche legate ai colori. Per i ciechi mi son preoccupato nel vedere che il sito scorresse perfettamente anche senza css ed ho aggiunto un icona per ingrandire i caratteri nel caso di cataratta (ad esempio).... ho inserito anche un link per l'alto contrasto, ma dovrebbe essere inutile a questo punto... poi, appena sarà on line vi mando il link.
Ora, per quanto riguarda la dichiarazione di conformità, mi sembra che molti siano molto larghi nel autodichiararsi. Ci son siti che non raggiungono AA e si autodichiarano AAA.... tutto perchè non esiste un ente di controllo statale sui siti periferici (non esiste un ente che controlla siti scolastici/comunali/provinciali ecc...). Quello dell'autodichiarazione è una buffonata..... e non parliamo di piccoli enti, ma anche grandi strutture, come alcuni grandi comuni che si autocertificano AAA.
P.S.
Se si può fare, io sarei molto favorevole nel proporre una sezione dove ogniuno posta variazioni del codice, aggiustamenti, trucchi e consigli su come rendere accessibile drupal.... ovviamente amministratori del sito permettendo 
Ciao
Gianni
Per Gianni
Sono d'accordo con te sull'attenzione agli acronomi, ai title e ai target e soprattutto a scegliere un tema fluido che si adatti allo schermo con font ingrandibili ( ems). Io ci tento. Per il lavoro che sto "cercando di fare" in www.nadiaciao.it ho scelto il tema garland e per renderlo fluido ho lavorato sul CSS.
Segnalatemi pure correzioni: ne farò tesoro.
Per una sezione particolare dove raccogliere "segnalazioni di accessibilità" ben venga, sarebbe un'ottima cosa. Sono disposta a raccogliere tutto in un tutorial da mettere a disposizione.
Grazie a tutti
Per quanto riguarda al questione dell'autocertificazione mi pare sia possibile autocertificarsi solo al livello A, per l'AA e AAA serve verifica da enti predisposti (che si ciucciano un bel pò di soldi, sito da un centinaio di pagine sui 4'000,00€). Ovvio che poi uno si può autodichiarare quello che vuole, ma se viene controllato mi pare si prenda anche multe non proprio trascurabili (ok, non ci sono enti di controllo preposti, che io sappia).
Per quello che riguarda i requisiti di accessibilità della legge Stanca il problema non è tanto il generare codice XHTML Strict, quanto seguire tutte le condizioni avvini, generare i fogli di stile aural, contrasto dei colori, layout decenti fatti con CSS che non diano grossi problemi e sopratutto testarne il funzionamento con persone effettivamente affette da disabilità (gli unici che possono dare una vera risposta sulla accessibilità e usabilità).
Per quanto riguarda al possibilità di creare una sezione apposita del forum ne parlerò con Psico e vediamo cosa dice, in ogni caso approvo in pieno 
Per giangiusti, hai pensato di usare un software per la conversioen del contenuto delle pagine in XHTMl strict e creare uno script per prelevare e reinserire i dati nel DB? ne esiste uno ottimo open source (momentaneamente mi sfugge il nome), che funziona veramente bene, l'avevo provato e anche passando i documenti di word esportati come HTML faceva una pulizia tremenda e dava codice pulito 
Tanto per sapere per rendere TinyMCE che fornisce soo XHTML valido intendi che ahi abilitato solo alcuni pulsanti o che hai fatto qualche modifica al codice per ottenere risultati decenti?
PS: siamo dannatamente OT nel topic, quindi per ora continuiamo qui, non appena verrà aperta una nuova sezione sposterò il tutto dall'altra parte, se invece non verrà aperta spezzerò in un altro topic.
__________________A me risulta, da un convegno a cui partecipai 3 anni fa, che l'ente può autocertificarsi (come avviene nel 90% dei casi sia A, AA o AAA)...... poi, il fatto che si appoggi a qualcuno perchè il sito non è sviluppato in casa, quella è un'altra storia. Tutto sommato con l'autocertificazione non fai altro che dichiarare punto per punto, il rispetto delle singole richieste (linee guida) della Stanca. Se hai un link o qualcosa che dice che le autocertificazioni su A e AA NON son valide, potresti inviarlo così me lo leggo? (visto che non è proprio un dettaglio) 
Si tratta di seguire la linea guida, rispettando quei punti (per fare un sunto breve) 
Anche perchè, fin quando si tratta di seguire le linee guida, sin tutti buoni a leggere, il problema è poi applicare alcuni punti, su Drupal. Altro problema è capire alcuni punti "legali" della stanca e non solo quelli tecnici (mi sembra che ci sia un po' di caos, in generale sul web)
Il problema è che il precedente sito si trovava su notes domino.... oltretutto una vecchia versione e non sapevo come recuperare le pagine sul suo DB. Sul sito di IBM, avevo trovato gli ODBC...... peccato che erano per versioni più aggiornate della mia. Comunque, facendo copia incolla e modificando a manina, son riuscito, insieme alla redazione del sito, a passare tutte le pagine e a correggerle quasi tutte.... col tempo poi aggiusteremo anche le ultime rimaste.
Ormai il sito è convertito..... ma mi mancano ancora alcune pagine di enti esterni a noi collegati. Che tu sappia, il software che mi accennavi, può prendere in entrata anche pagine da wget? stavo pensando "se imposto wget per scaricare le pagine a N livelli e queste le do in pasto a quel software, mi dovrei ritrovare pagine strict".... magari con link errati, ma per lo meno corrette dal punto di vista tecnico.
TinyMCE, restituisce XHTML.... il problema è che non è STRICT.... però..... puoi impostare dei filtri sia a livello di tag, sia a livello di proprietà (senza variare il codice).... in questo modo, ho deciso io i tag consentiti e quelli "vietati", pur mantenedo la barra standard di tiny. In poche parole il redattore usa tinyMCE con tutti i pulsanti che voglio, ma quando mette un immagine, un link o quant'altro, le proprietà scritte al suo interno, saranno solo quelle permesse da me.... nel caso di immagini ad esempio, può smanettare quanto vuole, ma le proprietà restituite saranno solo: alt,class,height,name,src,style,title,width (questo è solo un esempio).... cioè, le sole proprietà consentite. Per prendere l'esempio del target sui link.... per "ammazzarlo" ho messo qualcosa simile a:
$init['extended_valid_elements'] = 'a[href|name|title|onclick],';
Per far ciò, ho messo in template.php:
<?php
function phptemplate_tinymce_theme($init, $textarea_name, $theme_name, $is_running) {
switch ($textarea_name) {
// Disable tinymce for these textareas
case 'log':
case 'img_assist_pages':
case 'caption':
unset($init);
break;
// Force the 'simple' theme for some of the smaller textareas.
case 'signature':
case 'site_mission':
case 'site_footer':
case 'settings][access_pages':
$init['theme'] = 'simple';
unset($init['theme_advanced_toolbar_location']);
unset($init['theme_advanced_toolbar_align']);
unset($init['theme_advanced_path_location']);
unset($init['theme_advanced_blockformats']);
unset($init['theme_advanced_styles']);
break;
}
// FILTRA LE PROPRIETA E CANCELLA CIO CHE NON E' STRICT
switch ($theme_name) {
case 'advanced':
$init['extended_valid_elements'] = 'a[href|name|title|onclick],';
$init['extended_valid_elements'] .= 'table[],';
$init['extended_valid_elements'] .= 'img[alt|class|height|name|onclick|ondblclick|
onkeydown|onkeypress|onkeyup|onmousedown|onmousemove|
onmouseout|onmouseover|onmouseup|src|style|title|width]';
$init['theme_advanced_buttons3_add_before'] = 'tablecontrols,separator';
$init['plugins'] = file_exists(drupal_get_path('module', 'tinymce'). '/tinymce/jscripts/tiny_mce/plugins/drupalimage') ? 'drupalimage,table,emotions,print' : 'table,emotions,print';
$init['theme_advanced_buttons3_add'] = 'drupalimage,emotions,separator,print';
break;
}
// Always return $init; !!
return $init;
}
?>Ovviamente quello sopra è solo un esempio striminzito, copiato da un mio vecchio post.... attualmente non posso mandarti la versione aggiornata e rivista perchè non ho accesso ftp da casa al sito in questione.
P.S.
se decidi di adottare una soluzione simile, fammi sapre che, se desideri, potremmo condividere un elenco di $init['extended_valid_elements'] consentiti..... mano a mano che qualcuno ne aggiunge uno, lo posta. Così ci potremmo ritrovare un filtro abbastanza buono da usare per tutti i singoli pulsanti (tag) di tiny
Ciao
Gianni
Ho visto il sito, se non erro chiedi come aggiungere i simboli di pipe nel calendario del blocco.
Per una modifica del genere devi operare all'interno di event.module
<?php
function event_calendar_month($op, $stamp, $types = NULL, $terms = NULL) {
...
case 'block':
// create caption and navigation links
+ $caption = _event_nav($stamp, 'prev', 'block', $types, $terms) .' '. l('|'. t(gmdate('F', $stamp)) .' '. $year .'|', 'event/'. $year .'/'. $month .'/'. $day .'/month') .' '. _event_nav($stamp, 'next', 'block', $types, $terms);
$callback = 'event_render_day_single';
...
}
?>Sarebbe veramente utile 
Guarda, non ho sottomano nulla, ma prova a vedere ai link:
che sicuramente ne sanno di più di me, in particolare alla pagina:
http://www.pubbliaccesso.gov.it/logo/index.php
dovrebbe esserci tutta la procedura, se ti interessa AA e AAA forse ti conviene contattarli, e se lo fai tienici informati 
A memoria mi pare che solo enti accreditati diano la possibilità di avere certificazioni AA e AAA (per la WAI-A sci si può autocertificare). Era nata anche una associazione no-profit che era riuscita aad accreditarsi dove una serie di volontari (la magior parte diversamente abili e una parte di programmatori) controllavano gratuitamente i siti che venivano segnalati. Quando mi informai il tutto era composto da una decina di persone e ricevevano decine di richieste al giorno e quindi non ci stavano dietro, di conseguenza potevi aspettare settimane se non mesi prima di avere una risposta, non so se la cosa poi abbi preso piede o sia stata abbandonata, fattostà che non ne ho saputo più nulla, quindi mi fa poco sperare...
EDIT: Al link qui sotto trovi info riguardo gli enti accreditati, a quanto pare esistono ancora le associazioni ONLUS, ma credo che comunque siano a pagamento, dovranno giustificare le spese, così a occhio tengono dei disabili stipendiati (svolgendo così anche una funzione sociale) e gli fanno visitare i siti in questione dando così l'ok per la validazione. http://www.cnipa.gov.it/site/it-IT/Attivit%c3%a0/Elenco_valutatori_acces...
Si tratta di seguire la linea guida, rispettando quei punti (per fare un sunto breve) ;-)
Già, solo che seguire quei punti è alquanto problematico, infatti a parte quelli chiari che fanno parte del codice prodotto (tag, attributi, entità, ..) tutti gli altri sono abbastanza soggiettivi; hai voglia di dire che un certo tipo di contrasto di colore va bene, o che il layout è fluido e anche aumentando le dimensioni dei font va tutto bene.. o che è facilmente utilizzabile da persone affette da parkinson perchè i pulsanti del menu sono sufficientemente ampi e distanziati in modo che non si possa sbagliare per errore...
Tanto per fare un esempio banale, quanti hanno una distanza tra i link cliccabili dei menu ALMENO 0.3em e con margine di 0.5em? Ben pochi nonostante sia uno dei prerequisiti per la certificazione WAI-AAA (e forse anche per la AA)
Anche perchè, fin quando si tratta di seguire le linee guida, sin tutti buoni a leggere, il problema è poi applicare alcuni punti, su Drupal. Altro problema è capire alcuni punti "legali" della stanca e non solo quelli tecnici (mi sembra che ci sia un po' di caos, in generale sul web)
Bhè, il problema principale non è applicarli, ma capire esattamente cosa vogliono cosa che tuttora IMHO resta un mistero. Ci sono persone decisamente preparate e professionali che hanno contribuito a gettare le linee guida, nonché hanno contribuito a scrivere la legge (vedi Roberto Scano), che però i burocrati hanno pensato di rendere incomprensibili senza l'aiuto di un avvocato; In definitiva hanno trasformato un documento tecnico in un legge.. e secondo me chi deve capire cosa c'è scritto per metterlo in pratica ci ha perso 
Il problema è che il precedente sito si trovava su notes domino.... oltretutto una vecchia versione e non sapevo come recuperare le pagine sul suo DB. Sul sito di IBM, avevo trovato gli ODBC...... peccato che erano per versioni più aggiornate della mia. Comunque, facendo copia incolla e modificando a manina, son riuscito, insieme alla redazione del sito, a passare tutte le pagine e a correggerle quasi tutte.... col tempo poi aggiusteremo anche le ultime rimaste.
Ormai il sito è convertito..... ma mi mancano ancora alcune pagine di enti esterni a noi collegati. Che tu sappia, il software che mi accennavi, può prendere in entrata anche pagine da wget? stavo pensando "se imposto wget per scaricare le pagine a N livelli e queste le do in pasto a quel software, mi dovrei ritrovare pagine strict".... magari con link errati, ma per lo meno corrette dal punto di vista tecnico.
Si lo faceva, io l'avevo usato all'interno di uno scrpt bash per far validare un sito di un centinaio di pagine (statiche)... sai che proprio non ricordo il nome.. sto goglando ma non trovo nessun riferimento.. e non me lo sono sognato!!
mi pareva si chiamasse tinivalidator o qualche cosa del genere... in pratica prendeva una pagina qualsiasi e la trasformava in un albero completo secondo le speficiche XHTML (ovviamente non faceva miracoli, per esempio per l'alt delle imagini scriveva "immagine nomefile", ma meglio che nulla
)... un pò come fa FF prima di renderizzare la pagina, la trasforma in un XML completo e poi manda il tutto in pasto al motore grafico...
EDIT: trovato il progetto http://tidy.sourceforge.net/ cerca l'eseguibile compilato per la tua architettura e OS..
TinyMCE, restituisce XHTML.... il problema è che non è STRICT.... però..... puoi impostare dei filtri sia a livello di tag, sia a livello di proprietà (senza variare il codice).... in questo modo, ho deciso io i tag consentiti e quelli "vietati", pur mantenedo la barra standard di tiny. In poche parole il redattore usa tinyMCE con tutti i pulsanti che voglio, ma quando mette un immagine, un link o quant'altro, le proprietà scritte al suo interno, saranno solo quelle permesse da me.... nel caso di immagini ad esempio, può smanettare quanto vuole, ma le proprietà restituite saranno solo: alt,class,height,name,src,style,title,width (questo è solo un esempio)
[CUT]
Ovviamente quello sopra è solo un esempio striminzito, copiato da un mio vecchio post.... attualmente non posso mandarti la versione aggiornata e rivista perchè non ho accesso ftp da casa al sito in questione.
Ok, per ora grazie, ho capito cosa intendevi, ma per esmepio le immagini devono avere OBBLIGATORIAMENTE l'attributo alt, e finora non ho trovato il modo di costringere l'utente a inserirlo, così come non posso obbligare a mettere degli accesskey ai link e cose del genere, mi sa ceh per quello l'unico modo è andare a ravanare nel JS, ci avevo provato, ma è al di fuori delle mie capacità/tempo a disposizione 
Speravo di trovare qualche altro editor più customizzabile e sopratutto leggero, TinyMCE è un vero e proprio mattone, ma non avevo cavato fuori nulla (tra prodotti free), quindi resto in attesa che BUEditor prosegua con lo sviluppo 
Potrebbe essere una buona idea... prometto che appena (se mai riuscirò) avrò tempo mi dedicherò a fondo su questo, ma per ora proprio non se ne parla.. se però intanto vuoi cominciare tu 
Iscritto il: 06 Dic 06