WordPress als link netwerk

Tijdens WordPress Köln vertelde Andreas Graap over hoe hij een link netwerk aandrijft door middel van WordPress multisite en domain mapping. Ook vertelde hij over de optimalisatie van de websites.

Andreas Graap verteld ons over de ins-en-outs over het runnen van WordPress als link netwerk. Hij is zelf de uitbater van een WordPress multisite installatie van 180 domeinen. Om dit te realiseren gebruikt hij onder andere de WordPress MU Domain Mapping plugin.

Hij vervolgt zijn verhaal door te vertellen hoe hij aan ‘hoge kwaliteit’ domeinnamen komt. Hij probeert hier zoveel mogelijk keyword-rich domains voor te gebruiken maar ook expired domains die al een mooie pagerank hebben opgebouwd. Omdat het voor SEO doeleinden ook belangrijk wordt geacht om de verschillende domeinen op verschillende class C IP adressen te hosten maakt hij hiervoor gebruik van verschillende hostingpartijen die zich specifiek op dit soort diensten richten.

De looks

Omdat het oog ook wat wil en men soms, om wat voor een reden dan ook, niet de associatie wil hebben met een van de andere domeinen geeft Andreas ieder domein een eigen theme. Hij noemt vervolgens enkele theme leveranciers die hoogwaardige themes leveren voor weinig geld.

(SE)O

Andreas adviseert vervolgens vooral voor snelheid te optimaliseren. Dit kan bijvoorbeeld door scripts met een kleinere footprint te gebruiken, investeren in goede hosting etc. Voor SEO doeleinden adviseert hij de WordPress SEO plugin van Joost de Valk, hij merkt er wel bij op dat hij zijn themes niet over-optimaliseert voor SEO, hij vindt dat Google nog wel een beetje moeite moet doen.

Content

Daarnaast huurt Andreas’ bedrijf voor de verschillende domeinen verschillende schrijvers in om zo ook de stijl zoveel mogelijk te laten verschillen. Op deze manier probeert hij zoveel mogelijk de sites voor de bezoeker te optimaliseren, door ze altijd een andere stijl/ervaring te laten beleven.

Tot slot

Andreas is nu bezig met een experiment om zijn ‘dode’ websites te scrapen naar statische HTML om ze vervolgens onder te brengen bij goedkope ( vaak zelfs gratis ) hosting partijen. Op deze manier hoopt hij met minimale kosten toch nog een fraai resultaat te halen. Hij gaat binnenkort zijn bevindingen hierover – op SEO gebied natuurlijk – met de wereld delen.

WordPress heeft plugin dependencies nodig

Iets waar WordPress plugin ontwikkelaars al een tijd tegenaan lopen is het feit dat ze geen dependencies voor hun plugin op kunnen geven. Dependecies in deze zin zijn vereiste andere plugins om functionaliteit van de te installeren plugin te garanderen. Dit is iets waar iedere Linux, maar ook bijvoorbeeld, Drupal gebruiker ongetwijfeld ervaring mee heeft.

Het voordeel voor ontwikkelaars is dat zij, wanneer ze meerdere plugins ontwikkelen met veel terugkerende functies, dat dan in een algemene functie library (plugin) kunnen opzetten en deze als dependency kunnen opgeven.

Niet alleen voor ontwikkelaars

Ook de eindgebruikers zullen hier baat bij hebben. Mijn populairste plugin brengt ondersteuning voor iDeal transacties naar WP e-Commerce, ik krijg echter een keer per week een support request om mijn plugin te configureren om vervolgens te ontdekken dat de gebruiker geen WP e-Commerce geïnstalleerd heeft. Nu klinkt dit vooral als ‘lastig’ voor mij maar de persoon die contact met mij opneemt voelt zich vaak bezwaard om dit te doen.

Niet iedere gebruiker zal de documentatie of FAQ van je plugin lezen maar als dependencies goed zichtbaar gemaakt worden, desnoods met uitleg, dan voeden we de eindgebruiker ook een beetje op.

In de praktijk

Nog een praktijkvoorbeeld is de plugins van Joost de Valk. Bij de meeste van zijn plugins tref je het bestand yst_plugin_tools.php aan. In dit bestand verzamelt Joost een reeks functies die hij vaker gebruikt over meerdere plugins. Wanneer hij deze functies in een aparte plugin zou kunnen plaatsen en deze als dependency kan opgeven voor bijvoorbeeld WordPress SEO dan scheelt dat niet alleen een paar kb per plugin maar het maakt plugins in theorie ook makkelijker te beheren. Stel Joost vind een betere best practice voor een functie die hij nu in yst_plugin_tools.php heeft staan dan zou hij deze voor al zijn plugins in één keer kunnen updaten op de geschetste manier.

Maar je kunt ook denken aan het aanbieden van algemene libraries voor bijvoorbeeld online betalingsdiensten. Wanneer PayPal of iDeal een algemene plugin ter beschikking zou stellen met de basisfunctionaliteiten voor hun product of dienst en ontwikkelaars alleen nog maar de brug hoeven te leggen tussen hun plugin en deze library dan kunnen zij eenvoudiger een goede werking van hun koppeling garanderen en bespaart dit andere ontwikkelaars veel tijd.

De valkuilen

Natuurlijk heeft het dependecy systeem ook zijn valkuilen. Wat kan een gebruiker doen wanneer plugin x versie >=1.0 van plugin y vereist en plugin z versie <1.0 van plugin y? Dit levert natuurlijk vervelende situaties op.

Daarnaast is er ook het risico wanneer teveel ontwikkelaars gebruik gaan maken van een bepaalde dependency en deze ineens niet meer doorontwikkeld wordt of bepaalde compatibiliteit verwijderd. Hiermee zouden eindgebruikers onnodig gedupeerd kunnen worden.

Dit zijn beiden punten waar wij als WordPress community op moeten anticiperen.

Hoe nu verder?

Ontwikkelaar Silviu-Cristian Burcă heeft al een mooie plugin voor een dependency systeem opgezet. Jammer genoeg werkt dit dependency systeem niet zonder zijn eigen plugin en daarin ligt natuurlijk ook de nodige ironie. Daarnaast staat deze plugin nog enigzins in de kinderschoenen omdat er geen versie informatie aan de dependencies gekoppeld kan worden.

Ik verwacht dat we pas na WordPress versie 3.3[ref]Uit Andrew Nacin’s reacties op dit artikel wordt in versie 3.3 het redirect/rewrite systeem van WordPress stevig op de schop genomen. Ik verwacht dat dit zoveel werk zal zijn dat er niet nog een grote nieuwe feature in deze versie zal zitten.[/ref] een keer een dependency systeem in de core kunnen verwachten. Er is steeds meer vraag naar (#10190, #11308, #12612) maar eigenlijk moet de discussie eens goed opengebroken worden en alle aspecten belicht worden. Het idee vereist namelijk ook aanpassingen op WordPress.org.

WordPress kan op dit gebied in ieder geval veel leren van de fouten die door de Drupal community zijn gemaakt, zo had Drupal tot versie 7 geen versie indicatie voor dependencies maar had ook de community problemen met de adoptie hiervan. Ik weet zeker dat als we als WordPress community eens goed de koppen bij elkaar steken dat wij het wel in één keer goed doen.