Blog - Pagina 9 di 9 - GeoDirectory

Advanced Custom Fields è un plugin fantastico utilizzato da milioni di persone che trasforma WordPress in un CMS a stack completo, permettendoti di creare gruppi e tipi di campi personalizzati illimitati e di aggiungerli a qualsiasi tipo di post personalizzato.

Tuttavia, in pochi conoscono i limiti di scalabilità di Advanced Custom Fields.

Spesso ci viene chiesto se GeoDirectory utilizzi Advanced Custom Fields per gestire i campi personalizzati delle inserzioni.

Quando rispondiamo che GeoDirectory dispone di un proprio sistema di campi personalizzati integrato, molti si chiedono perché abbiamo deciso di "reinventare la ruota".

Per noi la risposta è chiarissima: la scalabilità di Advanced Custom Fields è piuttosto limitata quando si tratta di creare directory.

Abbiamo pensato che forse, essendo utenti, non sono consapevoli di ciò che avviene dietro le quinte e delle sfide di scalabilità che una web directory può presentare.

Tuttavia, non molto tempo fa, ci siamo imbattuti in un sondaggio su un popolare gruppo WordPress su Facebook, dove le opzioni per votare la "Migliore Directory" erano: GeoDirectory, alcuni altri temi per directory disponibili sui marketplace più popolari e c'era anche l'opzione ACF + FacetWP.

Quando abbiamo visto i risultati, siamo rimasti perplessi, per usare un eufemismo: ACF + FacetWP aveva ricevuto molti più voti di quanti ne avremmo immaginati.

Le persone che avevano votato non erano semplici utenti, ma sviluppatori web ed esperti di WordPress.

Per questo motivo, abbiamo deciso che era giunto il momento di spiegare perché usare Advanced Custom Fields per una directory NON è una buona idea.

E perché gli sviluppatori web non dovrebbero offrire quella soluzione a nessuno, a meno che non si preoccupino di fornire ai propri clienti soluzioni veloci e scalabili, in grado di crescere in modo sostenibile.

Limiti di scalabilità dei campi personalizzati di WordPress

WordPress utilizza per impostazione predefinita la tabella del database wp_postmeta per memorizzare i dati dei campi personalizzati, creando 1 riga per ogni campo personalizzato utilizzato in un post.

Oltre a questo, WordPress aggiunge molti dati extra in questa tabella per ogni post, ognuno dei quali occuperà 1 riga della tabella.

Se hai trascorso del tempo a ottimizzare le query SQL, saprai che non è uno scenario ideale per cose come directory e filtri.

In effetti, la struttura predefinita del database è potenzialmente un enorme collo di bottiglia per i siti web con molti post e campi personalizzati.

È considerato uno dei punti deboli di WordPress.

Questo perché per filtrare i post in base ai campi personalizzati, dovrai unire la tabella wp_post con la tabella wp_postmeta nella tua query.

Più le tabelle cresceranno, più le query diventeranno lente.

Peggio ancora, se vuoi filtrare per due valori meta, dovresti unire la tabella post_meta due volte per farlo in una singola query.

Questo può consumare la memoria di sistema e rallentare tutto, tranne che per una directory di piccole dimensioni.

Limiti di scalabilità di Advanced Custom Fields

Il plugin Advanced Custom Fields è perfetto per qualsiasi sito web con un numero basso o moderato di post, pagine e campi personalizzati in generale.

Tuttavia, salvo rare eccezioni, le directory sono esattamente il contrario.

Hanno un numero molto elevato di post e potenzialmente anche un numero molto elevato di campi personalizzati.

Il principale problema di scalabilità di Advanced Custom Fields è che crea 2 righe nella tabella wp_postmeta del tuo database per ogni campo personalizzato aggiunto a un'inserzione.

Aggiungerà inoltre diverse righe postmeta relative alle proprie impostazioni.

Ciò significa che aggiungerà più del doppio delle righe nella tabella wp_postmeta del tuo database rispetto all'utilizzo del sistema di campi personalizzati predefinito di WordPress.

Abbiamo effettuato un rapido test che dovrebbe aiutarci a spiegare meglio questa questione.

Abbiamo creato un nuovo sito WordPress, eliminato il post "hello world" e la pagina di esempio, e installato Advanced Custom Fields.

Abbiamo creato 1 gruppo e 5 campi personalizzati, e pubblicato 3 post utilizzando ciascuno i 5 campi personalizzati.

Dopo questo, la nostra tabella wp_postmeta contava già 83 righe.

È assurdo.

Immagina il numero di righe per una directory con 300.000 inserzioni e cinque campi personalizzati.

Con ACF, la tua tabella wp_postmeta conterebbe un minimo di 3.000.000 di righe

