Op hoeveel paarden wed je op de renbaan, spreekwoordelijk in ieder geval op meer dan een. Je hebt meerdere sites, op verschillende servers staan, je promoot meerdere webwinkels via verschillende affiliate netwerken, toch? En toch ben je voor bezoekers volledig afhankelijk van 1 bron: google?

Toegegeven het was en is niet echt makelijk, google heeft een behoorlijke dominantie met meer dan 90% marktaandeel. Nederland is hiermee koploper, zou ‘gratis’ ermee te maken hebben dat we ons volledig afhankelijk hebben gemaakt. (ik tik dit verhaal trouwens in google docs) En het was eigenlijk altijd relatief makkelijk om in ieder geval op de long tail lekker te scoren in google.

Helaas is dat over. Heel veel affiliate sites hebben harde klappen gehad. Toch is het niet helemaal uit de lucht komen vallen, de regels van google over thin-affiliate sites waren al lang duidelijk. Men is ze alleen strengen en concequenter gaan toepassen. Wellicht om ruimte te maken voor hun eigen thin-affiliate sites onder de noemer google shopping? We zijn met zijn alleen verslaafd geraakt aan de gratis diensten van google, maar ook gratis moet ergens zijn geld verdienen.

Daarnaast is er de afgelopen tijd een toename geweest van zowel hobby webmasters die een graantje wilden meepikken als de meer profesionelle sites die hun deel van de markt opeisen. Grote vergelijkingssites, cach-back en kortingscodes sites bieden de bezoeker wat ze willen, informatie en koopjes.  Afgezien dat google het moeilijker maakt is er ook nog eens veel meer concurrentie, zowel in kwantiteit als kwaliteit.

‘content is king’ een site met unieke inhoud scoort goed in google, of scoorde? Het schrijven van unieke inhoud is zo moeilijk niet, dat het een prettig leesbaar verhaal is is een tweede. Het schrijven van unieke informatie is al een stuk lastiger. Welke bezoeker zal het boeien dat op jouw site het duizend-en-eenste verhaaltje over Arabië staat? Google net zo min. Wat gaat jouw site onderscheiden zodat een bezoeker jouw pagina’s gaat bookmarken, liken en tweeten, en zorgt ervoor dat hij nog een keer terugkomt.

Wellcht nog belangrijker dan content is het concept van de site, wat is het USP van je site. Dat geld voor affilaite sites, waar je site in feite je product is. Maak ook sites die een product aan de man proberen te brengen. Wat onderscheid jouw webwinkel?

Het concept hoeft niet zo vernieuwend te zijn als marktplaats een tijdje terug of twitter en facebook.

Geld verdienen zou bij het bedenken van een concept van een site op het tweede plan moeten staan, wat wil ik bieden wat nog nergens anders op deze unieke manier te vinden is.  Uniek als in anders of beter dan de anderen. Er zijn voldoende niches waar de grote vergelijkingssites het laten liggen, kunst is alleen ze te vinden, en er genoeg bezoekers voor te krijgen.

Is er nog geld te verdienen met affiliate (feeds). Zekers maar je zult er (weer) hard voor moeten werken. Site/Concept/Content en dan pas cashen. Of een heel briljant idee hebben.

Bij gebruik van SEF url's Dus als je gebruik maakt van het .htaccess bestand ( htaccess.txt in de joomla download) kun je een error 500 voor de kiezen krijgen.

Het kan zijn dat je hoster geen rewrite ondersteund, of dat de hoster geen options toestaat, Als het eerste niet mag kun je de sef url's niet gebruiken i.c.m. mod_rewrite. De options parameter kun je redelijk veilig weghalen uit de htaccess

In principe is elke host die mysql/php ondersteund geschikt om een joomla site met datafeeds te hosten. Vrijwel elke hoster die zijn systemen een beetje onderhoud voldoet aan de systeem eisen. De datafeeds component wijkt in zovere af van 'gewoon' joomla dat uitgaande http verbindingen van belang zijn. Problemen kunnen ontstaan door de libxml bug of door een combinatie van veiligheidsinstellingen ( allow_url_fopen, safe mode, base dir restrictions). Dit zijn gegevens die je pas ontdekt als je joomla draaiende hebt.

Hoeveelheid ruimte

