venerdì 10 ottobre 2025

Come tradurre le stringhe dei plugin? Ecco una soluzione definitiva

Vi è mai capitato di non riuscire a tradurre una stringa di un plugin Wordpress perchè la funzione _e() si trova all'interno di una funzione php non accessibile tramite un hook?

Sto sperimentando una soluzione molto efficace!

Ecco una classe per gestire le traduzioni dei plugin redirezionandole sul file .po del Vostro tema.

PHP
<?php
/**
 * Classe per reindirizzare le traduzioni WooCommerce al dominio del tema (myTheme).
 */
class MyTheme_Translations {

    /**
     * Dominio del tema da cui prendere le traduzioni.
     */
    private const THEME_DOMAIN = 'myTheme';

    /**
     * Domini di WooCommerce da intercettare.
     */
    private const WC_DOMAINS = [
        'woocommerce',
        'woocommerce-admin',
        'woocommerce-payments',
    ];

    /**
     * Inizializza i filtri.
     */
    public static function init(): void {
        add_filter('gettext', [__CLASS__, 'gettext'], 10, 3);
        add_filter('gettext_with_context', [__CLASS__, 'gettext_with_context'], 10, 4);
        add_filter('ngettext', [__CLASS__, 'ngettext'], 10, 5);
        add_filter('ngettext_with_context', [__CLASS__, 'ngettext_with_context'], 10, 6);
    }

    public static function gettext($translated, $text, $domain) {
        if (!in_array($domain, self::WC_DOMAINS, true)) {
            return $translated;
        }

        $alt = translate($text, self::THEME_DOMAIN);
        return ($alt !== $text) ? $alt : $translated;
    }

    public static function gettext_with_context($translated, $text, $context, $domain) {
        if (!in_array($domain, self::WC_DOMAINS, true)) {
            return $translated;
        }

        $alt = translate_with_gettext_context($text, $context, self::THEME_DOMAIN);
        return ($alt !== $text) ? $alt : $translated;
    }

    public static function ngettext($translated, $single, $plural, $number, $domain) {
        if (!in_array($domain, self::WC_DOMAINS, true)) {
            return $translated;
        }

        $alt = translate_nooped_plural([$single, $plural], $number, self::THEME_DOMAIN);
        return ($alt !== $single && $alt !== $plural) ? $alt : $translated;
    }

    public static function ngettext_with_context($translated, $single, $plural, $number, $context, $domain) {
        if (!in_array($domain, self::WC_DOMAINS, true)) {
            return $translated;
        }

        // _nx() gestisce plural + context.
        $alt = _nx($single, $plural, $number, $context, self::THEME_DOMAIN);
        return ($alt !== $single && $alt !== $plural) ? $alt : $translated;
    }
}

// Avvia la classe
MyTheme_Translations::init();

Cos'è e a cosa serve

La classe MyTheme_Translations reindirizza le traduzioni di WooCommerce al text domain del tema (myTheme). In pratica, se nel tuo tema hai file di traduzione (.po/.mo) con stringhe alternative, la classe fa in modo che WooCommerce usi quelle al posto delle sue predefinite—senza toccare i file di WooCommerce.

Come funziona

Aggancia i filtri di WordPress per la localizzazione: gettext, gettext_with_context, ngettext, ngettext_with_context.

Intercetta solo i domini: woocommerce, woocommerce-admin, woocommerce-payments (puoi configurarli in WC_DOMAINS).

Per ogni stringa intercettata:

  • prova a ritradurla usando il dominio del tema (myTheme);
  • se trova un’alternativa diversa, la restituisce;
  • altrimenti lascia la traduzione originale di WooCommerce (fallback sicuro).
  • Gestisce correttamente contesto e plurali (es. _nx()).

Perché è utile

In questo modo centralizzi gli override delle stringhe di WooCommerce (o di qualsiasi altro plugin) nel tuo tema (o child-theme), eviti di modificare o “forkare” i file di traduzione di WooCommerce e mantieni la compatibilità con aggiornamenti e supporti plurali/contesti perchè non sei costretto modificare il codice del plugin.

