@FDA si direi quella del menu.

Per chi trovasse la discussione interessante ci sono sviluppi anche su google plus.
*
Maurizio ZioPal*

Ho studiato la cosa e ho scoperto un po' di cose interessanti.

Partiamo da MetaGenerator, plugin SEO per Joomla 2.5
MetaGenerator implementa bene il rel=canonical sulle url del com_content, ma fa cilecca su queste:

demo.com/35

per il quale il route di Joomla riconosce l'articolo con id=35 e "lo inserisce nella Home"; MetaGenerator ci piazza un bel rel=canonical alla Home, questa sì una pazzia!

Rel canonical con Joomla 2.5 e MetaGenerator
Nella demo di un'installazione base di Joomla 2.5.20 l'articolo con id=35 ha questo URL SEF:

http://demo.com/using-joomla/extensions/components/content-component/article-category-list/35-professionals

Per questo url e per tutti quelli che seguono:

http://demo.com/using-joomla/extensions/components/content-component/35
http://demo.com/using-joomla/extensions/components/35blabla
http://demo.com/using-joomla/blabla/35

il link con rel=canonical inserito da MetaGenerator è sempre lo stesso:

<link href="http://demo.com/using-joomla/extensions/components/content-component/article-category-list/35-professionals" rel="canonical" />

Come detto sopra, MetaGenerator sbaglia invece per:

http://demo.com/35

e infatti ci mette questo:

<link href="http://demo.com" rel="canonical" />

che è ovviamente sbagliato, in quanto in demo.com/35 c'è l'articolo con id=35 e non certo il contenuto della Homepage.

Perché MetaGenerator sbaglia?
Io credo che lo sviluppatore abbia male interpretato la documentazione di Joomla!

Come determinare se l'utente visualizza la Homepage secondo la documentazione di Joomla
In docs . jooma. org c'è un articolo dal titolo "How to determine if the user is viewing the front page" con istruzioni aggiornate al 29 aprile 2013 valide per 1.0, 1.5, 2.5, 3.

Per Joomla 2.5 e 3 la documentazione prevede questo codice:

<?php
$app = JFactory::getApplication();
$menu = $app->getMenu();
$lang = JFactory::getLanguage();
if ($menu->getActive() == $menu->getDefault($lang->getTag())) {
        echo 'This is the front page';
}
else {
        echo 'Accueil';
}
?>

In pratica, la documentazione suggerisce di fare un confronto tra il menu attivo e quello di default: se coincidono allora l'utente è "sulla vista della Home", che non significa che si trovi in Homepage. Eppure la traduzione non è molto chiara, potrebbe anche significare: "Come determinare se l'utente sta visualizzando la Homepage".

La funzione isFrontPage di MetaGenerator
Lo sviluppatore di MetaGenerator ha preso sul serio la documentazione ed ha inserito una funzione nel codice del suo plugin:

function isFrontPage()
    {
       $app = JFactory::getApplication();
        $menu = $app->getMenu();
       $lang = JFactory::getLanguage();
       if ($menu->getActive() == $menu->getDefault($lang->getTag())) {
             return true;
        }
       return false;
    }

Evidentemente voleva individuare la Homepage e solo quella, ma non è andata così.
Comunque, prima di aggiungere la riga del link rel canonical all'head della pagina, ha aggiunto questa porzione di codice per trattare la Homepage:

if ($this->isFrontPage() && $usecanonical==0) {
       if($start!=''){
              $ucanonical = $sitedomain.JRoute::_('index.php').$start;
       } else {
              $ucanonical = $sitedomain;
       }
}

Andrebbe tutto bene se soltanto la funzione isFrontPage non restituisse true anche sulle url come demo.com/35

La variabile $ucanonical contiene infatti l'url da inserire nel link rel canonical, e quando isFrontPage restituisce true questa url è pari a $sitedomain ... un bel guaio:

if(isset($ucanonical) && $ucanonical!='')$document->addHeadLink( $ucanonical, 'canonical', 'rel', '' );

