Blog - Page 9 of 9 - GeoDirectory

Skalierungsgrenzen von Advanced Custom Fields

Advanced Custom Fields ist ein fantastisches Plugin, das von Millionen genutzt wird und WordPress in ein vollständiges CMS verwandelt. Es ermöglicht Ihnen, unbegrenzte benutzerdefinierte Feldgruppen und -typen zu erstellen und diese zu jedem beliebigen benutzerdefinierten Beitragstyp hinzuzufügen.

Allerdings wissen nur wenige über die Skalierbarkeitsgrenzen von Advanced Custom Fields Bescheid.

Wir werden häufig gefragt, ob GeoDirectory Advanced Custom Fields zur Verwaltung benutzerdefinierter Felder für Einträge verwendet.

Wenn wir antworten, dass GeoDirectory über ein eigenes, integriertes benutzerdefiniertes Feldsystem verfügt, fragen sie sich, warum wir uns entschieden haben, „das Rad neu zu erfinden".

Für uns ist die Antwort glasklar: Die Skalierbarkeit von Advanced Custom Fields ist beim Aufbau von Verzeichnissen sehr begrenzt.

Wir dachten, dass sich die Nutzer als Anwender möglicherweise nicht bewusst sind, was im Hintergrund passiert und welche Skalierbarkeitsprobleme ein Web-Verzeichnis mit sich bringen kann.

Vor nicht allzu langer Zeit sind wir jedoch auf eine Umfrage in einer beliebten WordPress-Gruppe auf Facebook, where the options to vote for the "Best Directory" were: GeoDirectory, a few other Directory Themes available on popular marketplaces and there was also the option ACF + FacetWP.

When we saw the results, we were perplexed, to say the least, ACF + FacetWP had a lot more votes than we would have thought.

People who voted were not supposed to be just simple users, but website developers and WordPress experts.

For this reason, we decided it was time to explain why it is NOT a good idea to use Advanced Custom Fields for a directory.

And why Web Developers shouldn’t offer that solution to anyone unless they don’t care about providing fast, scalable solutions to their customers, that can grow sustainably.

WordPress Custom Fields Scalability Limits

WordPress by default uses the wp_postmeta database table to store custom field data, and it creates 1 row for each custom field used in a post.

Other than that WordPress adds a lot of extra data in this table for each post, each of which will use 1 row of the table.

If you spent some time optimizing SQL queries, you’ll know that’s not an ideal scenario for things like directories and filtering.

Tatsächlich ist die standardmäßige Datenbankstruktur ein potenziell enormer Flaschenhals für Websites mit vielen Beiträgen und benutzerdefinierten Feldern.

Sie gilt als einer der Schwachpunkte von WordPress.

Der Grund dafür ist, dass Sie zum Filtern von Beiträgen nach benutzerdefinierten Feldern die Tabelle wp_post mit der Tabelle wp_postmeta in Ihrer Abfrage verknüpfen müssen.

Je größer die Tabellen werden, desto langsamer werden die Abfragen.

Am schlimmsten ist es, wenn Sie nach zwei Meta-Werten filtern möchten – dann müssen Sie die Tabelle post_meta in einer einzigen Abfrage zweimal verknüpfen.

Dies kann den Systemspeicher aufbrauchen und alles verlangsamen – außer bei einem kleinen Verzeichnis.

Skalierbarkeitsgrenzen von Advanced Custom Fields

Das Advanced Custom Fields Plugin ist perfekt für jede Website mit einer geringen oder moderaten Anzahl von Beiträgen, Seiten und benutzerdefinierten Feldern im Allgemeinen.

Bei Verzeichnissen ist es jedoch – bis auf wenige Ausnahmen – genau umgekehrt.

Sie haben eine sehr hohe Anzahl von Beiträgen und potenziell auch eine sehr hohe Anzahl benutzerdefinierter Felder.

Das primäre Skalierbarkeitsproblem von Advanced Custom Fields besteht darin, dass für jedes benutzerdefinierte Feld, das einem Eintrag hinzugefügt wird, 2 Zeilen in der wp_postmeta-Tabelle Ihrer Datenbank erstellt werden.

Außerdem werden mehrere Postmeta-Zeilen hinzugefügt, die zu den eigenen Einstellungen gehören.

Das bedeutet, dass im Vergleich zur Verwendung des Standard-WordPress-Systems für benutzerdefinierte Felder mehr als doppelt so viele Zeilen in der wp_postmeta-Tabelle Ihrer Datenbank hinzugefügt werden.

Wir haben einen kurzen Test durchgeführt, der dabei helfen soll, diesen Sachverhalt besser zu erklären.

Wir haben eine neue WordPress-Website erstellt, den „Hello World"-Beitrag und die Beispielseite gelöscht und Advanced Custom Fields installiert.