Come scala GeoDirectory?

È molto semplice: creiamo una tabella personalizzata per ciascuno dei nostri tipi di post personalizzati.

Esempio: wp_gd_gd_place_detail

In questa tabella salviamo tutti i campi personalizzati e i loro dati, in una riga per ogni post.

Abbiamo anche sviluppato una nostra API PHP per interrogare le nostre tabelle personalizzate, proprio come WordPress dispone di una propria API PHP per interrogare le tabelle predefinite del database wp.

Ciò significa che GD, nella maggior parte dei casi, deve solo unire la tabella dei post alla nostra tabella.

Possiamo quindi filtrare quei risultati per QUALSIASI campo personalizzato.

Potremmo filtrare per 20 campi personalizzati, mentre ACF, anche con facetWP (che velocizza le cose ma ha comunque la limitazione di base), dovrebbe unire più tabelle più e più volte per svolgere lo stesso lavoro in un'unica query, utilizzando molte volte la memoria del server per la stessa query.

Conclusioni

Se confrontiamo GeoDirectory con WordPress o WP + Advanced Custom Fields, vediamo che:

WordPress
1) Richiede un JOIN aggiuntivo della tabella per ogni campo personalizzato per cui si vuole filtrare.
2) wp_postmeta diventa rapidamente molto grande, rallentando le query

WP + ACF

1) Richiede un JOIN aggiuntivo della tabella per ogni campo personalizzato per cui si vuole filtrare.
2) wp_postmeta diventa il doppio rispetto all'utilizzo di WordPress da solo

GeoDirectory

1) Non è richiesto alcun join
2) GD non aggiunge informazioni a wp_postmeta, quindi non crea inutile appesantimento.
3) Il database che archivia i dati delle inserzioni conta 1 riga per post

WordPress è noto per questa limitazione nel modo in cui memorizza i dati. Nella maggior parte dei casi questo sistema funziona bene, ma quando si tratta di directory di grandi dimensioni, non è semplicemente la soluzione giusta.

Ecco perché con GeoDirectory puoi creare una directory con milioni di inserzioni, mentre con WP + Advanced Custom Fields sei fortunato se riesci a costruire una directory con qualche centinaio di inserzioni prima di iniziare a riscontrare seri problemi di prestazioni.

Questi sono i limiti di scalabilità di Advanced Custom Fields che ci hanno spinto a decidere di non utilizzarlo per GeoDirectory, ed è per questo che non dovresti usarlo nemmeno tu.

Se hai domande, sentiti libero di farle nel commento qui sotto.

Le funzionalità di localizzazione di WordPress ti permettono di rendere plugin e temi facilmente traducibili tramite i file di lingua di WordPress (file po/mo).

Questo è vero soprattutto da WordPress 3.7 ed è diventato molto più semplice da WordPress 4.6.

Sono stati apportati molti miglioramenti all'intero sistema di traduzione di WordPress, e ho sentito il bisogno di pubblicare un articolo aggiornato sull'argomento.

I file di lingua di WordPress – La confusione ( Edizione sviluppatori )

Per gli sviluppatori, il nodo centrale è come comunicare a WordPress nel modo corretto che si dispone di file di traduzione.

Come sviluppatori, ci è stato indicato di usare "load_plugin_textdomain()" e di puntare questa funzione al file di lingua nella cartella del plugin.

In passato, però, questo era l'unico posto in cui WordPress avrebbe cercato e se un utente aggiungeva un proprio file di lingua lì, al successivo aggiornamento sarebbe andato perduto!

Tempo fa circolava un articolo che promuoveva l'uso di una seconda chiamata, questa volta con la funzione "load_textdomain()", per puntare a un file nella cartella delle lingue di WP, e molti hanno adottato questo approccio (noi compresi).

Questo consentiva agli utenti di inserire i propri file di lingua in una posizione predefinita nella cartella delle lingue di WP, senza perdere la traduzione ad ogni aggiornamento del plugin.

I file di lingua di WordPress – La confusione ( Edizione utenti )

Gli utenti devono sapere dove inserire una traduzione personalizzata per un plugin/tema; il problema è che in passato i posti possibili erano diversi.

La documentazione di WP indica agli sviluppatori di fare riferimento a una cartella chiamata "languages" all'interno della cartella del plugin, ma lo sviluppatore potrebbe usare la cartella "lang" e in ogni caso, questa andrà persa quando il plugin/tema viene aggiornato.

Alcuni sviluppatori aggiungevano un secondo controllo in un percorso a loro scelta, spesso in una cartella con nome personalizzato all'interno della cartella delle lingue di WP.

Questo significava che non esisteva un modo uniforme per l'utente di sapere dove inserire in modo sicuro i propri file di traduzione personalizzati.