Come eliminare il falso rel canonical
Non possiamo stampare il rel canonical alla Home quando il contenuto è quello di un articolo, e questo soltanto perché la voce menu è quella di default.
Racchiudiamo allora l'istruzione di stampa del rel canonical in una If:

if (!(($this->isFrontPage()) && ($view=='article'))) {
      if(isset($ucanonical) && $ucanonical!='')$document->addHeadLink( $ucanonical, 'canonical', 'rel', '' );
}

Conclusioni
Non abbiamo risolto il problema completamente, poiché le url come demo.com/35 non hanno rel canonical che punta all'url "migliore" ... ma qual è l'url migliore?
Il problema è che l'articolo con id=35 potrebbe essere associato a più voci di menu: chi può stabilire quale sia l'url canonica?
Il mio parere è che il componente SEO/SEF (non può farlo un plugin) dovrebbe estendere le metadata options degli articoli per trattare situazioni di questo tipo, consentendo di inserire a mano un url canonica, eventualmente suggerita dal componente stesso "scandagliando" i menu.

Tutto questo in attesa di altri test, anche su Joomla 3.

Cosa ne pensate?

Francesco

Grandissimo complimenti, la cosa che non capisco è perchè non viene gestito con la pagina di errore 404, dopo tutto la pagina non esiste e quindi non capisco perchè se io cambio qualcosa nell'url la pagina viene caricata correttamente e viene messo il canonical.
Secondo me dovrebbero gestirla con il 404, ho anche scritto nel forum di Joomla.org ma praticamente nessuno ha risposto e mi ha dato una giustificazione.

Ciao Stefano,
secondo me ci sono due questioni: da una parte la separazione che c'è tra i dati e la loro presentazione, tipica del pattern MVC (Model-View-Controller); dall'altra il sistema di routing di Joomla.

Questa pagina in verità esiste:

http://demo.com/35

Maurizio parlava di rel canonical, tu invece sei per il 404?
Penso che il 404 si possa fornire in risposta con una modifica a MetaGenerator, ma il rischio è che si perdano alcune pagine in cui il rel canonical andrebbe bene.

Faccio una prova. Fatemi sapere se ci sono tipologie di url che vorreste trattare in un modo invece che in un altro (rel canonical, noindex, 404).

Francesco

Poi magari mi sbaglio ma se l'url corretto è:
www.miosito.it/verdura/patate-americane.html
e uno per un motivo strano mette www.miosito.it/verdura/patate-american.html
quella pagina non esiste e quindi la solzuione migliore dovrebbe essere la 404, il canonical andfrebbe usato in altri casi, tipo in un ordinamento dei prezzi in un e-commerce..... IMHO

Sono d'accordo con Riga. Secondo me se l'URL della pagina non esiste deve tornare 404.

Nel caso indicato da te Joomla fornisce il 404, perché non riesce a individuare l'articolo dal momento che ha a disposizione un alias diverso (nulla vieta che due alias differiscano per un unico carattere).

Gli URLs di cui parlavamo sopra, invece, hanno la seguente particolarità: presentano un numero all'inizio di un segmento, come questi:

http://miosito.it/verdura/43-patata
http://miosito.it/verdura/43americana
http://miosito.it/verdura/patata/43

Per tutti questi il sistema di routing identifica l'articolo con id=43, che potrebbe essere ad esempio quello delle patate americane, cioè quello che dovrebbe avere come canonica:

http://miosito.it/verdura/patate-americane

Non ho messo "html" alla fine per non creare una complicazione che gestisce comunque con il rewrite.

Il sistema di routing invece non identifica l'articolo con id=43 per queste URLs:

http://miosito.it/verdure/patate-american
http://miosito.it/verdire/patate43

In pratica l'identificazione dell'articolo tramite id avviene soltanto se il numero è all'inizio di un segmento dell'url, cioè dopo uno slash.

Maurizio Zio Pal parlava di rel canonical come soluzione preferibile: per alcuni casi io concordo, perché il contenuto principale è sempre lo stesso, ma ho anche dubbi per quei casi in cui il contenuto "non principale" pesa molto rispetto all'intero contenuto.