La costante WC_DOMAINS Non tocca stringhe di altri plugin/temi fuori dai domini elencati, naturalmente potete rinominarla come preferite e aggiungere i valori che volete.

Non cambia nulla se nel tema manca la traduzione alternativa.

Requisito fondamentale!

Il tema deve caricare il proprio text domain (es. load_theme_textdomain('myTheme', get_template_directory() . '/languages');).

Le stringhe da sovrascrivere devono essere presenti nei file /languages/myTheme-XX_YY.mo del tema.

Come usarla

Includi la classe (ad es. nel functions.php o in un piccolo plugin) e chiama MyTheme_Translations::init();.

Se usi un text domain reale diverso da myTheme, aggiorna la costante THEME_DOMAIN.

Un piccolo consiglio

Se hai problemi di performance con il tuo sito e cerchi un servizio di hosting che supporta sistemi di cache lato infrastruttura come Redis, Memcached o Varnish, ti consiglio questo servizio di hosting:

Load WordPress Sites in as fast as 37ms!

sabato 27 settembre 2025

Siti multilingua in Wordpress e performance

Wordpress non gestisce nativamente la funzionalità multilingua ma è possibile realizzare il sito vs sito in più lingue utilizzando vari approcci differenti:

Approcci possibili

  1. Multisite (una installazione per lingua)
    Crei un network WordPress e un “sito” per ogni lingua (es. example.com/itexample.com/en).
    Pro: isolamento pulito dei contenuti, performance prevedibili, permessi separati, plugin/tema configurabili per lingua.
    Contro: manutenzione più articolata (backup, utenti, plugin), relazioni tra contenuti manuali se non supportate da plugin dedicati.

  2. Plugin multilingua su singolo sito
    Tutte le lingue convivono nella stessa installazione. Opzioni più diffuse:

    • Polylang: leggero, ottimo per blog/siti corporate; estensione a pagamento per WooCommerce.

    • WPML: completo, include traduzione stringhe, media, workflow; più “pesante”.

    • TranslatePress: traduzione visuale dal front-end, supporto MT (da rivedere/redigere).
      Pro: una sola installazione da gestire, linking tra traduzioni semplice.
      Contro: lock-in da plugin, possibili impatti su performance in siti molto grandi.

  3. Multisite + plugin di collegamento (es. MultilingualPress)
    Ibrido: benefici di Multisite con collegamento “nativo” tra versioni tradotte.
    Pro: scalabilità, nessun contenuto duplicato nel DB di un solo sito.
    Contro: costo/licenza, setup più tecnico.

  4. Headless/Jamstack
    WordPress solo come CMS; front-end (Next.js/Nuxt) gestisce i18n.
    Pro: massima libertà su UX/performance, routing i18n su misura.
    Contro: richiede team con competenze da sviluppo front-end moderno e DevOps.


Come scegliere (decision quick-guide)

  • Sito piccolo/medio senza e-commerce: Polylang o TranslatePress.

  • Sito complesso o con molto flusso redazionale: WPML (workflow, TM, stringhe).

  • Portale enterprise o network di brand/paesi: Multisite (con o senza MultilingualPress).

  • Team con skill React e focus performance/SEO avanzata: Headless.