Joomla zelf neemt een megabyte of 40 in beslag.  de omvang van de database is afhankelijk van de hoeveelheid content en feed-items. per 1000 items ben je ongeveer een megabyte aan database ruimte kwijt.

Gratis Hosting byet

byethost bied gratis hosting aan met voldoende ruimte en mogelijkheden om joomla en de datafeeds compoment uit te proberen.

Ga naar de site byet en registreer je voor een gratis pakket. Gebruik als 'username' de naam van het subdomein dat je wilt hebben.

Na de registratie kun je inloggen op hun cpanel, maak hier een database aan. De cpanel biedt de mogelijkheid om joomla te installeren, controlleer echter dat dit de laatste versie is. Download anders de engels of nederlandse joomla versie en upload deze via ftp.

• joomla.org
• dutchjoomla.nl
• joomlacommunity.eu

als je de datafeeds component installeerd zonder dat de nederlandse taalbestanden van de joomla core aanwezig zijn zal de nederlandse versie van de component niet geinstalleerd worden. Installeer dan de nederlandse taalbestanden en aansluitend de component opnieuw.

Installeer joomla, de database host is niet localhost, kijk in de cpanel (links ) wat de host name is. Het installeren van extensies werkt zonder ftp-layer, die stap kun je overslaan.

Daarna de component installeren via het extensions menu, data downloaden en klaar.

byethost demo

joomsef is net als smartsef een component om de url nog vriendelijker te maken joomla dan  zelf als doet.

De component draait op zich prima met joomsef.

Aangezien er  geen plugin/ extension van com_datafeeds voor joomsef is zal joomsef de gewone joomla links gebruiken.Om voor com_datafeeds dan zoekmachine vriendelijke links te krijgen zul je in de configuratie de SEF Url's van joomla moeten inschakelen.

De datafeeds component maakt zelf al zoekmachine vriendelijke url's met informative links volgens de SEO richtlijnen van google.

Alle links die door joomsef worden aangemaakt worden opgeslagen in de database. Dit wordt een aardige verzameling bij een site van een beetje omvang.

Een zeer ernstig probleem met joomsef is dat na het purgen van de database je complete site onvindbaar is !

De meer recente versies van de compoment bevat de mogelijkheid een functie aan te roepen op het moment dat een feed succesvol geparsed is. Een mogelijkheid hiervan is om bijvoorbeeld na elke update automatisch een bericht te plaatsen op een weblog. Dat kan dezelfde joomla installatie zijn of een willekeurige andere weblog.

Voorbeeld toepassing

In de feeds-example.php vind je een stukje code, als je deze code overneemt in je eigen feeds.php zal als alles goed gaat de site toppers.gryla.nl automatisch van een post voorzien worden bij elke update van een feed. toppers.gryla.nl is een wordpress installatie met een iets aangepast versie van xmlrpc

Er zit een bug in php/libxml die  html encoded characters kwijtmaakt '& amp;' '& lt;' '& gt;' enzovoorts. In de feed configuratie zie je dat bij de ruwe data de &'s missen in de url.

Dit probleem is opgelost in libxml 2.7.3 in combinatie met php 5.2.9. Upgraden is de beste uitweg. Zit je niet op een eigen server en moet je je host overtuigen? Van het probleem heeft niet alleen deze joomla component last maar ook gebruikers van bijvoorbeeld wordpress.

Andere workaround is alleen csv bestanden te gebruiken, of voeg ( versie 608 en hoger) een define toe aan je feeds.php

define('LIBXML_BUG','yes');

Meer info bij php of leef je uit met google

In principe kun je een joomla-installatie met com_datafeeds net zo verplaatsen of copieren als je met een gewone joomla installatie zou doen. Bestanden zippen,copieren,ftpen (whatever) database dumpen. Op nieuwe locatie configuration.php aanpassen voor nieuwe locatie en database, database importeren en klaar.

Tikje tricky is de mogelijke omvang van de dataitems tabel. Die is al gauw een paar mbytes groot. Nu is het helemaal niet nodig om de dataitems ook te verplaatsen, met een run van de feedcron heb je de tabel weer gevuld.

Houd er rekening mee dat de doorsnee shared-host niet is ingericht op databases die groter zijn dan enkele (tientallen) Megabytes. datafeeds verbruiken circa 1 Mbyte per 1000 items. Als de tabel met items te groot wordt ga je dat in de performance merken, http requests duren langer,  de server krijgt ze niet weggewerkt en de http-processen stappelen zich op. Met name mod_datamenu's (de menu's/zoek versies) kunnen vrij zware query's opleveren. In het minst ergste geval schopt je hoster je de deur uit, erger is dat je bezoekers afhaken.