Bel dubbio.

@Juanin: intendi il 404 per tutte?

Mi aiutate per piacere a capire come devo rispondere per i diversi gruppi di URLs? Intendo 404, rel canonical, redirect o noindex.

Primo gruppo
In pratica queste tre pagine sono identiche:

http://miosito.it/verdure/patata-americana
http://miosito.it/verdure/43patata
http://miosito.it/verdure/43

perché l'articolo con id=43 è "immerso" nella vista generata dal medesimo menu, che è definito a partire dal segmento ../verdure/ .
Per il primo gruppo sopra mettereste 404 a tutte tranne la prima (che è l'"originale")? Oppure?

Secondo gruppo

http://miosito.it/verdure/blabla/43
http://miosito.it/verdure/blabla/43patata

Queste pagine sono identiche a quelle del primo gruppo se il segmento /blabla/ non definisce nulla, cioè se non è relativo a un menu esistente.
Per il secondo gruppo sopra mettereste 404? Oppure?

Terzo gruppo
Solo per questo esempio del terzo gruppo facciamo l'potesi che ci sia una categorizzazione su più livelli e che quindi la url "originale" sia miosito . it/verdure/patate/americana , cioè abbiamo un sottomenu legato alla sottocategoria "patate".

http://miosito.it/verdure/43
http://miosito.it/verdure/ciakciak/43americana

In pratica qui Joomla fornisce pagine molto simili, il più delle volte uguali (ma non è detto, dipende dai menu), e continua ad associare l'articolo con id=43 alla vista definita dal menu con segmento /verdure/ , eventualmente ignorando quel falso /ciakciak/ (che non esiste, come negli esempi del secondo gruppo non esisteva /blabla/ ... ribadisco però che le pagine sono nella maggiore parte dei casi identiche, e tuttavia queste ottenute inserendo segmenti che non esistono io le tratterei con 404).

Per il terzo gruppo sopra mettereste 404? Oppure?

Quarto gruppo

http://miosito.com/43
http://miosito.com/frutta/43

Questo URL è fastidioso perché il segmento di riferimento è quello che fa capo alla homepage, cioè il menu di default, e sono gli URLs per i quali MetaGenerator fornisce come rel canonical la Home nonostante il contenuto principale della pagina sia quello dell'articolo con id=43.

Per il quarto gruppo sopra mettereste 404? Oppure?

Attendo i vostri suggerimenti e grazie a tutti.
Francesco

Non conosco Joomla, ma se ad un URL corrisponde un ID univoco allora ha senso usare il canonical altrimenti no.

Insomma il discorso è questo:

Se american-patate ha id 43 e lo ha generato l'utente
e
american-pat non ha id allora american-pat va 404.

Se american-pat ha id perché la pagina è generata dall'utente e con lo stesso id 43 allora il canonical è corretto.

Se american-pat ha id 43 perché lo genera automaticamente Joomla creando alias ad cazzum secondo me non è corretto il canonical

Se ovviamente sono limitazioni di Joomla il canonical non fa male però va considerato che poi diventa più difficile per il webmaster leggere i log e i vari errori se tutte le pagine tornano un 200.
Magari il motore riesce a districarsi grazie ai canonical, ma il webmaster farà più fatica a scovare pagine linkate male e errori di altra natura.

Delle due se proprio Joomla non ce la fa quelli che dovrebbero essere errori autogenerati da Joomla li gestirei con 301 piuttosto che con canonical in modo che il webmaster possa comprendere che c'è un'anomalia.

Grazie Andrea!
Come sempre illuminante.
L'osservazione sui log è importante, a questo aspetto non avevo pensato.

Mi metto al lavoro, vediamo se sono da rottamare o tiro fuori qualcosa di decente.

Francesco

C'ho messo un'ora per rileggervi e vado pure di corsaaaaa....

Per me il problema è dato dal fatto che non si può sapere prima se l'URL è generata a cavolo, la mia risposta di fatti faceva il confronto tra 301 e canonical, se fossi sicuro che è un duplicato generato da joomla 301 tutta la vita, ma se viene generato per scelta in una diversa visualizzazione come faccio a capirlo:

http:// miosito.it/verdure/43americana
http:// miosito.it/verdure/ciakciak/43americana

Qui per me l'unica soluzione è il canonical, e ho l'impressione che per risolvere questo sia necessario puntare sul canonical piuttosto che rischiare di perdere un contenuto reindirizzato da 301. L'alternativa potrebbe essere la combinata con un componete SEF che permette di specificare per le pagine che ho creato volontariamente la URL canonica, però come si gestisce la precedenza? Comanda il componente SEF o il plugin che fa il redirect?

Maurizio ZioPal

In realtà basterebbe dare un'opzione post based dove si può fare overhide delle impostazioni generali e dunque disabilitare il 301 e mettere il canonical o viceversa.

Penso che sia un'esigenza di davvero poche persone fare quello che descrivi sopra Dexter quindi un pannello avanzato post based dovrebbe essere più che sufficiente.

Ho visto che questo post ha generato una valanga di commenti...
Io personalmente mi sono scoraggiato e ho passato 2 giorni interi a rifare il sito in wordpress, appena pubblicato.
Deluso da Joomla penso di spostare le future realizzazioni su wp.

Ciao a tutti e grazie per i tanti suggerimenti.

@altraimmagine said:

Deluso da Joomla penso di spostare le future realizzazioni su wp.

Ciao a tutti e grazie per i tanti suggerimenti.

Ciao altraimmagine.
Comprendo il tuo punto di vista.
Esprimo la mia opinione (parlo a titolo personale, magari altri non condividono).

Un utente si comporta come un imprenditore, inteso nel senso più ampio del termine, che per realizzare la propria impresa persegue l'obiettivo senza alcuna guerra di religione. Dunque fai bene a scegliere WP se questo facilita i tuoi processi abbattendo i costi e riducendo i rischi.

Chi difende Joomla, però, non lo fa per guerra di religione. Quello che alcuni provano a spiegare è che Joomla e WordPress differiscono totalmente, con WP che nasce come piattaforma di blogging e si sviluppa grazie a un'architettura semplice che consente di aggiungere funzionalità (le più varie, incluso l'e-commerce) senza che siano richieste competenze avanzate di programmazione.
A mio avviso questo è un punto di forza di WP, la vera causa del suo successo: un webmaster junior configura in maniera accettabile il proprio sito seguendo i consigli sull'installazione di plugin e le migliori opzioni da scegliere via pannello di controllo; uno sviluppatore junior crea un plugin semplice in 1 ora.