Caricare i file di lingua nel modo corretto (2017)

Da WP 4.6 tutto è diventato molto più semplice sia per gli utenti che per gli sviluppatori!

Come sviluppatore, ora devi solo assicurarti di caricare i file di lingua correttamente, seguendo la documentazione di WP come indicato di seguito:

<br />
// for plugins<br />
add_action( 'init', 'myplugin_load_textdomain' );<br />
function myplugin_load_textdomain() {<br />
  load_plugin_textdomain( 'my-plugin', false, basename( dirname( __FILE__ ) ) . '/languages' );<br />
}<br />

<br />
// for themes<br />
add_action( 'after_setup_theme', 'my_theme_setup' );<br />
function my_theme_setup(){<br />
    load_theme_textdomain( 'my-theme', get_template_directory() . '/languages' );<br />
}<br />

Nota che questi vengono attivati sugli hook 'init' e 'after_setup_theme': questo dovrebbe garantire che tutto si carichi senza problemi.

Se li attivi direttamente o prima dei rispettivi hook, potresti riscontrare problemi con alcune stringhe che non vengono tradotte, e plugin per la gestione delle traduzioni o per la creazione di siti multilingua come WPML potrebbero non funzionare affatto.

Come utenti, ora abbiamo a disposizione un percorso comodo e denominato in modo uniforme dove inserire i nostri file di lingua.

Per i plugin: /wp-content/languages/plugins/my-plugin-en_US.mo
Per i temi: /wp-content/languages/themes/my-theme-en_US.mo

'my-plugin' e 'my-theme' corrispondono al textdomain del plugin/tema (solitamente indicato nel file readme.txt del plugin o nel file style.css del tema, in cima al file).

Si tratta di un grande miglioramento rispetto al metodo precedente e nella maggior parte dei casi eviterà la perdita delle traduzioni durante gli aggiornamenti.

In alcuni casi il plugin/tema potrebbe già disporre di una nuova traduzione nella tua lingua memorizzata su wp.org; in tal caso potrebbe sovrascrivere il tuo file .mo, ma nella maggior parte dei casi questo è il comportamento desiderato.

Puoi contribuire alle traduzioni su wp.org se il plugin è ospitato lì; se si tratta di un plugin premium, è molto improbabile che la tua traduzione venga sovrascritta.

Informazioni aggiuntive

WordPress tenterà di trovare i file di lingua di WordPress in diversi percorsi; per un plugin con textdomain 'my-plugin' cercherà prima qui:

/wp-content/languages/plugins/my-plugin-en_US.mo

Se non trova una traduzione lì e il plugin specifica dove trovarne una in locale, cercherà lì:

/wp-content/plugins/my-plugin/languages/my-plugin-en_US.mo

Se il plugin non specifica un percorso, WordPress cercherà invece qui:

/wp-content/languages/my-plugin-en_US.mo

È bene seguire la documentazione di WordPress, ma in realtà da WP 4.6 non è nemmeno necessario specificare un file locale se non ne stai includendo alcuno (se sono archiviati nel repository di wp.org); puoi quindi semplicemente aggiungere questo:

<br />
// for plugins<br />
add_action( 'init', 'myplugin_load_textdomain' );<br />
function myplugin_load_textdomain() {<br />
  load_plugin_textdomain( 'my-plugin');<br />
}<br />

<br />
// for themes<br />
add_action( 'after_setup_theme', 'my_theme_setup' );<br />
function my_theme_setup(){<br />
    load_theme_textdomain( 'my-theme');<br />
}<br />

Spero che questo chiarisca un po' le idee sulle traduzioni; se hai domande o vuoi aggiungere qualcosa, lascia pure un commento qui sotto.

Aggiornamento settembre 2019

Questo è stato aggiunto come campo personalizzato predefinito nella versione V 2.0.0.67. Lo snippet qui sotto funzionerà solo se si utilizza GeoDirectory V1.

Il problema

Oggi un membro ha avanzato una richiesta piuttosto insolita: sta usando GeoDirectory per gestire un festival locale e sta elencando cose come gli alloggi disponibili. La richiesta era di mostrare la distanza in ogni annuncio rispetto all'evento principale, in modo che gli utenti abbiano una chiara comprensione di quanto disterà l'evento da ciascun annuncio. Faccio qualcosa di molto simile su uno dei miei siti, che riguarda una sola location: indico la distanza dall'aeroporto e la distanza dalla città principale. Fino ad ora ho lasciato che gli utenti inserissero questa distanza manualmente, ma spesso è errata e devo correggerla.

La soluzione