Wir haben 1 Gruppe und 5 benutzerdefinierte Felder erstellt und 3 Beiträge veröffentlicht, die jeweils die 5 benutzerdefinierten Felder verwenden.

Danach zählte unsere wp_postmeta-Tabelle bereits 83 Zeilen.

Das ist absurd.

Stellen Sie sich die Anzahl der Zeilen für ein Verzeichnis mit 300.000 Einträgen und fünf benutzerdefinierten Feldern vor.

Mit ACF würde Ihre wp_postmeta-Tabelle mindestens 3.000.000 Zeilen zählen

Wie skaliert GeoDirectory?

Das ist ganz einfach: Wir erstellen eine benutzerdefinierte Tabelle für jeden unserer benutzerdefinierten Beitragstypen.

Beispiel: wp_gd_gd_place_detail

In dieser Tabelle speichern wir alle benutzerdefinierten Felder und deren Daten in einer Zeile pro Beitrag.

Wir haben auch eine eigene PHP-API entwickelt, um unsere benutzerdefinierten Tabellen abzufragen – genau wie WordPress eine eigene PHP-API zum Abfragen der Standard-WordPress-Datenbanktabellen hat.

Das bedeutet, dass GD in den meisten Fällen nur die Beitragstabelle mit unserer Tabelle verknüpfen muss.

Anschließend können wir diese Ergebnisse nach JEDEM benutzerdefinierten Feld filtern.

Wir könnten nach 20 benutzerdefinierten Feldern filtern, während ACF – selbst mit facetWP (was die Dinge zwar beschleunigt, aber dennoch die grundlegende Einschränkung hat) – mehrere Tabellen immer wieder verknüpfen müsste, um dieselbe Aufgabe in einer einzigen Abfrage zu erledigen, und dabei ein Vielfaches des Serverarbeitsspeichers für dieselbe Abfrage benötigt.

Fazit

Wenn wir also GeoDirectory mit WordPress oder WP + Advanced Custom Fields vergleichen, sehen wir Folgendes:

WordPress
1) Für jedes benutzerdefinierte Feld, nach dem gefiltert werden soll, ist ein zusätzlicher Tabellen-JOIN erforderlich.
2) wp_postmeta wird schnell groß und verlangsamt die Abfragen

WP + ACF

1) Für jedes benutzerdefinierte Feld, nach dem gefiltert werden soll, ist ein zusätzlicher Tabellen-JOIN erforderlich.
2) wp_postmeta wird doppelt so groß im Vergleich zur alleinigen Verwendung von WordPress

GeoDirectory

1) Kein JOIN erforderlich
2) GD fügt keine Daten zur wp_postmeta hinzu und erzeugt daher keinen unnötigen Overhead.
3) Die Datenbank, in der Eintragsdata gespeichert wird, zählt 1 Zeile pro Beitrag

WordPress ist für diese Einschränkung bei der Datenspeicherung bekannt. In den meisten Fällen funktioniert dieses System gut, aber bei großen Verzeichnissen ist es einfach nicht die richtige Lösung.

Genau deshalb können Sie mit GeoDirectory ein Verzeichnis mit Millionen von Einträgen erstellen, während Sie mit WP + Advanced Custom Fields froh sein können, wenn Sie ein Verzeichnis mit einigen Hundert Einträgen erstellen können, bevor gravierende Performance-Probleme auftreten.

Dies sind die Skalierbarkeitsgrenzen von Advanced Custom Fields, die uns dazu bewogen haben, es nicht für GeoDirectory zu verwenden – und deshalb sollten auch Sie es nicht einsetzen.

Wenn Sie Fragen haben, stellen Sie diese gerne im Kommentarbereich unten.

Die WordPress-Lokalisierungsfunktionen ermöglichen es Ihnen, Plugins und Themes über WordPress-Sprachdateien (po/mo-Dateien) einfach übersetzbar zu machen.

Dies gilt insbesondere seit WordPress 3.7 und wurde seit WordPress 4.6.

Am gesamten Übersetzungssystem für WordPress wurden viele Verbesserungen vorgenommen – ich fand, dass es wirklich einen aufgefrischten Beitrag braucht.

WordPress-Sprachdateien – Die Verwirrung (Entwickler-Edition)

Für Entwickler läuft es darauf hinaus, wie man WordPress auf die richtige Weise mitteilt, dass Übersetzungsdateien vorhanden sind.

Als Entwickler wurden wir angewiesen, „load_plugin_textdomain()

In der Vergangenheit war dies jedoch der einzige Ort, an dem WordPress suchte, und wenn ein Kunde dort eine eigene Sprachdatei hinzufügte, war diese beim nächsten Update verschwunden!

Vor einiger Zeit gab es einen Artikel im Web, der empfahl, einen zweiten Aufruf mit der Funktion „load_textdomain()