Struttura URL e SEO internazionale

  • Struttura consigliata: sottocartelle per lingua (/it//en/, …). In alternativa sottodomini (it.example.com) o domini ccTLD. Mantieni una sola strategia ovunque.

  • hreflang: obbligatorio per evitare contenuti duplicati tra lingue e far capire a Google la variante corretta. I plugin citati lo gestiscono; verifica anche la versione “x-default”.

  • Sitemap per lingua: meglio separare ed elencarle in robots.txt.

  • Slug, title e meta tradotti: non lasciare slugs inglesi su pagine italiane e viceversa.

  • Redirect iniziale per lingua del browser: se lo usi, fallo solo alla prima visita, salva preferenza (cookie) e non indicizzare la pagina di redirect.

  • Contenuti davvero localizzati: evita traduzioni “letterali”; adatta esempi, misure, valute, date.


Note per WooCommerce

  • Lingua ≠ valuta: valuta, tasse e spedizioni possono variare per paese, non solo per lingua. Valuta e tasse vanno gestite con plugin specifici (multi-currency, geolocalizzazione).

  • Prodotti e attributi: traduci titoli, descrizioni, attributi e termini (paio/pack, taglie, materiali).

  • URL prodotto e categorie: traduci slug e ricontrolla i 301 se cambi struttura.

  • Email transazionali: predisponi template per lingua (ordine, spedizione, resi).

  • Ricerca e filtri: assicurati che l’indice (es. Elastic/Algolia) sia separato per lingua o includa il campo lingua nei documenti.


Workflow di traduzione

  • Glossario e guida di stile per coerenza terminologica.

  • Processo a step: bozza → traduzione → revisione → QA (link, moduli, formati numeri/date).

  • Stringhe di tema/plugin: usa .po/.mo (Loco Translate) o il modulo “String Translation” del tuo plugin i18n.

  • Media: valuta se duplicare o riutilizzare; in molti casi le stesse immagini bastano, ma cura i testi ALT per lingua.


Performance e caching

  • Cache per lingua: varia la cache per path (/it//en/) e per cookie se usi redirect alla prima visita.

  • CDN: regole di purge e invalidation consapevoli della lingua.

  • Ricorda il Vary: evita di variare su Accept-Language lato server quando non serve, per non esplodere la cache.


Checklist di avvio rapido

  1. Scegli struttura URL e plugin/architettura.

  2. Definisci lingue, glossario e stile.

  3. Imposta hreflang, sitemap per lingua e meta.

  4. Traduci menu, widget, footer, form, email.

  5. Traduci slugs e controlla i 301.

  6. Configura cache/CDN per lingua.

  7. QA completo (contenuti, moduli, pagamenti, ricerca).

  8. Monitora Search Console per ogni lingua/property.


Errori comuni da evitare

  • Mescolare sottocartelle e sottodomini senza motivo.

  • Lasciare meta/slug non tradotti.

  • Redirect forzato ad ogni visita (esperienza pessima + problemi di indicizzazione).

  • Non separare la cache per lingua.

  • Affidarsi solo alla MT senza revisione umana.


Performance

Un unico sito multilingua rispetto ad un'installazione network può creare problemi di performance, soprattutto se sono installati altri plugin (Woocommerce, Advanced Custom Fields, etc..) per questo consiglio di valutare bene prima di effettuare una scelta o si dovrà ritornare sui propri passi.

Nel caso il sito diventi molto lento sarà opportuno, se non è possibile ottimizzare il codice, ricorrere a dei sistemi di cache (Memcached, Redis, Varnish su tutti).

Un servizio di hosting che supporta tutti questi servizi elencati sopra è Cloudways, vivamente consigliato!

Load WordPress Sites in as fast as 37ms!

Usare i file pot/po per tradurre le stringhe del sito

La traduzione delle stringhe del vostro sito web Worpress è basata su un formato noto come gettext, il codice dichiara una stringa e un text domain; a runtime WordPress cerca la versione tradotta nei file .mo per la locale attiva (es. it_IT).

Ciclo di vita di una stringa

  1. Marcatura nel codice → usi le funzioni gettext.
  2. Estrazione → generi un file .pot (template) con tutte le stringhe.
  3. Traduzione → crei i .po per ogni lingua a partire dal .pot.
  4. Compilazione → i .po diventano .mo (binari veloci).
  5. Caricamento → WordPress carica i .mo del tuo text domain.
Queste stringhe vengono tradotte tramite delle funzioni php.

Marcatura nel codice (PHP)

Le funzioni principali:

__( 'Testo', 'mio-dominio' );              // restituisce la stringa
_e( 'Testo', 'mio-dominio' );              // echo diretto
_x( 'Testo', 'contesto', 'mio-dominio' );  // con contesto
_n( '1 articolo', '%s articoli', $n, 'mio-dominio' );     // plurali
_nx( 'file', 'file', $n, 'contesto', 'mio-dominio' );     // plurali + contesto

// Sempre con escaping adeguato:
esc_html__( 'Testo', 'mio-dominio' );
esc_attr__( 'Testo', 'mio-dominio' );

Come generare i file

Poedit

Per generare/gestire questi file è necessario utilizzare dei software appositi, uno di questi è Poedit, questo software ha una interfaccia visuale tramite cui gestire 



Loco Translate 

Esiste anche un utile plugin, Loco Translate (per tradurre le stringhe, non i contenuti)

Loco Translate non è un plugin multilingua: serve a tradurre le stringhe di tema e plugin (menu, etichette, messaggi, email) tramite file .po/.mo e .json per gli script. È ideale per coprire testi dell’interfaccia non gestiti dai plugin i18n o per rifinire la terminologia.



La mia scelta: WP-CLI e un po' di BASH

Personalmente preferisco un approccio programmatico tramite WP-CLI e bash scripting.

Ecco un esempio di uno script che sto usando in questi giorni per un tema personalizzato:

#!/usr/bin/env bash
set -e  # interrompe lo script se un comando fallisce

source ~/.bashrc
LANG_PATH="$MYTHEME_THEME_PATH/languages" #cartella con i file delle traduzioni
POT_FILE="$LANG_PATH/mytheme.pot" # file del template generato 
PO_FILE="$LANG_PATH/it_IT.po" #file con le traduzioni da inserire

# 1. Genera il template .pot dal tema
wp i18n make-pot "$MYTHEME_THEME_PATH" "$POT_FILE" --exclude=node_modules,vendor,tests --domain=mytheme

# 2. Se non esiste già il .po, inizializzalo
if [ ! -f "$PO_FILE" ]; then
  msginit --no-translator --locale=it_IT --input="$POT_FILE" --output-file="$PO_FILE"
fi

# 3. Aggiorna il .po con le nuove stringhe dal .pot
msgmerge --update "$PO_FILE" "$POT_FILE"

# 4. Compila i .mo
wp i18n make-mo "$LANG_PATH"

Lo script scansionerà quindi la vostra cartella verificando la presenza di stringhe relative al vostro tema e genererà i file dove potrete inserire le traduzioni.
Lanciandolo nuovamnete sarà anche generato il file mo. (quello che viene effettivamente letto da Wordpress per la traduzione) basato sulle traduzioni inserite nel .po.


Soluzioni Multilingua

In questa pagina ho scritto un articolo sui possibili approcci di un sito multilingua e dei relativi problemi di performance. Se vi dovessero capitare vi consiglio di rivedere il codice del Vs. sito ed i plugin che state usando. Se proprio non potete cambiare nulla potete appoggiarvi ad un hosting che supporti efficaci servizi di hosting, io uso questo:


Load WordPress Sites in as fast as 37ms!

mercoledì 14 ottobre 2015

Attivare VirtueMart SEO senza utilizzare il suffisso nella pagina del dettaglio

Dalla versione 1.0 di Joomla! è consuetudine considerare Virtuemart l'estensione per fare e-commerce per eccellenza.

Oggi ci sono moltissime alternative (più o meno valide) ma VM ha indubbiamente ancora la community più forte, in particolare qui in Italia. Rispetto al passato è anche meglio integrato in Joomla! e dalla versione 2 è anche MVC e gestisce i campi come plugin per Joomla, cosa non trascurabile.

Al di là di questo VM ha ancora alcuni limiti che gli fanno preferire altri componenti o altre piattaforme.

Uno di questi limiti è la gestione delle url SEO. Infatti le impostazioni SEO impongono l'utilizzo di un suffisso alla pagina di dettaglio del prodotto (con il valore predefinito detail).

Ovviamente questo in taluni casi può non essere accettabile, soprattutto se si devono preservare delle vecchia e URL.

Nel caso non venga impostato un suffisso le opzioni SEO non funzioneranno.
L'unico modo di risolvere sarà quindi l'utilizzo di ulteriori componenti che permettano la riscrittura completa dell'url.

venerdì 9 ottobre 2015

MySQL non fa più accedere l'utente ROOT

Non riesco più a accedere a MySQL

Può capitare che la password di root di MySQL non funzioni più o che semplicemente sia stata smarrita.

Al di là della classica domanda iniziale "Perchè!?" quella di cui vi preoccuperà nei minuti successivi la scoperta sarà "che fare????"

In questo post cercherò di fornire una risposta efficace alla seconda, lasciando a voi il piacere (!) di scoprire la risposta alla prima.

Reimpostare la password di root di MySQL

Per reimpostare la password di root di MySQL è sufficiente eseguire la stessa operazione che fate quando reimpostate quella del Vs. CMS preferito: tramite una query.

Se nel caso di Wordpress, Drupal, Joomla, Magento o altro CMS che dir si voglia, basta accedere a phpMyAdmin o, per gli amanti del nero, alla riga di comando del terminale, per eseguire l'UPDATE di un campo, qui la situazione è apparentemente drammatica, perchè non si riesce ad accedere proprio alle tabelle i MySQL.

E' però possibile avviare MySQL senza i permessi (GRANT) per cui il problema "password" viene bypassato e sarà possibile eseguire la query di update per il reset della password.

Inutile dire che l'operazione NON VA ESEGUITA su di un server di produzione quando è accessibile da altri utenti.

Vediamo quindi i passaggi da eseguire da terminale:

1) fermate il servizio MySQL, su Debian / Mint / Ubuntu:
sudo service mysql stop
2) avviate MySQL disabilitando le GRANT sulle tabelle:
sudo mysqld --skip-grant-tables
non apparirà nessun prompt dei comandi, non potrete quindi aggiungere altri comandi e la schermata sembrerà bloccata. E' NORMALE

