Webshops die adsense-advertenties vertonen

Bezoekers die bijvoorbeeld de volgende pagina op drogisterij.net bezoeken. Zien naast het aanbod van cadeau-artikelen in de rechterbenedenhoek advertenties staan. Deze adsense-advertenties kunnen drogisterij.net geld opleveren als de bezoeker er op klikt. Toch lijkt het een beetje vreemd. Zelf zou ik denken dat iemand een webshop opent om producten te verkopen. Daarbij kies je dan voor producten met een goede winstmarge of een hoge omloopsnelheid. Op die manier kan geld verdiend worden met de webshop. Om geld te verdienen zijn in de eerste plaats bezoeker (klanten) nodig. Wanneer de bezoeker dan eindelijk op de website terecht is gekomen en een bestelling kan gaan plaatsen, dan wil je toch niet dat die via een advertentie weer verdwijnt??

Gezien de advertenties context gebonden zijn, zullen deze vaak verwijzen naar een vergelijkbare websites. Zo’n webshop zal dus te maken hebben met dezelfde winstmarges. De winstmarges op drogisterijartikelen zouden dus zo laag zijn, dat een klik (het doorsturen van een klant) naar de concurrent meer oplevert. Die concurrent kan daarop dan blijkbaar wel winst maken, zelfs na het betalen voor de advertentie. In het geval van een website wordt de winst natuurlijk ook gedrukt door bijvoorbeeld verzendkosten. Je zou dus haast denken drogisterij.net is door het productaanbod wel in staat geïnteresseerde bezoekers naar de website te krijgen. Vervolgens lukt het alleen niet om die producten ook met voldoende winst te verkopen. Bedrijven die dat wel kunnen zijn dus bereid op deze website te adverteren.

Op zich is er niets mis met deze strategie. Sterker het lijkt erg op de affiliate marketing, die ik ook op mijn eigen websites, zoals Lifestyleshop.be gebruik. Toch zie ik een probleem… drogisterij.net is namelijk bij verschillende affiliates-netwerken zoals kliks.nl en tradetracker aangesloten. Dat betekent dat drogisterij.net webmasters betaalt voor het sturen van bezoekers naar haar website. In dit geval is de betaling echter gekoppeld aan een daadwerkelijke verkoop. Wanneer ik nu met veel moeite een bezoeker zo ver gekregen heb dat hij / zij misschien iets wil gaan kopen op deze website, is het toch vreemd dat drogisterij.net deze klant weer ‘doorverkoopt’. Grootste probleem daarbij is voor mij natuurlijk dat ik geen percentage ontvang van de adsense inkomsten, maar dat wel had gedaan als de bezoeker een product had gekocht. Dit is misschien nog wel vervelender dan het vermelden van een telefoonnummer voor bestellingen of het sluiten van de webshop op zondag.

Mogelijk hebben ze er bij drogisterij.net net iets langer over nagedacht. Misschien staat de advertentie niet voor niets in de rechterbenedenhoek. Een website bezoeker die op dat punt van de pagina is beland, heeft blijkbaar niets gevonden wat hij wil kopen. De bezoeker heeft dan een keuze doorklikken naar een andere pagina van drogisterij.net of de website verlaten. Met een beetje rekenwerk zou je kunnen uitrekenen wat een bezoeker die doorklikt gemiddeld oplevert. Mogelijk is de opbrengst daarvan minder dan de opbrengst van de advertentieklik. Mij lijkt dit overigens geen lange termijn strategie, want zou de waarde van de klik inderdaad zo hoog zijn (of de winstgevendheid zo laag), dan zou deze webshop de mogelijkheid om iets te bestellen beter helemaal kunnen verwijderen. Elke doorklik van een bezoeker maakt de kans op bestellen kleiner en de kans op een exit (uitstapmoment) groter. Betaald krijgen voor de exit levert drogisterij.net op korte termijn misschien een kleine winst. Voor de webmasters die deelnemen aan het affiliatesprogramma van drogisterij.net is het i.i.g. altijd verlies, omdat er nog steeds een kans was dat er uiteindelijk een bestelling zou volgen.

Belangrijke vraag is natuurlijk hoeveel procent van het doorgestuurde verkeer komt uit de affiliate marketing? Webmasters kunnen kiezen voor een andere aanbieder zoals dokteronline of De Online Drogist. Voor webshops is affiliate marketing een relatief goedkope en doeltreffende manier om klanten te werven. Wanneer webshops dit beseffen en er vervolgens goed mee omgaan, kan een echte win-win situatie ontstaan. Webmasters kunnen echter net als klanten overstappen naar de concurrent, zo’n overstap betekent zowel op korte als op lange termijn een verlies voor de webshop.

Mocht de hier besproken strategie toch iets opleveren, dan zullen ‘interesses gebaseerde advertenties‘ dit mogelijk nog interessanter maken.

Adsense gaat interesses aan de advertenties koppelen

Afgelopen weekend ontvingen webmasters die gebruik maken van Adsense de officiële aankondiging van Google. Vanaf april zal Adsense gekoppeld worden aan het surfgedrag en de interesses van de websitebezoeker. Het gedrag en de voorkeur van de bezoekers wordt vast gelegd d.m.v. cookies. Google maakt hiervoor gebruik van de technologie van Doubleclick.com. Doubleclick.com werd alweer bijna twee jaar geleden door Google overgenomen.

Google maakt webmasters er op attent, dat het privacybeleid van de websites die adsense gebruiken mogelijk moet worden aangepast. Bezoekers horen te weten dat hun surfgedrag geanalyseerd wordt zodat daarmee ook op andere websites de advertenties kunnen worden aangepast. Vanwege de privacy zal Google ook gebruik maken van de Dart-cookies van Doubleclick.com. Uiteraard beschikt Google via de Google toolbar en de Google zoekmachine al over veel meer gegevens van de bezoekers van websites.

De gekoppelde gegevens van een bezoeker bepalen het interesse-profiel van een websitebezoeker. Adverteerders die via Adwords advertenties kopen voor het adsense programma kunnen hier hun advertenties op aanpassen. Advertenties zullen dus niet langer alleen gericht zijn op de inhoud van een website of internetpagina. Adverteerders kunnen hun advertenties richten op mensen met hetzelfde interessegebied. Ook wordt het mogelijk advertenties aan te passen op het surfgedrag. Dan kan de adverteerde er voor kiezen de advertenties alleen te tonen aan bezoekers, die zijn website al eerder bezochten of juist nog nooit.

