Goedendag,
Ik gebruik het onderstaande script al een hele tijd om bestanden naar mijn server te downloaden:

<?php

$ch = curl_init();
$source = "http://www.url.nl/xml/products.xml?k=3754-07a30d17713389029ec174ec7175eb5b30c40d64&toys=1&toys2=1&x=1&x2=1&language=nl&stock=all&catlist=1&size=stock";;
curl_setopt($ch, CURLOPT_URL, $source);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
$data = curl_exec ($ch);
curl_close ($ch);

$destination = "/home/map/domains/domain.com/public_html/pub/media/importexport/leverancier-voorraad.xml";
$file = fopen($destination, "w+");
fputs($file, $data);
fclose($file);

?>


Het bestand leverancier-voorraad.xml werd altijd keurig aangemaakt en kan van daaraf met andere cron verwerkt worden.
Nu merkte ik echter dat de voorraad niet goed bijgewerkt werd de afgelopen tijd. dat ik ging kijken bleek dat de laatste versie van leverancier-voorraad.xml 2 weken oud was.
Dus even de rapportage van cron aangezet en krijg ineens de volgende rapportage bij uitvoeren van bovenstaande script:

--2018-06-21 06:29:01-- http://www.domain.com/pub/media/importexport/leverancier-voorraad.php
Resolving www.domain.com... ip Connecting to www.domain.com|ip|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 537 [application/x-httpd-lsphp]
Saving to: “/dev/null”

0K 100% 67.4M=0s

2018-06-21 06:29:01 (67.4 MB/s) - “/dev/null” saved [537/537]



Cronjob wordt dus goed uitgevoerd, bestand wordt gedownload maar hij slaat het ineens op naar Saving to: “/dev/null”
Volgens mij staat er toch echt een andere opslag locatie in het bestand opgegeven.

Iemand voor deze leek enig idee waarom hij ineens niet meer naar opgegeven locatie opslaat maar naar “/dev/null”

[size=xsmall]Toevoeging op 21/06/2018 07:28:49:[/size]

Ik heb hetzelfde script nog even op andere domeinnaam getest en dan wordt bestand gewoon opgeslagen op de daar opgegeven locatie.
Locatie waar opgeslagen moet worden bestaat ook gewoon (staat ook nog het oude eerder via script gedownloade bestand). en rechten van de map waarbinnen opgeslagen moet worden staat op 0755

Dat gebeurd ook zo omdat voor bepaalde leveranciers er in dat php script ook een stukje code staat die gebruikt wordt om bij die leverancier in te loggen (die productfeeds staan achter een wachtwoord).

Dat kun je toch ook via wget regelen?


wget -q --http-user=USER --http-password=PASSWORD -O /home/map/domains/domeinnaam-voor-opslaan.com/public_html/pub/media/importexport/files/merk-voorraad.xml "http://www.website-voor-downloaden.nl/xml/products.xml?k=3754-07a30d17713389029ec174ec7175eb5b30c40d64&toys=1&toys2=1&x=1&x2=1&language=nl&stock=all&catlist=1&size=stock"

en dan heb je dat hele php-script niet eens nodig. ;-)
oke.....
dat klinkt stuk makkelijker.
Ik doe al jaar of 5 dat met die scripts en werkte altijd prima tot dus een week of 2 terug op deze domeinnaam. en op andere domeinnaam werkt het dus nog steeds.

maar ga het eens testen zo rechtstreeks

[size=xsmall]Toevoeging op 21/06/2018 12:58:37:[/size]

Het werkt zo te zien :-)
Bestand is gedownload en op de juiste locatie opgeslagen.
Alleen krijg ik nu geen e-mail meer van cron systeem met of goedgegaan is of niet.
Komt dat door die -q toevallig?
Ik heb het stukje --http-user=USER --http-password=PASSWORD er nu tussenuit gehaald omdat voor deze site dat niet nodig is.
Die -q zorgt er inderdaad voor dat je geen output krijgt als het goed is gegaan (als het fout gaat, krijg je wel een melding). Als je dat fijner vindt, kun je de -q ook gewoon weglaten. Ik ben zelf van huis uit gewend aan 'silent success'. Gelukkig maar, anders zou ik tienduizenden cron-mailtjes per dag krijgen. :-)

Waarom het ineens op het ene domein mis is gegaan: geen idee. Kan aan een heleboel (ook ogenschijnlijk ongerelateerde) dingen liggen. Het is moeilijk om daar op afstand iets over te zeggen.
Oke bedankt.
Lijkt iets overigens toch nog niet helemaal goed te gaan.
Bestand is gedownload en opgeslagen.
Volgende stap is dat dat gedownloade bestand geimporteerd wordt (ook dat start weer via cronjob normaal).
Nu even handmatig gestart via ssh maar hij gaat niet lopen.
Komt niet verder dan:

Entity catalog_product
Begin data validation
Checked column 0
Checked column 1
Finish checking columns
Errors count: 0
Start saving bunches

en dan hoort dus de hele lijst met regels uit gedownload bestand te volgen.
Dus nu zoeken waarom dat nu niet goed gaat.
Mogelijk vanwege een pad die niet absoluut is?
ik heb in import template enkel locatie aangepast van
/pub/media/importexport/merk-voorraad.xml
naar
/pub/media/importexport/files/merk-voorraad.xml

[size=xsmall]Toevoeging op 21/06/2018 13:35:26:[/size]

locatie nu ook weer teruggezet maar blijft dus hangen. controleert de 2 kolommen in het bestand zen zegt dat goed is. daarna moet hij de regels gaan verwerken maar daar start hij niet mee.
Bestand is ook als UTF-8 opgeslagen dus dat is ook goed.

[size=xsmall]Toevoeging op 21/06/2018 14:37:40:[/size]

Blijkt dat hij het wel doet maar nu ineens heel lang nodig heeft om te starten. normaal starte het binnen 1 seconde met verwerken, nu duurt 5 tot 15 minuten. dat nu bij ontwikkelaar van import extensie neergelegd
Wellicht ben je inmiddels van deze constructie afgestapt, maar scripts die op gezette tijden uitgevoerd dienen te worden (via cron) zouden bij voorkeur eigenlijk nooit in de publieke webdirectory mogen staan.
Thomas van den Heuvel op 21/06/2018 19:19:33

Wellicht ben je inmiddels van deze constructie afgestapt, maar scripts die op gezette tijden uitgevoerd dienen te worden (via cron) zouden bij voorkeur eigenlijk nooit in de publieke webdirectory mogen staan.


heb nu nog maar paar crons overgezet naar de nieuwe manier van verwerken zonder php file. rest moet nog.
Heb bestanden in die mappen gezet omdat dat is van waaruit de import systemen ze weer verwerken.
Kan waarschijnlijk beter, maar zijn nog paar honderd zaken die in mijn webshop beter kunnen. Maar nu eerst draaiende krijgen en geld verdienen, daarna een nog betere en beter doordachte shop bouwen;-)

Reageren