3) aprite una nuova istanza del terminale.

4) avviate mysql:
mysql start
5) selezionate il database di sistema di MySQL:
use mysql
6) eseguite una query di update:
update user set password=password('lamiapasswordsupersicura') where user='root'
A questo punto potrete accedere nuovamente con l'utente root utilizzando la password che avete impostato, "lamiapasswordsupersicura" nel caso abbiate fatto copia/incolla della riga qui sopra.

Ora che potete di nuovo accedere ai vostri dati, avete tutto il tempo per tornare ad interrogarvi sull'origine del problema.

Per saperne di più leggete questo post nel forum di Ubuntu

mercoledì 7 ottobre 2015

Alcuni semplici ma utili script per Joomla!

Ottenere il nome del template corrente di Joomla!

Questo script può tornare utile quando si sta scrivendo il percorso di un css su Joomla e lo si sta caricando tramite il metodo addStylesheet() di JDocument.

Ottenere il prefisso delle tabelle indicato nella configurazione in Joomla!

Questo script (da usare solo in debug) è particolarmente comodo quando si fa scrive la query di un modello nell'output della pagina e lo si vuole incollare in phpMyAdmin o Heidi per eseguire la query, in questo modo eliminerete gli antipatici cancelletti.

Caricare un modulo di Joomla con il codice

