/usr/local/bin/php -q -f /home/wouter/domains/mijndomein.be/public_html/backup/index.phpWat is mis met deze cronjob code? (op de plaats van mijndomein staat effectief mijn echte domein en mijndomein.be/backup/index.php doet wat het moet doen...)
Kleine Vragen Topic #4
Wat is mis met deze cronjob code? (op de plaats van mijndomein staat effectief mijn echte domein en mijndomein.be/backup/index.php doet wat het moet doen...)
Wouter schreef:Wat is mis met deze cronjob code? (op de plaats van mijndomein staat effectief mijn echte domein en mijndomein.be/backup/index.php doet wat het moet doen...)/usr/local/bin/php -q -f /home/wouter/domains/mijndomein.be/public_html/backup/index.php
Je kunt je commando eens veranderen naar iets als dit:
/usr/local/bin/php -q -f /home/wouter/domains/mijndomein.be/public_html/backup/index.php > /home/wouter/output.txt 2>&1De output van je bestand wordt dan weggeschreven in ouput.txt, dan kun je op die manier debuggen.
Wat ik vaak gezien heb bij cronjobs is dat er relatieve paden gebruikt worden (require_once ../config.php) maar die werken niet altijd als je op deze manier het PHP-bestand aanroept.
Luukvdo schreef:Je kunt je commando eens veranderen naar iets als dit:Wat is mis met deze cronjob code? (op de plaats van mijndomein staat effectief mijn echte domein en mijndomein.be/backup/index.php doet wat het moet doen...)Eerdere citaten tonen
Wouter schreef:/usr/local/bin/php -q -f /home/wouter/domains/mijndomein.be/public_html/backup/index.php
/usr/local/bin/php -q -f /home/wouter/domains/mijndomein.be/public_html/backup/index.php > /home/wouter/output.txt 2>&1De output van je bestand wordt dan weggeschreven in ouput.txt, dan kun je op die manier debuggen.
Wat ik vaak gezien heb bij cronjobs is dat er relatieve paden gebruikt worden (require_once ../config.php) maar die werken niet altijd als je op deze manier het PHP-bestand aanroept.
Je zat er knal op! Inderdaad een probleem met een require_once../
Ondertussen opgelost door het volledige pad op te roepen. Dankjewel!!
Ik heb nu dit bovenaan een file staan.
Maar er blijven strings als "Sunday" komen. Weet iemand hoe het dan wel moet?
[COLOR= #0000BB]<?php[/COLOR]
[URL="http://www.php.net/setlocale"]setlocale[/URL][COLOR= #007700]([/COLOR]LC_ALL[COLOR= #007700],[/COLOR] [COLOR= #DD0000]nl_NL[/COLOR][COLOR= #007700]);[/COLOR]
?>Maar er blijven strings als "Sunday" komen. Weet iemand hoe het dan wel moet?
Wouter schreef:Wat is mis met deze cronjob code? (op de plaats van mijndomein staat effectief mijn echte domein en mijndomein.be/backup/index.php doet wat het moet doen...)/usr/local/bin/php -q -f /home/wouter/domains/mijndomein.be/public_html/backup/index.php
Hmm ik zou cronjobs niet in public_html zetten
Hoezo zou je uberhaupt php scripts in een html map zetten? 
Jessee schreef:Het is geen map specifiek voor html. Dat is gewoon hoe DirectAdmin server werken. public_html bevat bestanden die publiekelijk zichtbaar zijn als je naar je website gaatHoezo zou je uberhaupt php scripts in een html map zetten?
Luukvdo schreef:Zet je je php code niet buiten de public root zodat niemand erbij kan? En dan expose je alleen de html..Het is geen map specifiek voor html. Dat is gewoon hoe DirectAdmin server werken. public_html bevat bestanden die publiekelijk zichtbaar zijn als je naar je website gaatEerdere citaten tonen
Jessee schreef:Hoezo zou je uberhaupt php scripts in een html map zetten?
Nja ik doe al jaren geen php meer so wouldnt know.
Jessee schreef:Dat is afhankelijk van hoe je je site opbouwt. Meestal zou ik alle PHP gewoon in de public_html zetten.Zet je je php code niet buiten de public root zodat niemand erbij kan? En dan expose je alleen de html..Eerdere citaten tonen
Luukvdo schreef:Het is geen map specifiek voor html. Dat is gewoon hoe DirectAdmin server werken. public_html bevat bestanden die publiekelijk zichtbaar zijn als je naar je website gaatEerdere citaten tonen
Jessee schreef:Hoezo zou je uberhaupt php scripts in een html map zetten?
Nja ik doe al jaren geen php meer so wouldnt know.
Laravel, een PHP framework dat ik nu vaak gebruik, doet het iets anders. Daar staat enkel de index.php in de public map en de rest van de PHP code buiten de public map.
Luukvdo schreef:Ah oké, dat laatste lijkt mij logisch ja.Dat is afhankelijk van hoe je je site opbouwt. Meestal zou ik alle PHP gewoon in de public_html zetten.Eerdere citaten tonen
Jessee schreef:Zet je je php code niet buiten de public root zodat niemand erbij kan? En dan expose je alleen de html..Eerdere citaten tonen
Luukvdo schreef:Het is geen map specifiek voor html. Dat is gewoon hoe DirectAdmin server werken. public_html bevat bestanden die publiekelijk zichtbaar zijn als je naar je website gaatEerdere citaten tonen
Jessee schreef:Hoezo zou je uberhaupt php scripts in een html map zetten?
Nja ik doe al jaren geen php meer so wouldnt know.
Laravel, een PHP framework dat ik nu vaak gebruik, doet het iets anders. Daar staat enkel de index.php in de public map en de rest van de PHP code buiten de public map.
En die index exposed dan alle publieke shit.
In javascript werkt het weer anders omdat je daar zelf een webserver nog moet bouwen. Maar alle modules staan dan niet in je public directory, alleen je html en je assets. (js, css, images, etc)
Dylan schreef:Hmm ik zou cronjobs niet in public_html zettenWat is mis met deze cronjob code? (op de plaats van mijndomein staat effectief mijn echte domein en mijndomein.be/backup/index.php doet wat het moet doen...)Eerdere citaten tonen
Wouter schreef:/usr/local/bin/php -q -f /home/wouter/domains/mijndomein.be/public_html/backup/index.php
Waarom niet als ik vragen mag? Ik vind het juist handig dat ik het script dan ook eerst kan testen, handmatig, voor er een cron opstaat. Vandaar in public_html.
Toegang tot "backup" via de website is overigens geblokkeerd via htaccess, dus niemand anders kan het script aanroepen.
Kan het allemaal mis op hebben, dus correct me if Im wrong
Je kan toch ook resten door php command te runnen via je cli?
Jessee schreef:Ik snap even niet je bedoelt?Je kan toch ook resten door php command te runnen via je cli?
Testen*
Dat je in je cli php cmd runt, dan run je php file zonder t via browser te doen
Dat je in je cli php cmd runt, dan run je php file zonder t via browser te doen
Wouter schreef:Waarom niet als ik vragen mag? Ik vind het juist handig dat ik het script dan ook eerst kan testen, handmatig, voor er een cron opstaat. Vandaar in public_html.Hmm ik zou cronjobs niet in public_html zettenEerdere citaten tonen
Dylan schreef:Wat is mis met deze cronjob code? (op de plaats van mijndomein staat effectief mijn echte domein en mijndomein.be/backup/index.php doet wat het moet doen...)Eerdere citaten tonen
Wouter schreef:/usr/local/bin/php -q -f /home/wouter/domains/mijndomein.be/public_html/backup/index.php
Toegang tot "backup" via de website is overigens geblokkeerd via htaccess, dus niemand anders kan het script aanroepen.
Kan het allemaal mis op hebben, dus correct me if Im wrong
Omdat als iemand een beetje rondsnuift op je website en hij komt op /backup/index.php wordt er een backup gemaakt wat eigenlijk niet door een gebruiker zou moeten kunnen. Je kan het met htaccess blokkeren maar dat hoort eigenlijk niet zo.
toevoeging op zondag 9 april 2017, 13
26:Cronjobs horen buiten de webroot.