Das bedeutete, dass Benutzer ihre Sprachdateien an einem vordefinierten Ort im WP-Sprachordner ablegen konnten und die Übersetzung beim Plugin-Update nicht verloren ging.

WordPress-Sprachdateien – Die Verwirrung ( Benutzer-Edition )

Benutzer müssen wissen, wo sie eine benutzerdefinierte Übersetzung für ein Plugin/Theme ablegen sollen – das Problem ist, dass dies in der Vergangenheit an mehreren verschiedenen Orten möglich war.

Die WP-Dokumentation empfiehlt Entwicklern, einen Link zu einem Ordner namens „languages even then this will be lost when the plugin/theme is updated.

Some developers would add a second check again in a place of the developers choosing, but often in a custom named folder in the WP languages folder.

This meant there was no consistent way for a user to know where to place their custom translation files safely.

Loading language files the correct way (2017)

Since WP 4.6 this got a whole lot easier for both users and developers!

As a developer you now just have to make sure you are loading your language files correctly, following the WP documentation as below:

<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 />

Notice we fire these on the ‘init’ and ‘after_setup_theme’ hooks, this should mean everything will load nicely.

If you fire it directly or before their respective hooks you can have problems with some strings not translating and plugins to manipulate translations or to create multi lingual websites such as WPML, might not work at all.

As users we now have a convenient and consistently named place we can place our language files.

Für Plugins: /wp-content/languages/plugins/my-plugin-en_US.mo
Für Themes: /wp-content/languages/themes/my-theme-en_US.mo

'my-plugin' und 'my-theme' sind die Textdomain des Plugins/Themes (in der Regel in der plugin readme.txt oder der theme style.css ganz oben zu finden).

Dies ist eine erhebliche Verbesserung gegenüber der alten Methode und verhindert in den meisten Fällen, dass Übersetzungen bei Updates verloren gehen.

In manchen Fällen verfügt das Plugin/Theme möglicherweise bereits über eine neue Übersetzung in Ihrer Sprache, die auf wp.org gespeichert ist. Falls dies der Fall ist, könnte diese Ihre .mo-Datei überschreiben – in den meisten Fällen ist das jedoch gewünscht.

Sie können zu Übersetzungen auf wp.org beitragen, wenn das Plugin dort gehostet wird. Bei einem Premium-Plugin ist die Wahrscheinlichkeit, dass es überschrieben wird, sehr gering.

Bonusinformationen

WordPress sucht Ihre WordPress-Sprachdateien an verschiedenen Orten. Bei einem Plugin mit der Textdomain 'my-plugin' würde es zunächst hier suchen:

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

Wenn dort keine Übersetzung gefunden wird und das Plugin angibt, wo lokal eine zu finden ist, wird es dort nachsehen:

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

Wenn das Plugin keinen Pfad angibt, sucht WordPress stattdessen hier:

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

Die WordPress-Dokumentation sollte befolgt werden, aber in der Praxis müssen Sie ab WP 4.6 nicht einmal eine lokale Datei angeben, wenn Sie keine einbinden (sofern sie im wp.org-Repository gespeichert sind). Sie könnten also einfach Folgendes hinzufügen:

<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 />

Ich hoffe, das bringt etwas Klarheit in das Thema Übersetzungen. Wenn Sie Fragen haben oder etwas ergänzen möchten, hinterlassen Sie bitte unten einen Kommentar.

Update September 2019

Dies wurde in V 2.0.0.67 als vordefiniertes benutzerdefiniertes Feld hinzugefügt. Der folgende Snippet funktioniert nur bei Verwendung von GeoDirectory V1.

Das Problem

Heute hatte ein Mitglied eine etwas ungewöhnliche Anfrage: Es nutzt GeoDirectory, um ein lokales Festival zu verwalten, und listet dabei Dinge wie Unterkünfte auf. Die Anfrage bestand darin, in jedem Eintrag die Entfernung zum Hauptereignis anzuzeigen, damit die Nutzer genau wissen, wie weit es vom jeweiligen Eintrag zum Event ist. Ich mache etwas sehr Ähnliches auf einer meiner eigenen Websites, die sich auf einen einzigen Ort bezieht – ich liste dort die Entfernung zum Flughafen und die Entfernung zur nächsten Stadt auf. Bisher haben die Nutzer diese Entfernung einfach manuell eingegeben, was jedoch häufig falsch war und ich es korrigieren musste.

Die Lösung