Distanza da". Il codice è riportato di seguito, ma ci sono due modi per utilizzare questo campo:
#1 Potremmo semplicemente aggiungere il campo e lasciare che l'utente inserisca le coordinate GPS; potrebbe essere ad esempio un campo "aeroporto più vicino", e l'utente potrebbe inserire le informazioni GPS dell'aeroporto più vicino a lui.
#2 Nel caso di questo utente, deve solo mostrare la distanza da un luogo specifico senza che l'utente debba nemmeno conoscere il campo. Quindi, quando aggiunge il campo personalizzato, lo imposta come campo "solo admin" in modo che non venga mostrato all'utente nel frontend e non possa modificarlo, dopodiché imposta il "valore predefinito" con le coordinate GPS necessarie: tutti gli annunci mostreranno così le informazioni richieste.

Il codice

Questo articolo ti spiegherà come risolvere il problema "Questa pagina non ha caricato Google Maps correttamente. Consulta la console JavaScript per i dettagli tecnici." con Google Maps.

Se stai utilizzando GeoDirectory consulta la nostra documentazione qui.

Se vuoi approfondire il problema leggi il nostro articolo qui: https://wpgeodirectory.com/google-maps-api-key-and-new-limits/

Se hai visto il messaggio "Questa pagina non ha caricato Google Maps correttamente. Consulta la console JavaScript per i dettagli tecnici." o uno dei seguenti messaggi:
"Esta página no ha cargado Google Maps correctamente."
"Google Maps ne s'est pas chargé correctement sur cette page."
"Google Maps non è stata caricata correttamente."
"Google Maps wurde auf dieser Seite nicht richtig geladen."
"При загрузке Google Карт на этой странице возникла проблема."

È probabile che tu abbia bisogno di questa correzione. Se stai usando WordPress, abbiamo creato un plugin che dovrebbe risolvere il problema per la maggior parte degli utenti il cui plugin o tema ne è la causa. Puoi trovarlo qui: CORREZIONE API KEY DI GOOGLE MAPS

Se non stai usando WordPress, dovrai individuare nel codice sorgente la chiamata a Google Maps e aggiungere la chiave API. Puoi trovare le istruzioni per creare una chiave API qui. Una volta ottenuta la tua chiave API, aggiungila alla chiamata al file Google Maps: maps.google.com/maps/api/js?key=YOUR-API-KEY-HERE

Speriamo che tu abbia trovato questo articolo utile; i tuoi commenti sono sempre i benvenuti.

Il Team di GeoDirectory.

Siamo lieti di annunciare il supporto per Snazzy Maps nel nostro addon Custom Google Maps (1.0.5).

Cos'è Snazzy Maps?

Snazzy Maps è una risorsa online che consente agli utenti di personalizzare i colori, la saturazione e altre opzioni di stile delle proprie Google Maps.

Le opzioni di personalizzazione sono disponibili sotto forma di diversi stili di mappa progettati da vari autori sul web.

Oltre a modificare le mappe con Snazzy Maps, gli utenti possono creare i propri stili Snazzy Map da utilizzare nei loro siti web o nelle loro app.

Tutte le mappe personalizzate offrono anche immagini satellitari ad alta risoluzione e supporto vettoriale sia per il web che per i dispositivi mobili.

Grazie a queste funzionalità, aziende e sviluppatori possono creare mappe visivamente accattivanti per i loro progetti senza dover ricorrere a competenze di programmazione.

Perché abbiamo aggiunto il supporto per Snazzy Maps su GeoDirectory?

Poco più di una settimana fa, uno dei nostri membri, `Pieter Ravelli`, ci ha segnalato il sito web e ha colpito nel segno con il nostro team, tanto da essere subito portato in cima alla lista delle attività di sviluppo.

Questo rispecchia la nostra filosofia qui a GeoDirectory. Se un membro può suggerire qualcosa che vada a beneficio di tutti, siamo ben felici di aggiungerlo.

Importare gli stili di Snazzy Maps in GeoDirectory

Aggiungere gli stili di Snazzy Maps all'addon Custom Maps di GeoDirectory è piuttosto semplice.

Prima di tutto, vai su snazzymaps.com e trova o crea uno stile che ti piace.
Una volta sulla pagina che ti interessa, troverai un pulsante di copia. Cliccaci sopra.
Successivamente, vai nelle impostazioni di GeoDirectory e accedi a GD>Custom Google Maps>Manage Styles, quindi clicca per modificare la mappa che desideri cambiare.
import styles", incolla il codice degli stili da Snazzy Maps e clicca il pulsante "Import & Save Styles".
Il tuo nuovo stile di mappa sarà ora utilizzato sul tuo sito.

Stai usando Snazzy Maps con GeoDirectory? Se sì, quale stile stai utilizzando? Faccelo sapere nei commenti qui sotto.

Il Plugin WordPress per Directory Più Avanzato e Scalabile al Mondo