Websitebezoekers zullen mogelijk problemen zien m.b.t. hun privacy. Mogelijk zien ze ook voordelen in de advertenties die beter aansluiten bij hun interesses. Het is interesseprofiel is voor de betreffende persoon overigens in te zien een aan te passen.

Belangrijkere vraag vind ik op dit moment wat zijn de gevolgen voor de webmasters die op hun website inkomsten uit Adsense halen? Zullen de inkomsten stijgen? Google wijst webmasters er op, dat adverteerders bereid zijn meer te betalen voor bezoekers waarvan de interesses bekend zijn.

Ik denk dat er vooral voordeel te behalen is voor websites, die zich niet richten op een specifieke doelgroep. Bijvoorbeeld website die nieuwsberichten publiceren kunnen voordeel behalen van advertenties, die gericht zijn op de bezoeker i.p.v. de inhoud van de website.

De inkomsten van de advertenties via adsense worden door twee factoren bepaalt. In der eerste plaats de kans dat een bezoeker op een advertentie klikt en daarnaast natuurlijk het bedrag dat de adverteerder per klik betaalt. Website, die zich qua inhoud al richten op een specifieke doelgroep, zullen dus geen profijt hebben van de wijzigingen. Door het huidige
plaatsingstargetingbeleid sloten de advertenties al aan bij de doelgroep. Het betrekken van het surfgedrag bij het vertonen van advertenties kan op deze websites juist een averechts effect hebben. Bezoekers zijn op dat moment misschien juist op zoek naar specifieke informatie, die niet per definitie binnen hun interessegebied valt.

Webmasters van websites met een specifieke doelgroep zouden het tonen van advertenties op basis van interesses dus waarschijnlijk uit willen schakelen. Google biedt die mogelijkheid wel, maar webmasters kunnen er niet voor kiezen om het surfgedrag van de bezoeker uit te sluiten. Vanaf april zullen adsense-advertenties dus steeds meer gebaseerd worden op het surfgedrag en wordt adverteerders de mogelijkheid geboden daar op te sturen.

Voor een adverteerder wordt het dan dus mogelijk advertenties bijvoorbeeld alleen nog te tonen aan bezoekers die de doelwebsite al eerder bezochte of juist niet. Advertenties worden dan meer een herinnering en een mogelijkheid om bezoekers terug te halen. Gelukkig blijft de mogelijkheid om advertenties van concurrenten niet te tonen ook in het nieuwe beleid gehandhaafd.

Webmasters kunnen de toegestane advertenties beheren via het advertentiecontrolecentrum. Hier kunnen bepaalde doelgroepen worden uitgesloten, Google vraagt webmasters wel hiervoor een reden op te geven. Webmasters krijgen de keus om advertenties te controleren voordat deze op de website getoond worden. Het weren van bepaalde advertenties of websites heeft alleen nut als de instellingen per domeinnaam of website gemaakt kunnen worden. Op dit moment kunnen webmasters advertenties alleen per Adsense account instellen.

Zelf beheer ik veel websites waarvan de doelgroep of het onderwerp al vastligt, om die reden verwacht ik ook dat het klikratio voor Adsense mogelijk gaat dalen. Vraag is dan of de vergoeding per klik inderdaad zal gaan toenemen. Overigens denk ik zelf dat het bezoeken van een bepaalde website het meeste zegt over de interesses en behoeften van de bezoeker op dat moment. Deze interesse van het moment zal volgens mij vaak juist niet passen binnen het algemene interesseprofiel.

zie ook: Google gaat de technologie van Doubleclick echt inzetten

Wel of geen indexbestand?

Bij een website is de structuur te vergelijken met een directory- of mappenstructuur op een PC. Op een PC verwacht je bij het opvragen van een directory een lijst bestanden. Bij een website is het net iets anders. De meeste webservers tonen dan een bestand met de naam index.*. Dat kan bijvoorbeeld een .htm, .html of .php bestand zijn.
Op een apache webserver kun je de volgorde aangeven d.m.v. DirectoryIndex in de virtual host configuratie. Eventueel kan de instelling weer ‘overruled’ worden door het plaatsen van een .htaccess bestand in de betreffende directory.

Door deze constructie zullen voor een website /{subdirectory}/ en /{subdirectory}/index.htm verwijzen naar dezelfde content (bestand). Vanuit een zoekmachine gezien kan dit leiden tot ‘duplicate content’. Veel website tonen bij het opvragen van de domeinnaam een menu, waarop ‘home’ bijvoorbeeld verwijst naar /index.htm. Hoewel dit misschien een vreemd voorbeeld is bestaat het risico dat een zoekmachine beide URL’s gaat indexeren en deze vervolgens ziet als ‘duplicate content’.

Op een webserver kan dit worden opgelost door het opnemen van redirect. Dus als /index.* wordt opgevraagd krijgt de bezoeken een redirect naar / of v.v. Op apache is Mod Rewrite hiervoor zeer geschikt. Op Windows-machines is er tegenwoordig voor IIS 7.0+ ook een URL Rewrite Module beschikbaar.

Vraag is nu verwijst je op een website naar de /{subdirectory}/index.* of laat je het index bestand weg. Tot op heden heb ik altijd gedacht je hierin een vrije keuze had. Mij leek de enige voorwaarde consequent zijn. In de laatste versies van Opensourcecms.eu hanteerde ik de volgende strategie. Bij het opvragen van de domeinnaam wordt geen index bestand gebruikt, dus bijvoorbeeld http://www.bhmaat.nl/. Bij het opvragen van een ‘subdirectory’ moet altijd een index.htm gebruikt worden. Bijvoorbeeld: http://www.ingetrokkentepels.nl/nl/home/hoffman_exercises/index.htm. Uiteraard is dit een keuze waarover je kunt twisten. D.m.v. Mod Rewrite zorgde ik dat ‘verkeerde’ bestanden niet kon worden opgevraagd. Indien toch een aanvraag werd gedaan voor /index.htm(l) of /{subdirectory}/ gaf ik een redirect (response code 301) naar het juiste bestand.

De boven beschreven strategie werd niet alleen doorgevoerd in de virtual host configuratie. Opensourcecms.eu zorgde dat ook binnen een website de links klopte. In interne links, menu’s en broodkruimelpaden (breadcrumbs) verwees ‘home’ naar /. Overige links verwezen naar */index.htm. Ook werd dit doorgevoerd in zichtbare html-sitemaps, zoals http://www.lynxen.nl/nl/sitemap/index.htm en ook voor de xml-sitemaps. Een voorbeeld van het laatste is te vinden op: http://www.voedingsbeha.nl/sitemap.gz.