Dies schien der perfekte Anlass zu sein, ein neues benutzerdefiniertes Feld zu erstellen – nennen wir es „Entfernung zu". Der Code ist unten aufgeführt, aber es gibt zwei Möglichkeiten, dieses Feld zu verwenden:
#1 Wir könnten das Feld einfach hinzufügen und den Nutzer GPS-Koordinaten eingeben lassen – zum Beispiel für ein Feld „Nächster Flughafen", in das der Nutzer die GPS-Daten des ihm nächstgelegenen Flughafens eintragen kann.
#2 In diesem Fall muss der Nutzer nur die Entfernung zu einem bestimmten Ort anzeigen, ohne dass der Nutzer überhaupt von dem Feld wissen muss. Beim Hinzufügen des benutzerdefinierten Felds würde er es daher als „nur Admin"-Feld festlegen, sodass es dem Nutzer im Frontend nicht angezeigt wird und er es nicht ändern kann. Anschließend setzt er den „Standardwert" auf die benötigten GPS-Koordinaten – und alle Einträge zeigen dann die gewünschten Informationen an.

Der Code

Dieser Beitrag erklärt, wie Sie das Problem „This page didn't load Google Maps correctly. See the JavaScript console for technical details.

If you are using GeoDirectory please see our documentation hier.

If you want to read about the problem see our blog post here: https://wpgeodirectory.com/google-maps-api-key-and-new-limits/

If you have seen the message “This page didn’t load Google Maps correctly. See the JavaScript console for technical details.” or any of the following messages:
“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.”
„Beim Laden von Google Maps auf dieser Seite ist ein Problem aufgetreten.

Wahrscheinlich benötigst du diesen Fix. Wenn du WordPress verwendest, haben wir ein Plugin erstellt, das das Problem für die meisten Nutzer beheben sollte, deren Plugin oder Theme die Ursache ist. Du findest es hier: GOOGLE MAPS API KEY FIX

Wenn du WordPress nicht verwendest, musst du den Aufruf von Google Maps in deinem Quellcode finden und den API-Key hinzufügen. Eine Anleitung zum Erstellen eines API-Keys findest du hier. Sobald du deinen API-Key hast, fügst du ihn deinem Aufruf der Google Maps-Datei hinzu: maps.google.com/maps/api/js?key=YOUR-API-KEY-HERE

Ich hoffe, das war hilfreich – Feedback ist jederzeit willkommen.

Das GeoDirectory-Team.

Wir freuen uns, die Unterstützung für Snazzy Maps in unserem Custom Google Maps-Addon (1.0.5).

Was ist Snazzy Maps?

Snazzy Maps ist eine Online-Ressource, die es Benutzern ermöglicht, die Farben, Sättigung und andere Stiloptionen ihrer Google Maps anzupassen.

Die Anpassungsoptionen werden in Form verschiedener Kartenstile angeboten, die von verschiedenen Autoren im Web entworfen wurden.

Neben der Bearbeitung von Karten mit Snazzy Maps können Benutzer ihre eigenen Snazzy Maps-Stile zur Verwendung auf ihren Websites oder in ihren Apps erstellen.

Alle angepassten Karten bieten zudem hochauflösende Satellitenbilder und Vektorunterstützung für Web- und Mobilgeräte.

Mit diesen Funktionen können Unternehmen und Entwickler gleichermaßen optisch ansprechende Karten für ihre Projekte erstellen, ohne auf Programmierkenntnisse angewiesen zu sein.

Warum haben wir Snazzy Maps-Unterstützung für GeoDirectory hinzugefügt?

Vor etwas mehr als einer Woche machte uns eines unserer Mitglieder, `Pieter Ravelli`, auf die Website aufmerksam, und sie traf einen Nerv bei unserem Team – deshalb rückte sie ganz oben auf unsere Entwicklungsaufgaben.

Das ist unser Ethos hier bei GeoDirectory. Wenn ein Mitglied etwas vorschlagen kann, das allen Mitgliedern zugute kommt, werden wir es gerne umsetzen.

Snazzy Maps-Stile in GeoDirectory importieren

Das Hinzufügen von Snazzy Maps zum GeoDirectory Custom Maps-Addon ist relativ einfach.

Gehen Sie zunächst zu snazzymaps.com und suchen oder erstellen Sie einen Stil, der Ihnen gefällt.
Sobald Sie sich auf der gewünschten Seite befinden, sehen Sie eine Kopierschaltfläche. Klicken Sie darauf.
Gehen Sie anschließend zu Ihren GeoDirectory-Einstellungen und navigieren Sie zu GD>Custom Google Maps>Manage Styles und klicken Sie auf Bearbeiten der Karte, die Sie ändern möchten.
fügen Sie Ihren Stilcode von Snazzy Maps ein und klicken Sie auf die Schaltfläche „Stile importieren & speichern".
Jetzt werden Ihre neuen Kartenstile auf Ihrer Website verwendet.

Verwenden Sie Snazzy Maps mit GeoDirectory? Wenn ja, welchen Stil verwenden Sie? Lassen Sie es uns in den Kommentaren unten wissen.

Das weltweit fortschrittlichste und skalierbarste WordPress-Verzeichnis-Plugin