Con questo script potrete caricare all'interno di qualsiasi file un modulo di Joomla! Vi consiglio di impostare la visibilità del modulo su Tutte le pagine e assegnare come posizione un non nome dedicato (in questo Gist "statistics"), in questo modo il modulo comparirà solo nelle pagine dove avrete inserito il codice.

Effettuare il dump di un DB Joomla senza accedere a phpMyAdmin

In questo caso al posto del Gist inserisco direttamente il link allo script su GitHub.
Basta copiarlo sulla root e lanciare lo script dalla barra dell'indirizzo, creerà automaticamente il dump in una cartella dedicata sulla root.

Provatelo e commentatelo su GitHub!

mercoledì 30 settembre 2015

Cosa aspettarsi di Joomla 3.5 e Joomla 3.6

Le novità di Joomla 3.5

La release 3.4 di Joomla risale ormai allo scorso febbraio ed è ormai iniziata la roadmap per la nuova versione 3.5

Le idee sono tante vedremo quali saranno poi le nuove features effettivamente rilasciate :-)

Secondo l'articolo di Steve Burge di OSTraining.com questa è un'anteprima attendibile basata su (questa roadmap):

Override di tutto in Joomla 3.5

Uno degli obiettivi chiave di Joomla 3.5 è che tutto possa essere sovrascritto.