Ondanks dat de beschreven strategie mij correct leek heeft google moeite met het indexeren van de pagina’s die uitsluitend onder *index.htm worden getoond. Google biedt een aantal hulpprogramma’s voor webmasters, hier kun je o.a. jouw xml-sitemap uploaden en deze vervolgens laten analyseren.

Ook al staat in de sitemap aangegeven dat het opvragen van /{subdirectory}/index.htm gewenst is, vraagt de spider van google toch alleen /{subdirectory}/ op. Deze aanvraag wordt door verwezen via een 301 waarop google concludeert dat er sprake is van een doorverwijzing. Concreet leidt dit in de ‘Hulpprogramma’s voor webmasters’ tot een aantal waarschuwingen (gelukkig wordt nog gezien dat het geen fout is):

URL’s niet gevolgd
Tijdens het testen van een aantal URL’s uit uw sitemap hebben we vastgesteld dat bepaalde URL’s de gebruiker omleiden naar een andere locatie. We raden u aan URL’s in uw sitemap op te nemen die naar de uiteindelijke bestemming verwijzen (de bestemming van de omleiding) in plaats van om te leiden naar een andere URL.

Ondanks dat ik deze waarschuwingen niet terecht vind heb ik toch besloten voor de toekomstige versie van Opensourcecms.eu min strategie weer aan te passen. In hyperlinks zullen geen index.* meer voorkomen, index-bestanden kunnen uitsluitend nog opgevraagd worden via een */ request. Oudere versies van Opensourcecms.eu deden dat al. Dergelijke website zoals http://www.seksuelevoorlichting.be/ geven in de ‘Hulpprogramma’s voor webmasters’ van google geen waarschuwingen.

Sinds het begin van dit jaar is de volledige broncode van Opensourcecms.eu te downloaden op http://www.opensourcecms.eu/nl/download_en_installatie/index.htm. De zip-versie zal voorlopige nog de ‘oude’ strategie hanteren. Op de via cvs beschikbare code zullen de wijzigingen z.s.m. worden doorgevoerd. Weirdmaker.be zal de eerste website zijn, die van deze nieuwe aangepaste benadering gebruik zal maken.

Evaluatie Frog CMS

Op mijn eerder blog over Digitalus cms kwam een reactie om ook eens naar Frog CMS te kijken. Dat heb ik inmiddels gedaan. De installatie ging soepel en de performance van dit CMS bleek in eerste instantie uitstekend te zijn.

Installatie

Na het downloaden kan Frog CMS geïnstalleerd worden via de geleverde installer. In eerste instantie gaf die de volgende foutmeldingen:

Error: config.php must be writable
Error: public/ folder must be writable

Jammer, dat die controle niet werd uitgevoerd voor het invullen van de databasegegevens. Nu moest ik deze nog een keer invullen na het aanpassen van de rechten. Verder werkt het prima. Na de installatie had ik meteen een werkende website. Deze website (demo) is opgezet als een blog (Artikelen met archieven). Dit geeft in eerste instantie de indruk dat het CMS ook het beste gebruikt kan worden voor het schrijven van blogs. Als een blogartikelen aan een pagina koppelt heb je opeens een site. Zo groot is dat verschil dus niet. Bijvoorbeeld Expression engine en WordPress werken overigens ook op die manier.

Performance

Net als bij Digitalus cms heb ik voor Frog CMS ook naar de performance gekeken. Daarbij kijk ik dus naar het geheugengebruik en de rekentijd voor genereren van een pagina. Ik heb steeds dezelfde pagina gebruikt met dezelfde layout. De test is geen benchmark, maar wel een indicatie. Voor ik Digitalus cms testte had ik eerst een aanpassing gemaakt, zodat per pagina automatisch metatags werden aangemaakt. Dit heb ik ook eerst voor Frog CMS gedaan. Bij alle tests werd dezelfde php-class gebruikt voor het bepalen van de metatags (description en keywords). Voor Frog CMS heb ik de aanpassing in de layout gedaan. De resultaten waren verrassend:

Frog CMS:
<!– CPU usage user program: 0.048003 sec –>
<!– CPU usage OS for user program: 0.004 sec –>
<!– Total cpu usage: 0.052003 sec (user + OS)–>
<!– Memory usage totaal: 413,388 bytes –>
<!– Memory usage cms: 307,732 bytes –>
<!– PHP version: 5.2.8 –>
<!– Apache version: Apache/2.0.54 (Fedora) –>

Opensourcecms.eu:
<!– CPU usage user program: 0.092006 sec –>
<!– CPU usage OS for user program: 0.044003 sec –>
<!– Total cpu usage: 0.136009 sec (user + OS)–>
<!– Memory usage totaal: 1,708,364 bytes –>
<!– Memory usage cms: 1,468,084 bytes –>
<!– PHP version: 5.2.8 –>
<!– Apache version: Apache/2.0.54 (Fedora) –>

Frog CMS heeft dus een uitstekende performance. Het geheugengebruik is laag, minder dan een kwart van dat van Opensourcecms.eu. De rekentijd is slechts een tiende t.o.v. Opensourcecms.eu. Oeps, toch eens uitzoeken waar dat aan ligt.

Frog CMS heeft ook een cache module. De module slaat de complete pagina op en toont deze weer als er niets veranderd is. Uiteraard komt dat de performance ten goede, maar het is niet echt zinvol dit te vergelijken bovengenoemde tests. Gezien het een module is die niet tot de core van het systeem behoort is er wel het risico, dat het bekijken van de cache niet het eerste is wat het systeem doet. Op die manier zou er nog best wat rekentijd en geheugen verbruikt kunnen worden. Toch maar even de cijfers:

Frog CMS pagina uit de cache:
<!– CPU usage user program: 0.0080000000000027 sec –>
<!– CPU usage OS for user program: 0.004 sec –>
<!– Total cpu usage: 0.012000000000003 sec (user + OS)–>
<!– Memory usage totaal: 393,804 bytes –>
<!– Memory usage cms: 288,484 bytes –>
<!– PHP version: 5.2.8 –>
<!– Apache version: Apache/2.0.54 (Fedora) –>

De cache module levert dus wel een extra voordeel op.

In /frog/app/frontend/main.php wordt als eerste uitgevoerd:

// Intialize Setting and Plugin
Setting::init();
Plugin::init();

Daarmee is dus alleen niet gezegd, dat de cache plugin ook al eerste van de plugins wordt uitgevoerd. Ter vergelijking als ik de html van de pagina direct naar de browser echo:

