® Davide Taddei - programmatore esperto CMS / PHP / Wordpress

Come tradurre le stringhe dei plugin? Ecco una soluzione definitiva

2025-10-10T17:47:00.040+02:00

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:

Siti multilingua in Wordpress e performance

2025-09-27T17:41:00.005+02:00

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

Approcci possibili

Multisite (una installazione per lingua)
Crei un network WordPress e un “sito” per ogni lingua (es. example.com/it, example.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.
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.
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.
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

Scegli struttura URL e plugin/architettura.
Definisci lingue, glossario e stile.
Imposta hreflang, sitemap per lingua e meta.
Traduci menu, widget, footer, form, email.
Traduci slugs e controlla i 301.
Configura cache/CDN per lingua.
QA completo (contenuti, moduli, pagamenti, ricerca).
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!

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

2025-09-27T17:28:00.005+02:00

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

Marcatura nel codice → usi le funzioni gettext.
Estrazione → generi un file .pot (template) con tutte le stringhe.
Traduzione → crei i .po per ogni lingua a partire dal .pot.
Compilazione → i .po diventano .mo (binari veloci).
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"

# 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:

Come funziona Wordpress

2016-05-04T07:58:00.002+02:00

Attivare VirtueMart SEO senza utilizzare il suffisso nella pagina del dettaglio

2015-10-14T12:12:00.000+02:00

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.

MySQL non fa più accedere l'utente ROOT

2015-10-09T23:48:00.001+02:00

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

Alcuni semplici ma utili script per Joomla!

2015-10-07T23:24:00.000+02:00

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!

Cosa aspettarsi di Joomla 3.5 e Joomla 3.6

2015-09-30T01:00:00.000+02:00

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

Ottimizzare il file robots.txt per Magento

2015-09-09T22:59:00.000+02:00

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/

Comandi utili da terminale su Debian / Ubuntu / Mint

2015-01-10T12:24:00.000+01:00

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.

Vai alla directory dei log di Apache

cd /var/log/apache2/

Rimuovi tutti i file

rm -rf /var/log/apache2/*

Ricarica apache

service apache2 reload

Magento mettere offline un sito web proteggendo la SEO

2015-01-04T19:28:00.002+01:00

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) ) {

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';

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.

Eseguire un’importazione in Magento da riga di comando

2015-01-01T20:12:00.000+01:00

Come eseguire un’importazione di prodotti con DataFlow nel catalogo di Magento da terminale

L’opzione Dataflow-Profile permette di effettuare aggiornamenti del catalogo senza dover scrivere codice PHP.

Tuttavia a volte può verificarsi un timeout del web server e rendere impossibile l’effettuazione dell’operazione, abbiamo già visto nel post relativo agli indici bloccati.

Eseguire un’importazione di prodotti da riga di comando può sembrare un’operazione un po’ complicata per chi non l’abbia mai effettuata ma talvolta può essere necessaria se il web server va in timeout.

Il codice PHP necessario

In effetti per eseguire un’importazione di dati da Magento utilizzando il DataFlow sono sufficienti poche righe di codice:

<?php

//verifichiamo che lo script venga eseguito da riga di comando

if (php_sapi_name() !== 'cli') {

die ("Esegui lo script solo da shell");

}

//identifico l’ID del profilo di importazione Dataflow

$profileId = 7;

//includo Magento

require_once 'app/Mage.php';

umask(0);

Mage::app()->setCurrentStore(Mage_Core_Model_App::ADMIN_STORE_ID);

//instanzio il model dataflow/profile

$profile = Mage::getModel('dataflow/profile');

//imposto l’utente che eseguirà lo script

$userModel = Mage::getModel('admin/user');

$userModel->setUserId(0);

Mage::getSingleton('admin/session')->setUser($userModel);

//carico il profilo di importazione

$profile->load($profileId);

//controllo che il profilo esista realmente

if (!$profile->getId()) {

Mage::getSingleton('adminhtml/session')->addError('ERROR: Incorrect profile id');

}

Mage::register('current_convert_profile', $profile);

//eseguo il profilo

$profile->run();

$recordCount = 0;

$batchModel = Mage::getSingleton('dataflow/batch');

//comunico nell’output che il profilo è stato eseguito

echo "EXPORT COMPLETE. BATCHID: " . $batchModel->getId();

Come lanciare lo script PHP da riga di comando

Dicevamo che lo script deve essere eseguito da riga di comando, quindi andiamo su terminale e digitiamo:

php export.php

fatto.

Magento, verificare il controller utilizzato

2014-11-29T23:08:00.000+01:00

Ottenere il nome del controller con la classe Mage_Core_Model_Url

Verificare il nome del controller attivo può essere utile per far comparire un output diverso a seconda delle situazioni.

Ad esempio immaginiamo di voler attribuire una classe CSS ad un tag a seconda che ci troviamo sulla home page o nella pagina del prodotto.

Verifica del controller nei file template (.phtml)

Possiamo ottenere il nome del controller che sta utilizzando Magento in questo modo:

$this->getRequest()->getControllerName();

Quindi se ci troviamo sulla home page otterremo "index", se ci troviamo nella scheda prodotto otterremo "product".

In questo modo avremo:

$controller=$this->getRequest()->getControllerName();
if( $controller=="index" ):
//sono sulla home page quindi
$class="stile1";
elseif( $controller=="product" ):
//sono nella scheda prodotto
$class="stile2";
endif;
echo '<span class="'.$class.'">Nome prodotto</span>

L'oggetto Request può anche restituire altre utili informazioni, ad esempio:

//nome della funzione usata dal controller
$this->getRequest()->getActionName();

//indirizzo della route corrente
$this->getRequest()->getRouteName();

//nome del modulo corrente
$this->getRequest()->getModuleName();

Richiamare il controller all'interno delle classi

getRequest può essere richiamato da $this solo nei file .phtml, ma se ci troviamo all'interno di una classe, $this restituirà la classe stessa, quindi il metodo getRequest() non sarà disponibile.

Per ottenere le informazioni sopra descritte sarà quindi necessario utilizzare Mage::app() al posto di $this.

La classe che ci viene in aiuto per ottenere queste informazioni è Mage_Core_Model_Url. Possiamo verificare il contenuto dell'oggetto con un print_r():

You can explore all requests with print_r.

echo "<pre>";
print_r(Mage::app()->getRequest());
echo "</pre>";

Magento - caricare un blocco statico tramite codice

2014-11-16T01:00:00.000+01:00

Come caricare un blocco statico in un file phtml?

Per caricare un blocco statico all'interno di una pagina su Magento, potrebbe essere comodo effettuare direttamente una modifica all'interno di un file .phtml anzichè andare a modificare i layout XML.

Questa operazione può essere facilmente eseguita, dopo aver creato il blocco statico nel CMS.

Ad esempio, se vogliamo visualizzare il contenuto di un blocco che si chiama block_left_top possiamo utilizzare la seguente istruzione:

<?php echo Mage::app()->getLayout()->createBlock('cms/block')->setBlockId('block_left_top')->toHtml(); ?>

Vediamo insieme da cosa è composta:

Mage::app() mi permette di utilizzare il metodo statico app() della classe Mage, da cui partono tutte le chiamate al framework di Magento.
Mage::app() crea un oggetto app che tramite il metodo getLayout() crea un oggetto LAYOUT.
L'oggetto ottenuto tramite il metodo getLayout() può a sua volte utlizzare il metodo createBlock a cui passo il valore 'cms/block' per indicare che voglio che tipo di oggetto voglio utilizzare;
Il nuovo oggetto potrà poi assegnare il blocco statico all'oggetto Blocco creato per scegliere assegnare utilizzo li metodo setBlockId() a cui passerò come parametro l'identificatore del blocco, in questo caso ("block_left_top");
L'oggetto ottenuto può generare un output in HTML tramite appunto il metodo toHtml();
L'output generato può essere inserito in una variabile da utilizzare successivamente oppure stampato direttamente con echo;

Posso ottenere lo stesso risultato con un codice più compatto utilizzando il metodo statico getBlockSingleton che mi permette di creare direttamente un blocco, a cui poi assegnerò il tipo e l'identificatore prima di ottenere il rendering in formato HTML.

Ottenere le informazioni dello store in Magento

2014-11-08T01:00:00.000+01:00

Come ottenere il codice dello negozio (store) corrente su Magento tramite PHP?

Per accedere alle proprietà dello store attivo su Magento si instanzia l'oggetto store tramite il metodo app della classe statica Mage:

$app=Mage::app();

Poi lo store può essere richiamato con il metodo getStore

$store = $app->getStore();

Naturalmente posso eseguire tutto in un'unica operazione:

$store = Mage::app()->getStore();

A questo punto avrà accesso all'oggetto Mage_Core_Store_Model, un modello che mi permetterà di ottenere le seguenti informazioni:

//il nome del negozio
$name = $store->getName();

//il codice del negozio
$code = $store->getCode();

e, utilizzando i metodi del modello, tante altre utili info, ecco i più importanti esempi:

//il Website Id
websiteid=$store->getWebsiteId();

//se il negozio è attivo
$attivo=$store->getIsActive();

//l'url della home page del negozio
$home=getStore()->getHomeUrl();

Aggiungere un prefisso a tutte le tabelle di un database Magento (e più in generale su MySQL)

2014-11-04T03:30:00.000+01:00

Come aggiungere un prefisso alle tabelle del DB di Magento

In alcuni casi può capitare di dover sfruttare uno stesso database per più applicazione.

La soluzione: utilizzate un prefisso

Sia che le applicazioni siano di tipo diverso (ad esempio Magento e Drupal) che, a maggior ragione dello stesso tipo (due installazioni di Magento), potrebbero esserci delle tabelle con lo stesso nome, da qui la necessità di aggiungere un prefisso per evitare che una o più tabelle vadano a "sovrapporsi" e salti l'integrità dei dati.

Aggiungere il prefisso a tutte le tabelle tramite SQL

In fase di installazione possiamo specificare il prefisso delle tabelle, quindi il problema si risolve nella fase iniziale.

Come comportarsi nel caso di un DB esistente?

Nel caso in cui non si debba effettuare una nuova installazione e l'unica operazione fosse dover importare solo i db la situazione diventerebbe però un po' problematica.

In questo caso sarebbe opportuno aggiungere il prefisso ad ogni tabella prima del primo database prima di importare il secondo.

Per effettuare questa operazione le opzioni a disposizione sarebbero le seguenti:

1) aprire il file dump con un editor di testo rinominare a mano tutte le tabelle con un copia/incolla del prefisso desiderato (molto esoso in termini di tempo e con un alto rischio di imprecisione);

2) aprire sempre il file, ma rinominare le tabelle con un trova/sostituisci aggiungedo il prefisso (elevatissimo rischio di imprecisione perchè le tabelle possono trovarsi in varie situazioni, CREATE, LOCK, etc.. e quindi difficilmente potremmo individuarle tutte)

3) utilizzare SQL e un po' di PHP

Ovviamente a mio avviso la soluzione 3) è l'unica praticabile.

Oltretutto l'operazione può essere eseguita in due step:

PRIMO STEP: ESEGUIRE UNA QUERY SQL

La seguente query creerà le istruzioni SQL da eseguire successivamente:

SELECT Concat('ALTER TABLE ', TABLE_NAME, ' RENAME TO hors_', TABLE_NAME, ';') FROM information_schema.tables WHERE table_schema = 'Sql718613_3'

Se usate PhpMyadmin (tipica situazione di partenza su tutti gli i principali servizi hosting), potete eseguire la query e poi esportare i risultati in un file SQL.

risultati query

Esportazione dei risultati

Il file ottenuto potrà essere reimportato su phpmyadmin ( o da riga di comando ) per essere eseguito, e tutte le tabelle saranno rinominate.

Magento, cercare articoli non assegnati a nessuna categoria

2014-11-02T21:23:00.000+01:00

Come cercare tutti gli articoli su Magento che non sono stati assegnati ad una categoria?

Avete inserito i prodotti del Vostro catalogo e volete creare un report della situazione relativa a quelli non assegnati a nessuna categoria?

Su Magento potete avere questa informazioni relativamente alla situazione di una categoria, per farlo è sufficiente andare nel backend:

tutti i prodotti della categoria corrente

Come fare per avere un report relativo a tutte le categorie?

Non esiste un'interfaccia nel backend di Magento che ci permetta di farlo, però può venirci in aiuto l'SQL.

La query da eseguire

Andate su phpmyadmin (o da riga di comando) ed eseguite la seguente query:

SELECT e.entity_id, e.sku FROM catalog_product_entity AS e LEFT JOIN catalog_category_product AS l ON l.product_id = e.entity_id WHERE l.category_id IS NULL

Nei risultati potete cambiare i campi della select per conoscere informazioni differenti, di norma lo sku è sufficiente per evitare query più complesse nel database EAV di Magento che potrebbero richiedervi numerose e articolate JOIN.

Se usate phpMyAdmin potete esportare i risultati in CSV per una più agevole lettura.

Verificare in Magento se un modulo è installato e attivo

2014-09-02T05:28:00.000+02:00

Come verificare su Magento la presenza di un modulo?

In alcuni casi può essere utile, su Magento, controllare se è stato installato oppure no un modulo.

Ad esempio potrebbe essere utile far comportare il proprio tema in un modo o in un altro nel caso sia installato un modulo.

Immaginate di avere installato un modulo aggiuntivo che sostituisce il checkout, ma quando viene aggiunto un prodotto al carrello, il redirect di default rimanda l'utente al checkout normale.

Naturalmente potreste modificare il comportamente del tasto ADDTOCART, ma potrebbero esserci in giro dei link che avete creato in precedenza. Con questo codice è possibile intercettare l'installazione del modulo Magestore_onestepcheckout e redirezionare l'utente alla giusta pagina.

Il codice da usare a questo scopo è questo:

$modules = Mage::getConfig()->getNode('modules')->children();
$modulesArray = (array)$modules;

if(isset($modulesArray['Magestore_onestepcheckout '])) {
$url=$this->getCheckoutUrl();
Mage::app()->getFrontController()->getResponse()->setRedirect($url);

}

Oppure:

if( $modules->Magestore_Onestepcheckout->active==true ) {
$url=$this->getCheckoutUrl();
Mage::app()->getFrontController()->getResponse()->setRedirect($url);
}

Sostanzialmente la stessa cosa.

Verifica del modulo installato attraverso il framework di Magento

In realtà è anche disponibile una soluzione migliore, usando però il metodo isModuleEnabled dell'helper della classe Mage:

Mage::helper('core')->isModuleEnabled('Magestore_onestepcheckout ');

In questo questo post di Stackoverflow potete trovare ulteriori alternative:

http://stackoverflow.com/questions/4307407/magento-checking-if-a-module-is-installed

Cosa fare se avete gli indici bloccati su Magento

2014-09-01T13:13:00.000+02:00

Come sbloccare gli indici su Magento

Cosa fare se in un sito Magento quando ricostruite gli indici non vanno in stato PRONTO?

Le cause possono essere varie, in generale il timeout dello script causato da tempi di elaborazione troppo lunghi. Questo problema a sua volta può essere causato da risorse insufficienti nel momento in cui viene effettuata l'operazione, specie se nel sito ci sono molti prodotti.

Nel caso in cui il le risorse del server su cui è pubblicato il vostro sito siano sufficienti per l'ordinaria amministrazione potrebbe succedere abbastanza raramente, ma nel caso in cui l'operazione venga eseguita in contemporanea con un'altra che sta già impegnando una quantità importante di risorse gli indici potrebbero restare bloccati in fase di elaborazione come nella seguente schermata:

A questo punto nel momento in cui tentiate di ricostruirli nuovamente l'operazione potrebbe non andare a buon fine a causa del fatto che una parte degli indici resta BLOCCATA.

Sbloccare gli indici di Magento

A parte aumentare i tempi di timeout di PHP nel php.ini, una soluzione manuale potrebbe essere la seguente procedura:

1) cancellate gli indici svuotando la cartella /var/locks (solo il contenuto, non cancellate la cartella);
2) andate database e cercate la tabella index_process, modificate quindi i valori del campo status in che non sono pending in stato pending
3) a questo punto ricostruite nuovamente gli indici

Ricostruire gli indici del database di Magento da riga di comando

Se il problema non è risolto potete tentare di ricostruire gli indici dala riga di comando (dovete però avere accesso al terminale).

Per avviare l'operazione potete andare nella cartella /shell del sito web, troverete un file indexer.php che può essere eseguito da riga di comando tramite la classe Mage_Shell_Compiler.

Il file shell/indexer.php accetta come argomento il nome dell'indice. Potete scegliere di ricostruire un indice alla volta oppure tutti gli 8 indici insieme. Naturalmente se avete risorse abbondanti potete scegliere la seconda ipotesi, ma in questo caso non dovreste essere arrivati a questo articolo!

Quindi per risparmiare risorse e rendere il procedimento di ricostruzione più veloce e meno accidentato vi consiglio di ricostruirne uno alla volta tramite questa istruzione:

php -f indexer.php -- -reindex catalog_url

I nomi degli indici sono quelli che trovate nel campo index_process.indexer_code.

Oppure potete scegliere di ricostruire tutto, in questo modo:

php -f indexer.php -- -reindexall

Per ogni indice ricostruito riceverete un messaggio di conferma.

L'elenco completo

Approfondimenti

Per un ulteriore approfondimento potete andare su questo link http://inchoo.net/ecommerce/magento/executing-magento-indexer-from-shell/

Magento - rimozione della cartella per il negozio predefinito (pubblicazione di tutte le url sulla root)

2014-08-31T19:07:00.000+02:00

Magento - Pubblicazione degli url sulla root per il negozio predefinito

Per varie ragioni principalmente legate alla SEO può essere necessario (o comunque preferibile) mettere tutti gli indirizzi del negozio predefinito sulla root del sito web anzichè su una sottocartella (tipicamente /it/ per i siti italiani).

Questo significa far gestire a Magento gli url senza aggiungere il codice negozio per avere gli url sulla root e poi forzarne il caricamento su sottocartelle create appositamente per i restanti codici negozio.

Disabilitiamo su Magento l'aggiunta del Codice del Negozio agli URLs

Innanzitutto disabilitiamo quindi l'aggiunta del codice negozio agli Url:

A questo punto tutti gli url saranno sulla root.

Creazione della cartella con il codice negozio per il negozio NON predefinito

Ora creiamo una cartella per ogni negozio NON PREDEFINITO, utilizzeremo il codice negozio per nominare la cartella. In ciascuna di queste cartelle copieremo i seguenti file dalla root di Magento:

* .htaccess
* index.php

In seguito vedremo quali modifiche vanno effettuate ai due file.

Impostazione dell'url per ogni negozio

Ora per ogni negozio dovremo specificare manualmente l'indirizzo del sito web.

Le differenze rispetto alle normali configurazioni è che:

* per URL di base inseriamo http://www.ilmiositoweb.it/en/ che è il percorso effettivo del sito web;
* per Skin URL di base andiamo ad inserire al posto della solita variabile {{unsecure_base_url}} l'indirizzo del sito web http://www.ilmiositoweb.it/skin. Lo stesso discorso vale per i campi Media URL di base e JavaScript URL di base;

Questo perchè ogni store deve utilizzare come root la cartella fisica corrispondente al codice negozio, ma deve prendere dalla root principale del sito i CSS, le immagini e i JavaScript.

La stessa procedura vale per gli indirizzi sicuri, se utilizzate una sessione HTTPS.

MODIFICA DEL FILE index.php

Ora che abbiamo modificato detto a Magento di usare come root per ogni store NON PREDEFINITO le cartelle fisiche nominate come i codici negozio, dobbiamo modificare file .htaccess e index.php per far funzionare l'entry point principale del software.

a questo punto dobbiamo modificare l'entry point di Magento, il file index.php contenuto nella cartella /en/ appena creata, non quello sulla root.

Andiamo alla fine del file, qui troveremo il seguente codice:

/* Store or website code */
$mageRunCode = isset($_SERVER['MAGE_RUN_CODE']) ? $_SERVER['MAGE_RUN_CODE'] : '';
/* Run store or run website */
$mageRunType = isset($_SERVER['MAGE_RUN_TYPE']) ? $_SERVER['MAGE_RUN_TYPE'] : 'store';
Mage::run($mageRunCode, $mageRunType);

inseriremo quindi le seguenti variabili prima dell'ultima riga:

$mageRunCode="en";
$mageRunType="store";
Mage::run($mageRunCode, $mageRunType);

In questo modo le variabili $mageRunCode e $mageRunType anzichè essere impostate dinamicamente avranno sempre lo stesso valore a seconda della cartella dove si trovano.

Ora dobbiamo dire a Magento i percorsi giusti per le variabili:

* $compilerConfig
* $mageFilename

e indicare il percorso giusto per il file errors/503.php

Per fare questo, dato che sarà il file /en/index.php il nuovo entry point, avremo bisogno di modificare i percorsi dicendogli di salire di un livello e andare sulla root.

Modifica del file .htaccess

Alla riga 123 del file .htaccess (se non sono state effettuate altre modifiche al file) troveremo la riga

# RewriteBase /magento/

decommentiamola e inseriamo al posto di /magento/ il percorso della cartella su cui vogliamo inserire la root del sito web. in questo modo:

RewriteBase /en/

In questo modo varemo modificato correttamente il percorso dei negozio.

Ordine degli store

Sulle vecchie versioni di Magento (1.7 e precedenti) occorre indicare come store predefinito in SISTEMA -> GESTIONE NEGOZI-> NOME VISTA NEGOZIO l'ordine di caricamento del negozio. Nelle versioni più recenti (1.8 e successive) occorre inserire sempre in SISTEMA -> GESTIONE NEGOZI-> NOME VISTA NEGOZIO la vista negozio di default.

Localizzazione

Infine in SISTEMA -> CONFIGURAZIONE -> GENERALE non dimentichiamoci di impostare come lingua predefinita quella del negozio predefinito.

» Programmatore php joomla esperto SEO @ Davide Taddei: Disabilitare il Multivendor su Virtuemart 2 se è s...

2014-08-28T03:05:00.000+02:00

» Programmatore php joomla esperto SEO @ Davide Taddei: Disabilitare il Multivendor su Virtuemart 2 se è s...: La funzione multivendor di Virtuemart 2 può essere attivata o disattivata in questo modo:

» Programmatore php joomla esperto SEO @ Davide Taddei: modificare il footer dell'e-mail dell'ordine in Vi...

2014-08-27T04:38:00.000+02:00

» Programmatore php joomla esperto SEO @ Davide Taddei: modificare il footer dell'e-mail dell'ordine in Vi...: A volte può servire modificare il messaggio di conferma d'ordine di Virtuemart 2. Potrebbe capitare ad esempio di non avere Shop Name ...

» Programmatore php joomla esperto SEO @ Davide Taddei: Tradurre i campi personalizzati (custom fields) di...

2014-08-26T05:59:00.000+02:00

» Programmatore php joomla esperto SEO @ Davide Taddei: Tradurre i campi personalizzati (custom fields) di...: Per tradurre i campi personalizzati su Virtuemart 2 è sufficiente seguire la stessa logica di Joomla! integrato quindi per tradurre il valor...

Eliminazione delle immagini dal Database MySql e struttura EAV del database di Magento

2014-08-23T15:56:00.000+02:00

Eliminazione delle immagini dal Database MySql di Magento

Su Magento può capitare di voler eliminare le immagini dei prodotti direttamente dal database. Per farlo occorre modificare i dati delle seguenti tabelle coinvolte sono:

catalog_product_entity_varchar
catalog_product_entity_media_gallery
catalog_product_entity_media_gallery_value

Le tabelle della galleria

Le seguenti tabelle:

catalog_product_entity_media_gallery
catalog_product_entity_media_gallery_value

contengono le immagini della galleria, per eliminare tutti i record è quindi sufficiente eseguire le seguenti query:

DELETE FROM catalog_product_entity_media_gallery_value

DELETE FROM catalog_product_entity_media_gallery

A causa delle Foreign Key un comando TRUNCATE non funzionerebbe.

Infine si possono eliminare le immagini dalla tabella:

catalog_product_entity_varchar

E' possibile utilizzare la seguente istruzione SQL:

DELETE FROM `catalog_product_entity_varchar` WHERE `attribute_id`=85 OR `attribute_id`=86 OR `attribute_id`=87

I valori 85 - 86 - 87 della clausola WHERE rappresentano i vari formati di immagine disponibili per il prodotto su Magento (image, thumb, small).

Osservazioni sulla struttura della tabella catalog_product_entity_varchar e sul database EAV di Magento

Questa tabella contiene gli attributi di tipo VARCHAR dei prodotti inseriti. In Magento la maggior parte delle informazioni relative ai prodotti sono gestite come attributi. Quindi un'istruzione DELETE senza nessuna WHERE specificata come nel caso delle tabelle relative alla galleria delle immagini cancellerebbe, non solo i riferimenti ai file delle immagini dei prodotti ma anche altre informazioni.

I campi della tabella sono i seguenti:

* value_id, la chiave primaria della tabella
* entity_type_id, il tipo di entità, nel caso dei prodotti del catalogo il valore è sempre 4
* attribute_id, il tipo di attributo da cancellare
* store_id, l'id del negozio (sarà sempre 1 se non gestite un sito multilingua o un multistore)
* entity_id, l'id del recordprodotto
* value, il valore effettivamente inserito

Se volete verificare quali informazioni sono disponibili per un singolo prodotto (supponiamo quello con id 363) potete quindi eseguire la seguente query:

SELECT * FROM `catalog_product_entity_varchar` WHERE `entity_id` =363;

troverete tutti gli attributi assegnati a quel prodotto. Per conoscere a cosa corrisponde il valore dell'attribute_id, è sufficiente andare nel pannello di controllo su CATALOGO->ATTRIBUTI->GESTIONE ATTRIBUTI e verificare il valore dell'attributo.

Se filtrerete i nomi degli attributi con i seguenti codici attributo:

* thumbnail
* image
* small_image

troverete appunto gli id 85, 86 e 87.

Per saperne di più sulla struttura EAV del database di Magento:

http://fishpig.co.uk/magento/tutorials/eav-database-structure/ (tutorial in inglese)
http://sqlblog.com/blogs/aaron_bertrand/archive/2009/11/19/what-is-so-bad-about-eav-anyway.aspx (appunti in inglese sulla performance di un database EAV)

La SEO influenza i Social Media? I Social Media influenzano la SEO?

2012-04-17T15:45:00.000+02:00

Social media e SEO sono talvolta contrapposti come possibilità di portare traffico al nostro sito web, a volte per motivi di budget (non abbiamo i soldi per fare tutte e due) altre volte per motivi di tempo (non abbiamo tempo di seguire entrambi i progetti) molto spesso perchè i webmaster sono più orientati verso una delle due soluzioni e detestano l'altra.In tutti e tre i casi è evidente la mancanza di un approccio professionale al problema, in queste slides un metodo ragionato basato sull'esperienza di anni di SEO della M.C. Marketing e Comunicazione, web agency anconetana che dal 1997 si occupa di curare la visibilità dei propri clienti sul web, ci aiuta a orientarci verso la strada giusta per una strategia di vincente di visibilità sul web.Social Media & SEO

Guarda altre interessanti presentazioni sul canale Slideshare di Gruppo M.C. Ancona dal 1979 / Consulenti aziendali e Web agency