Lo strumento per raggiungere questo obiettivo sarà, nelle intenzioni del team di sviluppo, di JLayout, (per saperne di più vedi questo articolo
https://www.ostraining.com/blog/joomla/custom-layouts/), ma potrebbero essere utilizzti altri strumenti come i motori di rendering PHP Laravel Blade o Twig.

Il solito problema sarà la retrocompatibilità, vogliamo scommettere?

Eliminazione dal core del componente com_messages

Il progetto di rimozione dei componenti dal core toccherà questa volta com_messages, che si potrà comunque scaricare dal proprio repository su Github

Nuovo media manager per Joomla 3.5

Il nuovo media manager includerà queste funzionalità:

  • nuova interfaccia grafica (anche l'occhio vuole la sua parte)
  • un upload manager 
  • tagging delle immagini
  • funzioni più potenti per l'editing delle immagini 

Ecco alcuni screeshot:



Nuovo sistema di Routing

E' nella lista delle cose da fare da molto tempo ed è stato oggetto di una campagna di crowd funding lo scorso anno. Un po' del codice realizzato è stato condiviso su GitHub (vedi qui le commit).
C'è ancora molto da fare, ma ci sono dei progressi.

Novità di Joomla 3.6?

Effettivamente il post è focalizzato soprattutto su Joomla 3.5. ma speriamo di vedere l'implementazione di un'API REST dalla release 3.6, ecco la roadmap.

Per le novità più prossime attendiamo il JoomlaDay di Firenze, di cui al momento non è ancora disponibile il programma

mercoledì 9 settembre 2015

Ottimizzare il file robots.txt per Magento

robots.txt per la SEO di un e-commerce Magento

Il file robots.txt è molto importante per l'indicizzazione del tuo e-commerce Magento.

Tramite questo file è possibile "istruire" corretamente i crawler dei motori di ricerca per una corretta indicizzazione dei file del tuo sito web.

Puoi escludere cartelle, includerne altre e dare ulteriori informazioni per la lettura del sito.

In pratica i benefici ottenibili sono 2:

  • Evitare l'indicizzazione di contenuti duplicati;
  • Nascondere i file e le cartelle relativi a contenuti "tecnici" (repository .git, cartella admin, etc..)
Ecco un esempio di un file robots.txt per Magento opportunamente commentato:


## IMPOSTAZIONI GENERALI
## Abilita le regole del robots.txt per tutti gli spider dei motori di ricercaUser-agent: *
## Parametro Crawl-delay: il numero di secondi di attesa tra una richiesta e l'altra allo stesso server## Questo parametro è molto utile per ridurre la frequenza delle richieste dei crawler, che talvolta possono creare problemi di traffico al server.Crawl-delay: 30
## Sitemap: inserisci l'indirizzo della sitemap del tuo sito webSitemap: http://www.miosito.com/sitemap/sitemap.xml
## IMPOSTAZIONI PER SITI IN SVILUPPO
## Non navigare le cartelle dei repository (CVS, snv, .git, etc..), gli ambienti di sviluppo (phpStorm, Netbeans, etc..) e i dump del db (.sql, tgz, etc..)Disallow: /CVSDisallow: /*.svn$Disallow: /*.idea$Disallow: /*.sql$Disallow: /*.tgz$Disallow: /*.git$
## LE IMPOSTAZIONI PRECEDENTI SONO GENERALMENTE VALIDE ANCHE PER ALTRE PIATTAFORME COME JOOMLA, DRUPAL, ETC..

## IMPOSTAZIONI DI MAGENTO

## NON NAVIGARE LA CARTELLA ADMINDisallow: /admin/
## NON NAVIGARE LE CARTELLE DI SISTEMA DI MAGENTODisallow: /app/Disallow: /downloader/Disallow: /errors/Disallow: /includes/Disallow: /lib/Disallow: /pkginfo/Disallow: /shell/Disallow: /var/
## NON NAVIGARE I FILE DI SISTEMA DI MAGENTODisallow: /api.phpDisallow: /cron.phpDisallow: /cron.shDisallow: /error_logDisallow: /get.phpDisallow: /install.phpDisallow: /LICENSE.htmlDisallow: /LICENSE.txtDisallow: /LICENSE_AFL.txtDisallow: /README.txtDisallow: /RELEASE_NOTES.txt
## MIGLIORAMENTI ALLA SEO DI MAGENTO
## NON NAVIGARE LE PAGINE DELLE SOTTOCATEGORIE CHE VENGONO FILTRATE O ORDINATEDisallow: /*?dir*Disallow: /*?dir=descDisallow: /*?dir=ascDisallow: /*?limit=allDisallow: /*?mode*
## NON NAVIGARE IL DUPLICATO DELLA HOME SU INDEX.PHP. QUESTA IMPOSTAZIONE VA INSERITA SOLO SE E' STATA IMPOSTATA L'OTTIMIZZAZIONE SEO DEGLI URL DI MAGENTODisallow: /index.php/
## NON NAVIGARE I LINK CHE CONTENGONO L'ID DI SESSIONEDisallow: /*?SID=
## NON NAVIGARE NELLE CARTELLE Do not crawl checkout and user account pagesDisallow: /checkout/Disallow: /onestepcheckout/Disallow: /customer/Disallow: /customer/account/Disallow: /customer/account/login/
## NON NAVIGARE PAGINE DI RICERCA E PAGINE DEL CATALOGO NON OTTIMIZZATE PER LA SEODisallow: /catalogsearch/Disallow: /catalog/product_compare/Disallow: /catalog/category/view/Disallow: /catalog/product/view/
## IMPOSTAZIONI DEL SERVER
## NON INDICIZZARE FILE E CARTELLE DI SISTEMA DEL SERVERDisallow: /cgi-bin/Disallow: /cleanup.phpDisallow: /apc.phpDisallow: /memcache.phpDisallow: /phpinfo.php 
## NON INDICIZZARE LA PAGINA 404
Disallow: /404/

Per attivare queste opzioni puoi copiare e incollare le istruzioni che trovi qui sopra in un file, nominarlo come robots.txt e inserirlo nella root del tuo sito Magento

Per saperne di più:
http://www.robotstxt.org/

sabato 10 gennaio 2015

Comandi utili da terminale su Debian / Ubuntu / Mint

Lista di comandi utili per ottenere informazioni da termina su un web server LAMP (Linux Apache MySQL PHP)



Nell’ordinaria amministrazione di un server web vengono utilizzati vari comandi ed istruzioni da eseguire su terminale per ottenere informazioni e/o compiere rapide operazioni su cartelle e file.


Presento di seguito i più comuni, spesso determinanti per risparmiare tempo su un server di sviluppo, vanno utilizzati con cautela su un server in produzione, magari solo per ottenere delle informazioni veloci e poi contattare l’amministratore di sistema. Ovviamente, se siete voi l’amministratore di sistema, dovreste già conoscerli e la lista di seguito può essere utile solo per un veloce ripasso. Le istruzioni sono state testate su un server Debian / Ubuntu / Mint


sudo -s
Accedi come amministratore (non ti sarà nuovamente richiesta la password)


du -h
Mostra la dimensione di tutte le sottocartelle della cartella corrente


du -h --max-depth=1
Mostra la dimensione di un livello di sottocartelle della cartella corrente. Se l’output è troppo lungo si può usare du -h --max-depth=1
-s è un’opzione che sta per “summarize”, mostra quindi solo la lunghezza

du -a /var | sort -n -r | head -n 10
Mostra le 10 cartelle più grandi presenti sul sistema

truncate -s 0 /path/to/log.log
Pulire un file log


Miniguide
Sono sequenze di operazioni semplici che sono utili in diverse situazioni.

  1. Vai alla directory dei log di Apache


cd /var/log/apache2/


  1. Rimuovi tutti i file


rm -rf /var/log/apache2/*


  1. Ricarica apache

service apache2 reload

domenica 4 gennaio 2015

Magento mettere offline un sito web proteggendo la SEO

Come mettere off-line un sito realizzato con Magento?

Dovete aggiornare il Vs. sito web Magento e avete la necessità di metterlo off-line per qualche tempo finchè lo modificate?


Una prima soluzione potrebbe essere “spegnerlo” e mettere una pagina di sito in costruzione, scaricare il sito in locale e poi rimetterlo on-line quando le modifiche sono state effettuate. In questo caso però, oltre agli ordini inevitabilmente persi, potrebbero esserci degli altri effetti collaterali, primo fra tutti la SEO del sito.


Google & colleghi, infatti, non trovando più le pagine del sito (se ricevono un errore 404) potrebbero decidere di penalizzarle e perderebbero quindi qualche posizione nelle SERP.

Utilizzare un errore 503

La soluzione può essere quindi di creare una pagina con errore 503 con questo codice:


<?php
header('HTTP/1.1 503 Service Temporarily Unavailable');
header('Status: 503 Service Temporarily Unavailable');
header('Retry-After: 300);
?>


in questo modo gli header inviati agli spider dei motori riceverebbero il messaggio di errore 503 e di ritornare dopo 300 secondi (generate questo valore dinamicamente in modo da stabilire un tempo di rimessa on-line del sito accettabile).

Utilizzare la pagina errore 503 di Magento

In Magento 1.4 e successivi è stata introdotta una gestione nativa degli errori 503 in modo da poter mettere il sito in mantainance mode.


Si tratta di una funzione molto utile perchè mantiene attivi tutti gli url del sito restituendo un erorre 503.


Per attivare la pagina è sufficiente inserire un file maintainance.flag nella root del sito web, non è importante il contenuto del file, basta che esista.

Personalizzare l’aspetto della pagina 503 di Magento

La pagina di errore 503 viene impostata in base ad un file specifico che si chiama 503.phtml e si trova nella cartella /errors/default (qui troverete anche i file e gli stili della pagina).


Potete quindi mostrare la grafica più adatta al design del vostro sito web e tutte le customizzazioni utili per ottenere una adeguata personalizzazione dei contenuti della Vostra pagina di errore 503 su Magento.


Gestione avanzata della pagina 503 e accesso per l’amministratore (o altri utenti specifici)

Mentre in sito è in mantenimento alcuni utenti potrebbero avere la necessità di accedere comunque (testers e sviluppatori).


Per fare questo è possibile utilizzare questo codice:


//definisco  un array di ip autorizzati
$ip = $_SERVER['REMOTE_ADDR'];
$allowed = array('127.0.0.1','89.23.233.10'); // these are the IP's that are allowed to view the site.


poi cambiare la linea del codice


if ( file_exists($maintenanceFile) ) {


in


if (file_exists($maintenanceFile) && !in_array($ip, $allowed)) {


in questo modo se il file maintainance.flag viene trovato e l’ip dell’utente non è compreso nella lista $allowed il sito va in mainanance mode, restituisce quindi un errore 503.


SEO blackhat


Potreste rendere l’accesso libero ai motori di ricerca mentre il sito è in maintainance mode, in questo modo non esisterebbe neanche la necessità di gestire un errore 503 - agli utenti non interessa gran che se è un 404 o un 503, in genere guardano solo il contenuto della pagina :-)


Si tratta però di una tecnica rischiosa perchè se i motori di ricerca si accorgono dell’utilizzo di tecniche di Cloaking possono decidere di bannare il dominio con danni notevolmente maggiori rispetto ai vantaggi ottenibili.


Cambiare la pagina di errore 503


La formattazione della pagina 503 standard di Magento potrebbe non essere coerente con il design del Vostro sito web, quindi potrebbe servire una customizzazione più radicale.


Per ottenere questo si può modificare la seguente riga della pagina index.php di Magento:


include_once dirname(__FILE__) . '/errors/503.php';


in


include_once dirname(__FILE__) . '/503/index.php';

quindi potete inserire nel codice della pagina index.php (contenuta in una cartella 503 che si trova sulla root) il codice che preferite.