<!– CPU usage user program: 0 sec –>
<!– CPU usage OS for user program: 0 sec –>
<!– Total cpu usage: 0 sec (user + OS)–>
<!– Memory usage totaal: 116,548 bytes –>
<!– Memory usage cms: 1,568 bytes –>
<!– PHP version: 5.2.8 –>
<!– Apache version: Apache/2.0.54 (Fedora) –>

Het installeren van deze plugin verliep overigens zeer eenvoudig.

Meertaligheid

De nieuwste versie van Frog CMS zou een betere ondersteuning hebben voor meertalige websites. Omdat ik nieuwsgierig was geworden door de goede performance, heb ik ook de laatste versie via SVN geïnstalleerd. Taal instellingen en vertaalmogelijkheden kon ik echter niet terug vinden. Op het form heb ik de volgende discussie hierover gevonden. De suggestie die gedaan wordt om de gehele websitestructuur te kopiëren en vervolgens te vertalen, lijkt mij geen optie. In de eerste plaats is het zeer bewerkelijk en bovendien heb je op die manier geen relatie meer tussen de vertalingen. Op een pagina kun je dus niet meer linken naar de vertaling van de betreffende pagina. De laatste post verwijst naar een WordPress Plugin met de naam qTranslate. Die aanpak lijkt mij veel beter. Voor Frog CMS zou dat beteken dat een dergelijke opzet niet alleen voor de pagina’s wordt gemaakt. Ook de artikelen gekoppeld aan een pagina zouden op deze manier opgezet moeten worden.

Pagina’s en artikelen

Na het installeren van Frog CMS vond ik het in eerste instantie verwarrend dat er een “Home” was waarop artikelen getoond werden van de pagina “Articles”. Waarschijnlijk is dit alleen als voorbeeld bedoeld. Aan “Home” kunnen net zoals aan “Articles” losse artikelen gekoppeld worden. Op die manier kun je dus prima een websitestructuur bouwen, met meerder artikelen per pagina. Het voorbeeld toont de artikelen op volgorde van toevoeging. Voor een website zou je dat dus niet willen. Het paginaoverzicht heeft ook de optie om te kunnen herschikken (drag and drop). Ik neem aan dat die volgorde ook gebruikt kan worden om de artikelen op de pagina’s te tonen.

Wat ik (nog) niet helemaal begreep. De “Articles” pagina is een pagina van het type archive. Toch bevat de inhoud van deze pagina een stuk php-code om de artikelen te tonen. Voor mij is niet duidelijk wat het nut van een pagina van het type archief dan is. Tenzij dit alleen bedoeld is om aan te geven dan het een archief is. Als dat inderdaad zo is, bemoeilijkt dit de inzet van Frog CMS voor het onderhoud van de site door niet php-programmeurs. Ik kan iemand vertellen, maak een pagina aan van het type archief. Als je dat gedaan hebt worden alle onderliggende pagina op die pagina als artikel getoond. Zou daar nog een stap bijkomen, voeg nu aan de content van die pagina het volgende stukje php-code toe, dan gaat dat net wat te ver. Ook voor wel php-programmeurs lijkt dat omslachtig.

Plugins / Modules

Om nog wat andere zaken te bekijken heb ik nog een extra module geïnstalleerd. Op deze pagina, is een flinke lijst met modules te vinden. Opvallend is dat veel modules gericht zijn op het systeem en onderhoud. De rest van de plugins voegen een eenvoudige functionaliteit toe. Complexere modules zoals een forum of een webshop zijn er niet.
Ik heb gekozen voor de “whois” plugin. De installatie was opnieuw eenvoudig:

1 – Unzip and upload this plugin to the Frog plugins directory.
2 – IF NECESSARY, edit the index.php file and change the variables.
All variables are well commented in the code.
3 – Access the Frog Administration screen and activate the plugin.
4 – Place the following code in your desired page: <? whois(); ?>

En zo werkte het ook. Ik kon dus een nieuwe pagina aanmaken en daarin de <? whois(); ?> code opnemen. Door deze manier van implementeren kan er dus nog steeds tekst boven of onder de module geplaatst worden. Ik had verwacht dat ik <? whois(); ?> code ook een een zgn. snippet (snipper) zou kunnen zetten. Dat kan ook, maar geeft in dit geval alleen content als de code in de content van een pagina wordt getoond. Plaats ik de snippet in de layout of in een artikel, dan wordt de inhoud niet getoond.
Verder neem ik aan dat er ook plugins zouden zijn die je aan een pagina koppelt. Op de manier van; deze pagina is van het type <plugin>. Eigenlijk net zoals bij de archive-plugin, die dus ook niet helemaal deed wat ik verwachtte.
Ondanks dat de <? whois(); ?> niet overal output geeft lijkt deze wel ‘globaal’ beschikbaar. Deze opzet zou er bij veel of grote plugins dus voor zorgen dat de performance hard achteruit holt.
Inderdaad is na het activeren van de plugin op alle pagina’s te zien dat de hoeveelheid gebruikt geheugen toeneemt:

<!– CPU usage user program: 0.032002 sec –>
<!– CPU usage OS for user program: 0.008 sec –>
<!– Total cpu usage: 0.040002 sec (user + OS)–>
<!– Memory usage totaal: 548,592 bytes –>
<!– Memory usage cms: 483,888 bytes –>
<!– PHP version: 5.2.8 –>
<!– Apache version: Apache/2.0.54 (Fedora) –>

Wanneer ik kijk naar de “Whois” plugin dan is deze niet geschreven volgens het MVC-patroon. Ook bij andere plugins zie ik dat niet terug.

Snippets / snipper

De website die met de installatie neergezet wordt heeft twee snippets. Via een snippet kan je klein stukjes content in een layout of pagina includen. De twee eerder genoemde snippets bevatten de header (inclusief) menu en de footer van de layout. Eigenlijk snap ik niet waarom deze opzet is gekozen, maar misschien is het alleen om te illustreren hoe een snippet werkt. De templates (layouts) bevatten veel php-code, eigenlijk past dat ook niet zo bij het MVC-patroon. Ook lijkt Frog CMS daarmee een systeem dat je alleen kunt beheren met php-kennis. Op het forum vond ik hier nog wat over terug, hier kun je lezen, dat je de php in snippets kunt plaatsen en zo de layout vrij van php kunt houden. Op de website van Frog CMS valt overigens te lezen dat het kunnen gebruiken van php in de layouts juist een uniek voordeel is. (waar heb ik dat eerder gehoord?)
Snippets lijken mij ook geschikt om de content van een plugin te tonen. Met de geteste “Whois”-plugin werkt dit dus niet.