Op een goede shared host moet het geen probleem zijn websites met 20-40 duizen items te hebben.

Hieronder een rijtje met tips. Met (shared) is aangegeven of deze aktie op een shared host mogelijk is. De meeste tips zijn niet joomla-datafeeds specifiek maar algemeen te gebruiken.

In onderstaande wordt uitgegaan van de standaard configuratie van joomla met de prefix jos_, pas dit eventueel aan.

Website splitsen (shared)

Het splitsen van de website in meerdere is een oplossing om de database klein te houden, helaas ondersteund joomla multi-site niet lekker ( er zijn componenten voor te koop ) dus heb je hier meerdere keren onderhoud.

Joomla cache (shared)

Wat goed helpt is het inschakelen van de cache van joomla. Meestal is het inschakelen van cache voor modules geen goed plan omdat joomla dit wat knullig cached ( niet pagina afhankelijk ). De caching van mod_datamenu houdt er rekening mee dat elke pagina een andere (en zelfs meerdere) module-inhoud toont. Echter omdat de feeds uit heel veel items bestaan met heel veel menu's en submenu's komen er ook heel veel bestanden in de cache te staan. Hier heb je dus weer flink ruimte nodig op schijf. En er zijn ervaringen dat de file cache weer langzaam wordt als er veel bestanden instaan.

waarschuwing : Op een omvangrijke site (veel menu's) kan de cache heel groot worden ( Gig's) er is dan kans dat je in de problemen komt om de cachee weer te wissen !!!

sessions op none (shared)

In de standaard installatie slaat joomla de sessions op in de database. Dat zijn een aardige hoeveelheid lees en schrijf akties. Je kunt de session ook file based maken door de setting op 'none' te zetten. Dan slaat php de sessies op de disk op. Dat kan per saldo voordeliger zijn.

Nog mooier zou zijn de sessies voor de frontend uit te schakelen, of en hoe dit kan moet nog uitgezocht worden. In feite is heel het sessie verhaal onzinnig zolang men niet inlogt ( ok, ok er zijn modules en plugins die het wel nodig hebben....)

php zlib compressie (shared)

php heeft de mogelijkheid om de content (de genereerde html) te bufferen en voor versturen te comprimeren. Dit heeft het voordeel dat er minder bandbreedte nodig is. Dat is ( was met huidig breedband ? ). Als je bij je host op een budget zit met betrekking tot bandbreedte kan het een optie zijn zlib aan te zetten om te sparen.

Keerzijde is dat bij output buffering die hele content op de server blijft totdat alles gereed is, bij ongebufferde output gaat de zaak meteen de deut uit, er is dus minder geheugen nodig. Daarnaast is er voor het comprimeren op het einde extra performance van de server nodig.  Het kan dus helpen zlib compressie uit te zetten.

Bij websites als deze bestaat bovendien een groot deel van de data uit niet php output ( javascript, afbeeldingen, stylesheets) en het is maar de vraag of je met zlib compressie veel bespaart.

• in php.ini zlib.output_compression = On/Off
• in .htaccess php_flag zlib.output_compression on/off

Een alternatieve manier om compressie toe te passen is via de apache server zelf. Terwijl er zelf ervaring zijn met een negatieve invloed op de performance bij php-zlib compressie, zijn er op dezelfde server positieve ervaringen met AddOutputFilterByType DEFLATE

MySQL Indexen optimaliseren (shared)

Als mod_datamenu gebruikt wordt om content aan het dataitems menu te koppelen (artikel variant) dan voert de module een zoekaktie uit op de alias in jos_content hier is geen index op:

ALTER TABLE `jos_content` ADD INDEX ( `alias` ) ;

mysql

De belangrijkste parameter om de performance van mysql te beinvloeden is geheugen. Hoe meer geheugen hoe meer mysql in geheugen kan cachen en hoe beter de performance wordt. Aangezien geheugen akties nog steeds een factor sneller zijn dan lezen en schrijven van de harddisk. Daarnaast is het zaak het geheugen binnen joomla goed toe te wijzen belangrijke parameters:

• mysql key_buffer