Questa semplicità si riflette anche sul lato tecnico, il codice del CMS. Alcuni sviluppatori non ci pensano proprio a invischiarsi con Joomla perché lo considerano un investimento oneroso che non porta ai risultati sperati (e a volte hanno ragione). Non si tratta di bravura, è proprio che il gioco non vale la candela. Il discorso è: se voglio fare una cosa per bene allora uso Python, Ruby on rails o mi sviluppo un CMS proprietario con un framework PHP che scelgo secondo esigenze e gusti, altrimenti tanto vale puntare su WordPress.

Per fortuna non tutti ragionano come questi sviluppatori, ma io non ho pregiudizi e ascolto tutti, tanto più che sono "prestato" all'informatica, quindi mi considero un umile operaio apprendista e nulla di più.

In WordPress ogni post ha il suo url: questo non è normale.
Un software come si deve garantisce la separazione tra il dato e la presentazione dello stesso: condannare a priori un post con una relazione uno-a-uno con un url è limitante. Perché allora funziona? Perché quello non è un dato qualsiasi ma un post di un blog, che per la SEO è bene che sia associato biunivocamente a un url.
Quello che quindi in generale non sarebbe l'ottimale, dal punto di vista dello scopo che si prefigge WP è ben fatto!
Il discorso che ho fatto è molto semplificato.

WP, Joomla & la SEO facile
Teoricamente io potrei creare 2 pagine tra loro molto diverse, con scopi differenti, sugli stessi dati, ovvero su quelli che noi chiamiamo in Joomla article e in WordPress post.