Overigens kun je een pagina ook opdelen in verschillende stukken. Bij de standaard installatie heeft de pagina een body en een sidebar gedeelte. De sidebar kan dan in de layout worden opgenomen d.m.v. $this->content(‘sidebar’, true); Voor mij is niet helemaal duidelijk wat dan het verschil met een snippet is. Mogelijk biedt deze constructie de mogelijk om op elke pagina iets anders in de zijbalk te plaatsen.

Server farm

Zou Frog CMS in te richten zijn als server farm? De templates vormen geen probleem omdat deze in de database staan, op die manier kan elke website gewoon zijn eigen templates hebben. Qua plugins zie ik in eerste instantie geen eenvoudige oplossing. Feitelijk zou je twee plugin directories willen hebben, een in de centrale code en een per website. Verder is de opzet van de plugins belangrijk, dan met name de views. Views lijken er in eerste instantie dus niet te zijn. Zouden die er wel zijn dan zou het gewenst zijn, als per website aparte views per plugin gebruikt zouden kunnen worden. De de plugin staat centraal terwijl de views lokaal staan (of wanneer ze daar staan de centrale views overrulen).

Code

De code lijkt wel goed in elkaar te zitten. Alleen mis ik dus MVC bij de plugins. Documentatie heb ik ook niet kunnen vinden. Op de roadmap lees ik dat er aan PHPDoc documentatie wordt gewerkt. Voor PHPDoc zijn speciale comments in de code nodig en die zie ik inderdaad met grote regelmaat terugkomen.
Op de roadmap las ik ook “Removed split between frontend and backend”. Ik vraag mij af wat dit betekent. Mogelijk het idee om de content op de site zelf te kunnen aanpassen. Vanuit performace-perspectief is een splitsing tussen frontend en backend vaak de beste optie. Althans mijn idee is dat de performance van frontend belangrijker is, dus houd je die code vrij van beheerfuncties.

Conclusie

In eerste instantie was ik erg verrast door de goede performance. Later bleek dit mede te danken aan het minimaal aantal geïnstalleerde plugins. Een grote plugin kan de performance van de gehele site sterk verslechteren. Wanneer het
multi-language probleem aangepakt zou worden volgens de manier waarop ook de genoemde qTranslate plugin van WordPress is geïmplementeerd zou ik mij nog eens verder willen verdiepen in Frog CMS.

Ook op het internet geen koopzondag

Bij een vooral christelijk kabinet, kan je natuurlijk altijd vreemde dingen verwachten. Rook- en paddoverboden kun je altijd nog motiveren door de verwijzen naar de gezondheidsrisico’s. Het opkopen van banken is natuurlijk ook vreemd. Echt vervelend wordt het pas als het beleid wordt gebruikt om te evangeliseren. Het in ere herstellen van de christelijke rustdag op zondag. Geen of minder koopzondagen is het plan, dat het 20.000 banen kost, maakt dan niet eens meer zoveel uit. Wat ik mij vooral af vraag is, voor wie zijn dat soort maatregelen bedoelt? Zijn er echt mensen die zich storen aan het open zijn van de winkels op zondag? (Ik heb er nu i.i.g. één gevonden, zie verder). Zelfs voor die paar mensen die op zondag nog naar de kerk gaan, lijkt mij het handig als daarna nog even kunnen shoppen, als ze toch langs de winkel komen. Buiten dat alles lijkt het mij gewoon handig om de winkels open te doen, wanneer zoveel mogelijk mensen tijd (en zin) hebben om wat te gaan kopen. Beste logisch dat dit op zondag is want dan hebben veel niet-winkeliers een vrije dag. Een ander probleem is dat van al die bemoeizucht mensen ‘gekke dingen‘ gaan doen….

Toch aardig dat ik het bovenstaande allemaal heb opgeschreven, want hoe meer winkels er dicht zijn, hoe meer mensen op internet zullen kopen. En dat zou dan uiteindelijk weer goed voor mij moeten zijn….. via verschillende website doe ik mee aan zgn. affiliate (affiliatie) programma’s. Wanneer ik (affiliate) iemand via een hyperlink doorstuur naar een webshop (adverteerder) en die persoon koopt daar dan ook iets, dan ontvang ik over die aankoop een provisie. Dat werkt bijvoorbeeld als volgt; onderaan het artikel “De nieuwe 17-inch MacBook Pro” staat een link ““Koop een 17-inch MacBook Pro“. Wanneer iemand na het lezen van het artikel nu een Macbook via de genoemde link koopt, dan verdiend de auteur van dat artikel daar dus aan.
Een andere adverteerder waar ik affliate ben is babypark.nl en daarom kwam ik vandaag op die website (ik werk wel op zondag dus). Tot mijn grote verbazing las ik daar het volgende:
—
Onze site is op zondag gesloten.
Graag zien wij u op andere dagen van de week terug.
Onze medewerkers zullen u dan volledig van dienst zijn.

Bedankt voor uw begrip en tot ziens.
—
Tja…. het mag natuurlijk. Als affiliate van deze webshop vind ik het een stuk minder leuk. Tot vandaag dacht ik altijd dat het plaatsen van een telefoonnummer, voor telefonisch bestellen op de site, de ‘grootste zonde’ was van adverteerders in de affiliatiebranche. Wanneer iemand telefonische bestelt, kan de verkoop niet meer aan de affliate worden toegekend. Althans het kan wel, maar het gebeurd vaak niet. Het sluiten van de website op een willekeurige (zon)dag is voor de affiliates ook niet echt gunstig.

Overigens verwijst de bovengenoemde link naar babypark.nl naar actiebaby.nl. Misschien wordt dat ook aangepast, ik moet nu echt tot maandag wachten omdat te kunnen controleren. De links die ik gebruik komen dus van affiliate4you.nl, dat is een bedrijf dat bemiddelt tussen affiliates en de adverteerders.

Veel affiliate programma’s werken d.m.v. cookies, de cookies van babypark.nl zijn bijvoorbeeld 100 dagen geldig. Dat betekent dus dat wanneer een bezoeker later terugkomt op webshop, waar hij in eerste instantie kwam via een affiliate-link, toch nog een commissie kan opleveren voor de affiliate.

De website van actiebaby.nl legt op zondag wel cookies vast. Kunnen dan ook niet gewoon de orders automatisch vastgelegd worden voor verwerking op maandag, vraag ik mij dan meteen af.

En wie echt niet kan wachten, via http://www.google.nl/search?q=site%3Ababypark.nl kun je de artikelen op de site terugvinden en bekijken. Dat kan zelfs op zondag, bestellen dus niet.

