<\/a><\/p>\nWaarom zijn die pleisters eigenlijk nodig?<\/h2>\n
Wat is de onderliggende oorzaak hiervan? Het komt doordat WPML probeert van een WordPress-site iets te maken waar het niet voor bedoeld is: volledige meertaligheid op \u00e9\u00e9n site. Dit wordt vooral duidelijk wanneer een WooCommerce-site wordt gecombineerd met WPML. Bij het bewerken van producten in een andere taal verschijnt een maatwerk dashboard, waardoor het vermogen om het volledige product te bewerken verloren gaat.<\/p>\n
De voordelen van wpMula<\/h2>\n
Kan het niet anders? Er moet toch een slimmere manier zijn om een WordPress-site meertalig te maken? Een manier die compatibiliteit met andere plugins behoudt\u2026 zonder pleisters? Dat kan inderdaad! Via de multisite-techniek kan voor elke taal een aparte subsite worden opgezet binnen \u00e9\u00e9n WordPress-installatie. Enkele voordelen:<\/p>\n
1. Elke subsite heeft zijn eigen set aan databasetabellen.<\/strong>
\nBij de WPML-opzet worden alle posts (pagina\u2019s, berichten, etc.) in \u00e9\u00e9n tabel opgeslagen. Stel dat een site vier talen heeft: \u00e9\u00e9n bericht wordt dan vier keer in de posts-tabel opgeslagen. Elk bericht heeft ook metadata, bijvoorbeeld voor de uitgelichte afbeelding. Dit leidt tot een opstapeleffect: ook de metadata wordt vier keer opgeslagen. Heeft een bericht 10 metadata-rijen, dan zijn dat 4 \u00d7 10 = 40 extra rijen voor \u00e9\u00e9n bericht. Voor 100 berichten wordt dit aanzienlijk. Op kleine sites valt dit niet direct op, maar op grotere sites vertraagt dit het openen van pagina\u2019s aanzienlijk, omdat de tabellen telkens doorzocht moeten worden.<\/p>\nIn een multisite-opzet gebeurt dit niet. Elke subsite heeft eigen tabellen die alleen de posts van die taal bevatten. Posts worden netjes verdeeld over de subsites, wat de snelheid van queries aanzienlijk verhoogt. Dit geldt niet alleen voor posts, maar voor alle tabellen: opties (sitenaam, permalinks) en termen (categorie\u00ebn, tags en menu\u2019s).<\/p>\n
2. Elke subsite biedt volledig WordPress-beheer.<\/strong>
\nEr zijn geen beperkingen bij het beheren van een site in een multisite. Beheerders zien op elke subsite een volledig dashboard. Geen workarounds nodig, puur WordPress.<\/p>\n3. Bijna alle plugins en thema\u2019s zijn compatibel met de multisite.<\/strong>
\nOmdat multisite een kernfunctionaliteit van WordPress is, zijn bijna alle plugins en thema\u2019s compatibel. Er zijn geen trucs of pleisters nodig, en er zijn geen extra plugins vereist.<\/p>\n4. Per subsite kan een domein worden gekoppeld.<\/strong>
\nEen handige toevoeging maakt het eenvoudig om meerdere domeinen aan een site te koppelen. Bijvoorbeeld example.nl voor de Nederlandse versie en example.com voor de Engelse versie. Dit kan naast de standaard subdirectory-opties (example.com\/en\/) of subdomein-opties (en.example.com). Zo kan elke vertaling onder een passend domein worden aangeboden.<\/p>\nVoorsprong en toekomstvisie<\/h2>\n
Op dit moment heeft WPML nog het voordeel van een voorsprong in ontwikkeling. WPML bestaat al veel langer en sommige functionaliteiten zijn daarom \u2018volwassener\u2019. Er zijn al veel pleisters beschikbaar om problemen op te lossen die er eigenlijk niet zouden moeten zijn. Daar komen wij in beeld! Met een solide basis en de juiste technische aanpak hebben we vier jaar ervaring opgebouwd met sites zoals Elementor, Gutenberg en WooCommerce, inclusief handige functies voor het dupliceren van een bericht, pagina, categorie of zelfs een hele site voor een nieuwe vertaling.<\/p>\n
Een nieuwe feature die gepland staat: het automatisch omzetten van een WPML-site naar wpMula. Onze toekomstvisie is om een zo groot mogelijk publiek aan te spreken, inclusief huidige WPML-gebruikers. Daarnaast komt er een integratie met DeepL, zodat content eenvoudig en automatisch vertaald kan worden.<\/p>\n
Laat je site alle talen van de wereld spreken.<\/p>\n <\/div>\n