• mysql query_buffer

• mysql table_cache

• delay_key_write

mysql verdere tips

Nog een paar opties die je kunt overwegen om met name ruimte te besparen:

• skip-networking
• skip-bdb
• skip-innodb

Waarschijnlijk zijn er bij de installatie van MySQL een aantal voorbeeld configuraties meegeinstalleerd. zoek op de hardeschijf of google op my-huge.cnf my-large.cnf. Prima inzicht in de mogelijkheden, met aardig wat uitleg

mysql slow queries

Interresant is het om te weten waar het misgaat. MySQL heeft de mogelijkheid queries die erg lang nodig hebben te loggen met behulp van de volgende opties. In de server status via phpmyadmin kun je trouwens zien hoeveel slow queries er zijn.

• log_slow_queries
• log_long_format

En om te kijken welke queries geen index gebruiken en dus potentieel traag zijn:

• log-queries-not-using-indexes (mysql > 4.1)

Met laatste parameter kan er een flinke hoeveelheid langskomen, wellicht geen goed idee deze logging altijd aan te hebben

Waar de log-file dan staat is afhankelijk van je omgeving

my.cfg voorbeeld

Onderstaande configuratie voor mysql houd databases met bijna 200.000 items draaiende op een VPS met 786MBytes geheugen. Af en toe is het wat krap.

{include_code_listing /var/www/www.affiliatefeeds.nl/images/code/my-cfg-89.txt}

accelerators (shared ? )

Er zijn verschillende php accelerators, Zend, fastcgi en meer. Dit zou allemaal prima smaen moeten werken met joomla+datafeeds maar er is nog geen ervaring mee.

Eigen Hosting

Aan de mysql parameters sleutelen mag op een shared host meestal niet. De oplossing is dan een VPS of Dedicated Server.

Een eigen server is ook de oplossing als je joomla cache erg veel ruimte in beslag neemt.

En verder

als het nog wilder wordt ga dan denken aan meerdere servers. Aparte server voor mysql, mysql database splitsen over meerdere schijven, andere database engine (InnoDB), meerdere apacher servers, squid als proxy/load balancer. Maar bovenal meer geheugen..

Heb je tips, kommentaar of aanvullingen? Graag !

Er zijn op dit moment geen plannen de component naar wordpress om te bouwen.

Het is echter wel mogelijk de  producten vanaf een joomla datafeeds site te gebruiken in een wordpress site.

Zie bijvoorbeeld sneeuwwandelen in Oostenrijk.

Als je eenmaal de joomla datafeeds draaiende hebt, is het integreren in wordpress vrij eenvoudig.

De noodzakelijke scripts worden aangeboden als (betaald) maatwerk.

Neem contact op als je belangstelling hebt.

Smartsef werkt niet goed samen met een aantal varianten van de module. Smartsef past url's aan onder andere de spaties. Hierdoor werken de queries niet meer.

Smartsef voor joomla 1.5 is al een tijdje niet onderhouden, de smartsef site werkt niet en de extension komt niet meer voor op extensions.joomla.org. Er zijn aanpassingen geweest in joomla sinds de laatste versie van smartsef. Dit zijn al een aantal redenen om smartsef niet meer te gebruiken. In ieder geval een reden om op dit moment geen tijd een smartsef te willen steken.

Er zijn aan aantal situaties waarin smartsef wellicht toegevoegde waarde heeft, voor joomla 1.0 had het dat zeker. Joomla is een stuk beter geworden in het maken van 'Search Engine Friendly' Url's en zoekmachines zijn heel veel beter geworden in het verwerken van de zoekmachine onvriendelijke URL's. Er is zeker nog wat voor de tegen om de Url's een wat fraaier uiterlijk te geven maar de term HRF ( Human Reader Friendly) zou veel beter zijn. 

Een zeer ernstig probleem met smartsef is dat na het purgen van de database je complete site onvindbaar is !

Een aantal zaken die smartsef regelt ( bijvoorbeeld de beroerde error meldingen in joomla-core ) zijn ook via de template en .htaccess te regele.

Com_datafeeds doet aardig zijn best om de url vriendelijk te maken, daar is eigenlijk geen rewritting meer voor nodig. Een probleem met com_datafeeds is is dat er heel veel links zijn, en dus de url-repository van smartsef nogal groot wordt. Overhead die ik je kan afraden.