Misschien moet ze hier in Den Haag toch ook eens naar kijken. In andere landen bemoeit de overheid zich ook veelvuldig met toegang tot websites. Het beste lijkt mij om op zondag gewoon het hele internet te sluiten. Dan kunnen mensen lekker naar de stad om de etalages van de gesloten winkels te bekijken.

Reverse Ajax

Voor een project wil ik het volgende testen: door het oproepen van een URL met parameter, bijvoorbeeld http://www.w3masters.nl/opslaan/?woord=test, wordt de parameter opgeslagen in de database. Na het opslaan in de database wordt in een webapplicatie een pop-up geopend, die de opgeslagen parameter toont.

Dit betekent dus dat de webserver de data naar de webapplicatie (browser) moet pushen. Deze techniek heeft de naam Comet gekregen. (zie ook: http://ajaxpatterns.org/HTTP_Streaming) Het is daarbij niet wenselijk dat er steeds een mysql-query gedaan moet worden om te controleren over er nieuwe data is.

Om dit te bereiken is een extra Comet server nodig. De clients maken een connectie naar deze server en tonen een pop-ups als er nieuwe data beschikbaar is. Bij het samenstellen van de pop-up kan extra data uit de database worden opgehaald. Het script (php) dat wordt aangeroepen bij de eerder genoemde URL, schrijft de parameter naar de database en geeft het ID van de parameter door aan de Comet server. De clients ontvangen het ID en kunnen dus vervolgens de pop-up tonen.

Voor het opzetten van een comet server lijkt Jetty zeer geschikt. Jetty is opensource webserver geschreven in Java. Jetty bevat tevens een servlet implementatie van het Bayuex protocol van cometd. Cometd is een implementatie comet van de Dojo Foundation. Bij Jetty zittten tevens een aantal cometd demo’s, zie http://docs.codehaus.org/display/JETTY/Cometd+(aka+Bayeux). Net als de meeste andere comet voorbeelden, zit hier ook een chat applicatie bij. Met enige aanpassing zou deze applicatie de gezochte functionaliteiten kunnen leveren. Een eenvoudige “hello world” is hier te vinden.
Het Bayuex protocol voorziet niet in autorisatie en/of authentificatie. Autorisatie zou dus via de webserver zelf geregeld moeten worden. Jetty kan dit o.a. met JAAS, zie http://docs.codehaus.org/display/JETTY/JAAS.

Een alternatieve Comet server zou Comep kunnen zijn. Comep is een comet server geschreven in PHP. Comep levert ook enkele voorbeelden mee. Deze voorbeelden leken in eerste instantie niet te werken. Ook Meteor zou geschikt zijn, Meteor is geschreven in Perl. Meteor moet onder poort 80 draaien, wat een nadeel kan zijn als je deze dus wilt gebruiken op een server waar ook bijvoorbeeld Apache draait. De reden die hiervoor gegeven werd was dat Meteor anders vatbaar was voor cross-site scripting. Ik vraag mij af waarom dat op port 80 dan niet zo is? En als dat inderdaad niet zo is hoe dat dan zit met de andere hier besproken servers? Het artikel “Real Time Angst” geeft een zeer mooi voorbeeld van de kracht en mogelijkheden van Comet. Dit voorbeeld is ook op Meteor gebouwd. Hoewel ik dus niet opzoek was naar live data streaming is wel me wel duidelijk geworden dat Meteor een goed opensource alternatief is voor bijvoorbeeld het commerciële Lightstreamer.

Overigens lijkt een server zoals Jetty voor een eerste prototype van mijn project toch nog wat te complex. Het artikel
“How to implement COMET with PHP” komt met twee eenvoudigere voorbeelden. De comet server is hier feitelijk een php-script in een ‘oneindige’ loop. Ook wordt geen gebruik gemaakt van het Bayuex protocol. Toch heeft het tweede voorbeeld wel ongeveer de functionaliteit die ik nodig heb. Je kunt regel tekst aan een .txt bestand toevoegen (in mijn geval dus het ID). Op de client wordt deze regel getoond, de laatst toegevoegde regel en alle regels die nieuw worden toegevoegd.

Evaluatie Digitalus cms 1.5 beta

Af en toe denk ik er over na om opensourcecms te herschrijven naar het Zend Framework. Er zijn natuurlijk veel php frameworks, toch lijkt Zend daarvan op dit moment de enige te zijn, die een standaard kan worden. Onlangs stuitte ik op Digitalus cms, dat reeds ontwikkeld is op het Zend Framework, het leek mij daarom interessant om eens te bekijken hoe de nieuwe 1.5 beta werkt en in elkaar zit.
Beta bleek al snel een groot wordt. Wat je krijg is de basis, met een installer die redelijk werkt. Pas na het lezen op het forum kwam ik er achter, dat de cache directory chmod 0777 moest hebben. Er wordt in deze beta slechts één module meegeleverd, de contact form module, die overigens niet werkt.
De reden om niet de stable versie maar de beta te testen is dat de stable versie in de eerste plaats niet gebouwd is met het Zend Framework. Ook beschikt de stable versie niet over de mogelijkheid een meertalige website te bouwen. Dit laatste is één van mijn minimale eisen.

MVC

Het cms maakt gebruik van het Model-View-Controller ontwerp patroon dat in Zend Framework geïmplementeerd is. Dit maakt de opzet van het systeem en de code overzichtelijk. In eerste instantie komt het vreemd over dat de views php-code bevatten. Dit is geen manco van Digitalus cms. Dit komt voort uit het Zend Framework. De ontwikkelaars van het Framework zeggen hierover: “PHP is itself a powerful template system”.

Artikelen en pagina’s

Wanneer je binnen het cms een pagina aanmaakt kan daar vervolgens met een html-editor, in dit geval WYSIWYG jQuery Plugin, content aan worden toegevoegd. Dat werkt prima. Zelf zou ik er de voorkeur aan geven om meerder artikelen per pagina te kunnen koppelen. Voordeel daarvan is dat je aan elk artikel apart extra functionaliteiten kunt koppelen. Op termijn zou dit opgelost kunnen worden via een aparte module.
Pagina’s kunnen slechts één module bevatten. Grootste nadeel daarvan is dat je geen content meer boven of onder de module kunt toevoegen. Dit probleem wordt opgelost door onder en boven de module een mogelijkheid te bieden, extra tekst in te voeren.

Automatische metatags

Bij Digitalus cms kan per pagina worden ingesteld wat de metatags (keywords en description) zijn, ook kan de titel van de pagina worden aangepast. Bij het beheren van meerdere website, met veel content wordt dit al snel te arbeidsintensief. Mijn voorkeur zou dan ook zijn dit net als bij Opensourcecms.eu te automatiseren.
De opzet van ./library/DSF/Builder/Action/Page.php maakt dit met een kleine aanpassing, mogelijk in de functie loadContent een aanroep te doen naar $this->setMeta en zo de metatags te maken op basis van de content die via de variabele content->content[‘content’]; beschikbaar is in deze functie.

Meertalige websites

Digitalus cms biedt de mogelijkheid om per artikel een vertaling aan te maken. Op de webpagina’s is dit zichtbaar te maken d.m.v. hyperlinks, die aangeven dat er ook een vertaling aanwezig is. Zelf zie ik de vertaling liever op een hoger (pagina) niveau, zodat niet alleen het artikel vertaald wordt maar ook de url, metatags (indien niet voor automatische metatags gekozen wordt, zie vorige paragraaf) en de menu’s op de betreffende pagina. Deze laatste optie, kan wel tot complexe situaties leiden, indien maar een gedeelte van de website vertaald is. Onmogelijk is het niet, zie bijvoorbeeld http://www.ellenpari.nl/

Modules

Ook de modules zijn opgezet volgen het MVC-partoon. Uitbreiding van het systeem, wordt daarmee eenvoudig en inzichtelijk. Wel vraag ik mij af hoe modules met meer complexere instellingen in de admin interface verwerkt moeten gaan worden. Binnen de interface lijkt wel ruimte te zijn gemaakt om een module in te stellen, maar niet om deze ook werkelijk te beheren, bijvoorbeeld in het geval van een webshop of forum.

Server farm

Installatie in een zgn. Server farm vind ik wenselijk. Hiermee bedoel ik dus dat er meerdere website opzelfde cms-code kunnen draaien. Mede door de MVC-implementatie zou dit mogelijk moeten zijn. In de huidige directory-structuur is hiervoor echter nog geen duidelijk onderscheid gemaakt. Het publieke deel (de feitelijk site) zou uitsluitend moeten bestaan uit templates, css, images en eventueel bijvoorbeeld een .htaccess bestand en een cache-directory.

Geheugengebruik en performance

Rekentijd en geheugengebruik krijgen bij cms-implementaties vaak weinig aandacht. Op zich is dat vreemd want in de eerste plaats bepalen deze factoren de laadtijd van de pagina. Daarnaast bepalen rekentijd en geheugengebruik het aantal gelijktijdige gebruikers dat een website of webserver kan afhandelen.

Ik heb een vergelijking gemaakt tussen Digitalus cms en Opensourcecms.eu, door een pagina te laden, met een artikel, menu, en ‘broodkruimel’-pad.

Digitalus cms:
<!– CPU usage user program: 0.248015 sec –>
<!– CPU usage OS for user program: 0.052003 sec –>
<!– Total cpu usage: 0.300018 sec (user + OS)–>
<!– Memory usage totaal: 5,184,296 bytes –>
<!– Memory usage cms: 5,127,524 bytes –>
<!– PHP version: 5.2.8 –>
<!– Apache version: Apache/2.0.54 (Fedora) –>

Opensourcecms.eu:
<!– CPU usage user program: 0.092006 sec –>
<!– CPU usage OS for user program: 0.044003 sec –>
<!– Total cpu usage: 0.136009 sec (user + OS)–>
<!– Memory usage totaal: 1,708,364 bytes –>
<!– Memory usage cms: 1,468,084 bytes –>
<!– PHP version: 5.2.8 –>
<!– Apache version: Apache/2.0.54 (Fedora) –>
<!– Database version: –>

Naast de langere rekentijd van Digitalus cms is te zien dat het geheugengebruik bijna 3x zo groot is. Mogelijke oorzaken hiervan zijn:

  • De overhead van Zend Framework
  • In de code kom ik veel nieuwe class/object initalisaties tegen, waar een Singleton misschien efficiënter zou kunnen zijn
  • Het cms lijkt voor elke pagina alle beschikbare ‘helpers’ e.d. in te laden terwijl ze niet allemaal nodig zijn
  • Hoewel het menu en ‘broodkruimel’-pad op een pagina vaak weinig veranderd, moet het elke keer opnieuw berekend worden, wat vaak gepaard gaat met rekenintensieve recursies.

Hoewel het niet openstellen van de cache-directory fouten gaf bij het installeren, lijkt de cache nu nog niet gebruikt te worden. Dit zou de performance kunnen verbeteren, als is er natuurlijk altijd iemand die de eerste pagina of zijn eerste pagina moet opvragen.

Opensourcecms.eu legt bij wijzigen in de pagina/websitestructuur een cache-bestand aan. Vanuit de in dit cache-bestand opgeslagen paginastructuur, kunnen menu’s, sitemaps en ‘broodkruimel’-paden worden samengesteld, zonder steeds opnieuw dezelfde queries naar de database te hoeven doen.

Code

De code van deze 1.5 beta versie is overzichtelijk en leesbaar. Mede door de inzet van Zend Framework ook consequent van opbouw. Documentatie van de code ontbreekt helaas nog volledig. Ook lijkt er bij de ontwikkeling dus nog weinig aandacht voor performance te zijn.

Conclusie

Digitalus cms laat zien dat er met Zend Framework een goed opgezet cms gebouwd kan worden. De keuze om een splitsing te maken in een public en admin deel, met elk zijn eigen views en controllers vind ik verhelderend. Het meenemen van meertaligheid vind ik goed, al is deze in mijn ogen dus nog niet ver genoeg doorgevoerd. Performance vraagt volgens mij nog wel aandacht. Zonder verdere verbeteringen zullen de vertalingen en menu-opzet op dit moment nog leiden tot het publiceren van ‘duplicate content’, wat dus ook nog aandacht vraagt.
Websites bouwen op een beta versie is natuurlijk sowieso geen aanrader. Zelf ga ik Digitalus cms i.i.g de komende maanden in de gaten houden.
De community lijkt overigens niet heel erg groot en/of actief te zijn. Daarnaast hoop ik dat de ontwikkelaars niet vergeten om eerste een stabiele basis te bouwen, voordat alle nieuwe en mooie functionaliteiten worden uitgewerkt.

PHP programming (tools)

Voor Opensourcecms.eu was ik op zoeken naar een meer professionelere aanpak en ontwikkelomgeving.

Ontwikkelomgeving

De eerste stap was de ontwikkelomgeving. Jarenlang heb ik gebruik gemaakt van de Zend IDE (Zend Studio). Dat leek ooit een goede keus, gezien dat bijvoorbeeld de mogelijkheid bood om Zend Encoder en Zend Guard te gebruiken. Twee tools om o.a. je code te kunnen beschermen en daar eventueel een licentie key aan te kunnen koppelen. Zend Encoder heb ik in het verleden wel eens gebruikt, maar de laatste jaren niet meer.

Na een tip die ik kreeg bij webdesiging.nl uit Nijmegen ben ik enkele maanden geleden overgestapt op Eclipse. Overigens wordt Zend Studio tegenwoordig ook aangeboden als plugin voor Eclipse. Ik heb gebruik gemaakt van het PDT Project (PHP Development Tools). Hiermee kon ik direct aan de slag. Tot op heden heb ik geen extra-plugins gedownload en bevalt het prima.

Versiebeheer

Tot op heden had ik uitsluitend een lokaal CVS Repository in gebruik. De maakte het voor andere lastig mee te ontwikkelen aan Opensourcecms.eu of zelfs om het te gebruiken. Ik heb er over gedacht om SVN te gaan gebruiken, maar tot op heden voldeed CVS ook prima. In plaats van zelf CVS te installeren heb ik gekozen om een account aan te maken op Sourceforge.net en daar gebruik te maken van de CVS. Het project is te vinden op: http://sourceforge.net/projects/opensourcecmseu/

Test-driven development

Test-driven development heeft zich de afgelopen jaren wel bewezen. Daar zou ik dus eigenlijk ook wel mee aan de slag willen. PHPunit is de tool die ik daarbij kan gebruiken. De documentatie geeft ook wat voorbeelden, die mij een beter idee geven voor het schrijven van tests. Test voor alle bestaande code schrijven leek mij niet te doen, maar ik heb mij wel voorgenomen, voor elke nieuwe bug en zoveel mogelijk voor nieuwe code wel tests te gaan schrijven.

Documentatie

De code wordt pas echt herbruikbaar en vooral overdraagbaar als deze voorzien is van goede documentatie. Phpdoc biedt de mogelijkheid deze documentatie automatisch te genereren. De documentatie wordt gemaakt uit de comments, die in de code staan. Het is even wennen en soms zoeken welke comments er moeten worden toegevoegd. Ik verwacht dat het wel snel routine zal worden.

Coding standaards

Het hanteren van de standaard voor coderen, houdt de code leesbaar en begrijpelijk voor andere programmeurs. Bij de ontwikkeling van Opensourcecms maak ik gebruikt van het Zend Framework. Daarom heb ik er voorgekozen om de Zend Framework Coding Standard for PHP te gaan gebruiken.
Checkstyle kan helpen de standaard te bewaken en overzichtelijk maken waar er van afgeweken is.
Verder is er voor Eclipse een speciale plugin voor Checkstyle. De komende weken moet ik nog testen of deze ook echt werkt en toepasbaar is op de Zend Framework Coding Standard.

Phpundercontrol

Phpundercontrol is een addon tool voor CruiseControl. Deze tools brengen veel van het bovengenoemde samen. het eindresultaat is een grafische interface, waar de documentatie te vinden is, die is samengesteld met Phpdoc. Verder wordt inzichtelijk gemaakt of de code de tests doorstaan (PHPunit) en hoeveel procent van de code gedekt is met een test (code coverage). Tot slot zijn ook de resultaten van Checkstyle terug te vinden. Gezien veel van mijn code nu nog niet voldoet aan de coding standards, geeft deze laatste tool enige problemen. Er kan in PHP nu niet voldoende geheugen gealloceerd worden om de Checkstyle over alle code uit te voeren.
Phpundercontrol gebruikt de laatste versie van de code uit het CVS Repository op Sourceforge.net.

OpenID wat kun je ermee

OpenID al veel van gehoord nog nooit wat mee gedaan. Onlangs zag ik dat ik op sourceforge.net ook kon inloggen met een OpenID. Voor wie niet weet wat OpenID is: OpenID is een gedecentraliseerd authenticatiemechanisme om Single Sign-on op het Internet mogelijk te maken. En dat klinkt dan weer als een leuke extra functionaliteit voor Opensourcecms.eu. Bovendien las ik dat Sourceforge.net de implementatie met het Zend Framework had gedaan, wat het nog eens extra interessant maakte.

Eerst maar eens een OpenID identiteit aanmaken, dat had ik kunnen doen door een keuze te maken op Openid.net, eigenlijk bleek ik al een aantal OpenID identiteiten te hebben o.a. via Yahoo. Altijd handig meerdere identiteiten 🙂 Er blijken echter ook twee Nederlandse OpenID-providers te zijn. Logmij.in en Mijnopenid.nl, chauvinistisch als ik ben kies ik daar natuurlijk voor. Logmij.in leek mij eigenlijk het meest interessant, omdat zij een met SSL beveiligde verbinding aanbieden. De .in in de domeinnaam gaf mij echter het gevoel mijn nieuwe identiteit direct aan India te verkopen. Dus gekozen voor Mijnopenid.nl. Registratie was eenvoudig, daarna mijn OpeniD nog bevestigen via een link per e-mail (wel een beetje ouderwets).
De URL van mijn OpenID identiteit luidt nu: http://mijnopenid.nl/is/allop.

Vervolgens terug naar Sourceforge.net, daar de URL opgegeven. Ik
wordt nu doorverwezen naar: http://mijnopenid.nl/

Daar krijg ik de vraag: “Wil je inloggen op https://sourceforge.net?” Altijd /
Eenmalig / Nee

Daarna (altijd gekozen) krijg ik nog de volgende vraag:
De pagina https://sourceforge.net vroeg om extra informatie.

De pagina vroeg de volgende gegevens:
Nickname (allop) (optioneel)
Email (bas@emailcommunications.nl) (optioneel)
Fullname (optioneel) [Wijzig]
Country (optioneel) [Wijzig]
Language (nl) (optioneel)
Timezone (Europe/Paris) (optioneel)

Feitelijk zou Sourceforge.net de koppeling hier al kunnen leggen op basis van mijn e-mailadres, maar dat doen ze dus niet.

Na verzenden kom ik terug op sourceforge.net, waar ik de volgende vraag krijg:

OpenID verified! Please associate your identity
Check our site doc for more information on OpenID.
Existing SourceForge Account
Log in

Username:

Password:

Nadat ik dat gedaan heb, kan ik dus ook inloggen met mijn openidurl.

Op mijnopenid.nl zie ik nu ook staan:

Jouw_sites

* https://sourceforge.net
Trek machtiging in

Kortom het werkt. Was wel veel werk…… en dat alleen om mijn wachtwoord niet te vergeten. Gezien ik altijd “bas” als wachtwoord neem vergeet ik dat ook niet zo snel…….

zie ook: Met OpenID geen wachtwoorden meer vergeten