De datafeeds veranderen nogal eens van structuur, of verdwijnen soms helemaal al dan niet tijdelijk.
De feedcron rapporteerd problemen. Hieronder een korte uitleg van de meldingen.
De feeds die een warning of error veroorzaakt hebben zijn terug te vinden in het feed overzicht door te filteren op 'attention', teven zijn deze feeds gemerkt door een driehoekje i.p.v. het groene published icoon.
Sommige elementen in feeds bevatten leestekens, sommige van de leestekens kunnen ergens in de keten van MySQL/php/joomla/html problemen veroorzaken.
Het gaat om : '/-:&"?_+
De ' en " zijn lastig met MySQL, de /,?,+ en & kunnen problemen veroorzaken in de URL. De - en : worden door joomla op een bijzondere manier behandelt in verband met het SEF systeem.
Daarom worden deze tekens vervangen door een spatie ( ` in geval van ') voordat elementen ( selecties/menu items) aan de MySQL database worden toegevoegd.
In de callback functie zijn de leestekens nog niet aangepast. Als je op de site bijvoorbeeld 'Nieuw Zeeland' hebt staan kan dat zijn oorsprong hebben in 'Nieuw-Zeeland' of 'Nieuw Zeeland'.
Het is toegestaan umlauten en soortgelijke karakters in de URI op te nemen, soms wordt de URI dan vertaald naar een encoded string. In het oorspronkelijke systeem werden de karakters vervangen door hun altenatieve schrijfwijze &ueml; -> ue. Dit is echter een nogal dure bewerking en daarom is ervoor gekozen dit niet meer te doen..
Vaak is het nodig de informatie in de feeds wat aan te passen, ISO-codes naar land informatie. Beschrijving inkorten of bijvoorbeeld een foutieve codering repareren. Voor deze aanpassingen is het mogelijk voor elke feed een callback functie te maken.
De gewone pharos feed ( tradetracker ) kent een tweetal problemen, ten eerste staat in sommige landennamen de aanduiding 'winter'. Daarnaast staan in de feed zowel gewonen reizen, stedentrips en wintersport reizen door elkaar. Onderstaand een voorbeeld van een callback functie om deze te repareren.
Het verwerken van de feeds is een vrij zware operatie. Door de feedcron veelvuldig aan te roepen zou een kwaadwillende een DOS aanval kunnen uitvoeren.
Over het algemeen voer je de feedcron uit vanuit een vast locatie. Je kunt de map ../administrator/components/com_datafeeds/cron dan eenvoudig beveiligen met een .htaccess bestand ( apache )
Order deny,allow
deny from all
allow from <toegestaan ip nummer>
allow from <ander toegestaan ip nummer>
Uiteraard zou je hier ook met wachtwoorden aan te gang kunnen.
En andere methode is om de map 'cron' en/of het script feedcron.php andere namen te geven. Alleen werkt dan de link vanuit het administrator panel niet meer.
Elke klik op 'Apply/Uitvoeren' haalt wel de feed opnieuw op en gebruikt ook de laatste versie van de feeds.php. Je ziet rechts dus de laatste stand van zaken, maar tijdens deze aktie wordt de database niet bijgewerkt.
Nadat een feed configuratie is aangepast (of een feed is toegevoegd) zul je dus de cron moeten uitvoeren.
bram
Werking
Dit php script zorgt voor het verversen van de gegevens in de database. Hiervoor moet het script periodiek draaien. Bijvoorbeeld dagelijks.
als je hosting provider toestaat dat je rechtstreeks via de commandline of via de admin-panel een cronjob aanmaakt en je gebruik kunt maken van de commandline versie (CLI-PHP) van php dan is rechtstreeks ( dus buiten de webserver) aanroepen van de feedcron de best oplossing
0 4 * * * (cd [pad van de feedcron];php feedcron.php)
Als je host geen php CLI heeft kun je het update script via de webserver aanroepen, wel moet er dan iets als wget, curl lynx zijn.
0 4 * * * w g e t https://www.example.com/administrator/components/com_datafeeds/cron/feedcron.php
Hier zit echter een klein addertje onder het gras. Het verwerken en met name de aktie daarvoor, het ophalen van de feeds, kost vrij veel tijd. Nu is het vrijwel altijd zo dat de maximale tijd dat een php script bezig mag zijn gelimiteerd is (max_execution_time), bijvoorbeeld op 30 seconden.
Bij een paar feeds is dit geen probleem. Maar bij vell of grote feeds loop je tegen deze beperking aan. Oplossing is dan de feedcron meerdere keren aan te roepen:
0 0-6 * * * w g e t https://www.example.com/administrator/components/com_datafeeds/cron/feedcron.php
(bovenstaande is van 0 tot 6 uur elk uur)
Of voor elke feed 1 keer
Als je host wel cron toestaat er echter geen CLI-PHP is maar wel perl dan kun je het perl script dat onderaan de pagina staat gebruiken, dat roept de feeds automatisch 1 voor 1 aan.
Geen eigen cron? Diensten als www.onlinecronjobs.com bieden een online cronservice aan ( let hier op de faq)
Veel feeds pretenderen een update frequentie van een dag, in de praktijk zijn er maar weinig feeds die inderdaad zo vaak veranderen. Feeds met veel items in de sfeer van aanbiedingen of last minutes kunnen inderdaad het beste alle 4 uur ververst worden. Voor andere feeds is eens in de week of nog minder voldoende. De standaard waarde die in de feed configuratie ingevuld wordt is 3 dagen.
https://www.example.com/administrator/components/com_datafeeds/cron/feedcron.php?feed=&freq=1
https://www.example.com/administrator/components/com_datafeeds/cron/feedcron.php?freq=1800
Eventueel meerdere keren aanroepen. Tot de laatste regel het items in de database bevat
In principe kan de parser ook (absurd) grote feeds aan. Je kunt echter tegen het time-out probleem aanlopen. Als de configuratie van je server het toelaat kun je proberen de maximale executie tijd te verhogen door de max_execution_time aan te passen in de feeds.php:
ini_set('max_execution_time',120);
Dit werkt in ieder geval niet als je server in safe mode draait
Zie max_execution_time en set_time_limit
Bij extreme gevallen zoals de feed van otto werkt alleen de commandline.
Dit script vraagt aan de betreffende feedcron welke feeds een update nodig hebben en roept ze dan een voor een op. Vergelijkbaar als de cron vanuit de joomla administrator maar dan zonder joomla