WP separa dati e presentazione a livello di template, ma quella è un'altra cosa ancora. Per separazione noi intendiamo qualcosa ad un livello di astrazione superiore, compatibilmente con il modello MVC e, non caso, Joomla ha un'architettura Model-View-Controller e WordPress invece no.

Joomla nasce come piattaforma web e non come blog. L'errore di chi sviluppa il core di Joomla a mio parere è stato di conservare queste potenzialità senza valutare lo scopo per il quale molti utenti avrebbero potuto scegliere il cms.

Il risultato di questa non-focalizzazione sull'obiettivo da parte del team di Joomla è che tanti utenti, che non sono programmatori ma webmaster o addirittura blogger, usando Joomla in maniera "limitata" (non come web application ma come piattaforma cms per un sito semplice, ad esempio un *corporate *con poche pagine e/o un blog, cosa che faccio anche io), incontrano tantissime difficoltà che con WordPress sono assenti o presenti in quantità minore.

A Joomla manca il suo Joost de Valk (lo sviluppatore di Yoast).

Le URLs "pazze" legate agli id articolo
Grazie a te ci stiamo confrontando e nei prossimi giorni potremmo ipotizzare una soluzione al problema.
Per renderla "non limitante" potrebbe essere un plugin che non scrive nel database: in questa maniera non verrebbe toccata la logica del routing, non verrebbero modificati i file esistenti (db incluso), non ci sarebbero eccessivi rallentamenti (tranne quelli non evitabili, perché il tempo di un redirect non si può annullare), non si avrebbero problemi di aggiornamento (al massimo disattivi il plugin).

Se volessimo "andare oltre" dovremmo pensare a un componente, perché è il solo modo per realizzare quelle opzioni "post based" suggerite da Juanin e a cui ho accennato anche io quando ho parlato di metadata options.

Al momento sono sul plugin: ho intercettato queste URLs e devo soltanto restituire il 404 not found.
Ieri pomeriggio mi sono fermato a questo, ma quando stampo il codice in alto nella pagina non riesco a "forzare" il code 404 da fare restituire.
Si tratta di un problema di PHP/server, sono evidentemente ignorante e mi serve una mano.
Ho aperto questa discussione sul ForumGT, se avete suggerimenti sono i benvenuti!

http://www.giorgiotave.it/forum/php-mysql/220467-ottenere-un-code-404-not-found-via-php.html

Francesco

Ciao FDA e grazie per le risposte e l'attenzione,
il mio non è un addio a Joomla, con il quale ho realizzato un centinaio di siti ma una scelta obbligata per il mio sito che fin quando era composto da 4 pagine flash era nei primi post della serp e oggi, nonostante abbia curato contenuti e impiegato lavoro, scende inesorabilmente.
Conoscevo il problema da tempo e mi ero documentato su alcuni forum in lingua inglese nei quali si scriveva che il problema della generazione folle di url sarebbe stato risolto con la 3.x.
Installata però la 3.3 ho ritrovato la stessa situazione, e questo è scoraggiante.
Nel frattempo nei webmastertool mi comparivano centinaia di pagine pazze che io rimuovevo con robots e strumenti vari.
Allora ho deciso di tagliare la testa al toro e di risviluppare il sito su wp (ieri pubblicato)

Mi pare incompresibile che un problema noto e grave si porti avanti di versione in versione.
Se riesci a risolvere questo problema ti do un bacio (virtuale)
Ciao

Scusa altraimmagine di che url pazze parli?
Guarda che quello di cui parliamo noi sono url che vengono create magari facendo prove di url non le crea Joomla da solo.
Se imposti bene i menu non ti crea nessuna url pazza

stefano

A proposito di contenuti duplicati, 404 e canonical, nella demo di Joomla! 2.5.20 questi due URL puntano allo stesso articolo (id=6):

/using-joomla/extensions/components/content-component/single-article
/parks-home

Basta assegnare qualche modulo diverso per creare queste situazioni. Forse per alcuni potrebbe essere comodo gestire le eccezioni.

Francesco