Je quote de halve zin, maar ook een notice bij een niet gedefinieerde variabele is echt een oplossing van niets. Of je geeft een exception / error of niet. Nu heb je dus afhankelijk van het niveau van error_reporting onverwachte bij-effecten. Het feit dat je dan weer met een @ operator die notice moet gaan onderdrukken maakt het nog erger.quote:
Van notices hebben mensen wel degelijk last. Zoals ik zeg is dat een bij-effect. Zeker wanneer mensen de code gebruiken in HTML, kunnen de gebruikers het te zien krijgen, wat doorgaans niet wenselijk is. Wanneer je met gecompileerde talen werkt zijn warnings / notices niet zo'n probleem. Prima te hanteren wanneer er bijvoorbeeld deprecated zaken worden gehanteerd. Runtime allerhande notices gaan uitspugen is nooit wenselijk.quote:Op woensdag 18 maart 2015 14:58 schreef Tijn het volgende:
Natuurlijk heb je helemaal gelijk dat PHP geen doordacht design heeft en in de loop der jaren enorm uit de kluiten is gegroeid, zonder dat dat aanvankelijk voorzien was. Maar ik vind niet dat er wat betreft ongedefinieerde variabelen nou echt zoveel mis is.
Je zegt het zelf al: geef als taal een error of niet. Nou, in het geval van PHP is het antwoord duidelijk: het gebruik van een ongedefinieerde variabele is geen enkel probleem. Dat je er een notice over krijgt, is een poging van PHP om hun gebruikers een beetje op te voeden, dat is alles. Maar daar heeft toch niemand last van verder?
| 1 2 3 | <?php ( isset($_GET[$table[$i]) ? $$table[$i] = new data($table[$i]) : false ); ?> |
| 1 2 3 | <?php $page->when('published')->take(-4); // laatste 4 gepubliceerde items van deze pagina ?> |
Ik kijk eerst of de table-name (mogelijk met een hard-coded/cached array) een match heeft met de url, als dat waar ik is pak ik de tabel met een query en hang deze aan een nieuwe instance van mn data class. de waarde van de get-key gebruik ik om de query te limiteren voor wat relevant is aan die pagina.quote:Op donderdag 19 maart 2015 10:36 schreef KomtTijd... het volgende:
Dat kun je toch veel beter in je query afhandelen? Dit lijkt me performance-wise niet bepaald optimaal. En als je tabellen wat groter worden ga je geheid uit je geheugen limiet lopen.
Dat bewijst zonder dat ik weet wat dat is, de noodzaak voor een ORMquote:Op donderdag 19 maart 2015 10:54 schreef KomtTijd... het volgende:
Je bent dus min of meer je eigen ORM aan het uitvinden? Daar is op zich niets mis mee nee.
Natuurlijk, maar lijkt me relevant dat hij daar even rekening mee houdt.quote:Op donderdag 19 maart 2015 10:56 schreef KomtTijd... het volgende:
[..]
riep daar iemand prepared statements?
SQL injectie kan met iedere query waar user input in staat. Ook met select queries. Daarom nooit user input direct in je query verwerken.quote:Op donderdag 19 maart 2015 10:57 schreef n8n het volgende:
[..]
Dat bewijst zonder dat ik weet wat dat is, de noodzaak voor een ORM![]()
Injecteren? Er gaat niks via deze weg 'omhoog', de data die losgetrokken kan worden is al openbaar. Verder nog hiaten waar ik geen idee van heb? Weet alleen dat ik PDO moet gebruiken en ALLES moet valideren wat omhoog gaat.
user input zoals een get varible zoals /?page=malafide-code. Dat vang je af met pdo/prepared statements?quote:Op donderdag 19 maart 2015 11:02 schreef KomtTijd... het volgende:
[..]
SQL injectie kan met iedere query waar user input in staat. Ook met select queries. Daarom nooit user input direct in je query verwerken.
En kijk ook eens naar bestaande ORM libs, zoals doctrine of redbean.
Klopt. Enige punt is dat je in jouw geval moet uitkijken voor /?malafide-code=waarde aangezien je ook min of meer dynamische tabelnamen wilt hebben op basis van de naam van request parameters. Gelukkig gebruik je de tabel en niet de request parameter daarvoor, dus dat moet goed gaan, maar het is wel iets waar je mee moet uitkijken. Helemaal omdat tabelnamen niet middels prepared statements in een query kunnen worden gestopt, dus daar ben je zelf verantwoordelijk voor het voorkomen van SQL injection.quote:Op donderdag 19 maart 2015 11:06 schreef n8n het volgende:
[..]
user input zoals een get varible zoals /?page=malafide-code. Dat vang je af met pdo/prepared statements?
de table names zet ik in een var:quote:Op donderdag 19 maart 2015 11:32 schreef Monolith het volgende:
[..]
Klopt. Enige punt is dat je in jouw geval moet uitkijken voor /?malafide-code=waarde aangezien je ook min of meer dynamische tabelnamen wilt hebben op basis van de naam van request parameters. Gelukkig gebruik je de tabel en niet de request parameter daarvoor, dus dat moet goed gaan, maar het is wel iets waar je mee moet uitkijken. Helemaal omdat tabelnamen niet middels prepared statements in een query kunnen worden gestopt, dus daar ben je zelf verantwoordelijk voor het voorkomen van SQL injection.
| 1 2 3 4 | <?php $tables = "show tables from $db"; //of $tables = ['table1', 'table2']; ?> |
Ow perlquote:Op woensdag 18 maart 2015 13:21 schreef Monolith het volgende:
[..]
Veel korter dan een ternary operator krijg je een if-then-else statement niet. 'this-when-true' slaat ook niet ergens op. Wat je eigenlijk wilt is een 'default-if-null'-constructie.
Als je dat echt kort wilt, dan maak je er toch gewoon een functie van, zodat je $var = defaultIfNotSet(originalValue, defaultValue) kan hanteren?
| 1 2 3 4 | $foo //= "bar" ; # is hetzelfde als $foo = defined $foo ? $foo : "bar" ; |
quote:
quote:Op woensdag 18 maart 2015 13:21 schreef Monolith het volgende:
[..]
Veel korter dan een ternary operator krijg je een if-then-else statement niet. 'this-when-true' slaat ook niet ergens op. Wat je eigenlijk wilt is een 'default-if-null'-constructie.
Als je dat echt kort wilt, dan maak je er toch gewoon een functie van, zodat je $var = defaultIfNotSet(originalValue, defaultValue) kan hanteren?
| 1 | $eenVariabele = $dezeWaardeAlsHijBestaat ?? $andersDit; |
Je kan PHP 7 al uitproberen dan? De meest recente versie die gebruikt kan worden, is bij ons nog steeds PHP 5.6quote:
Dat hoeft toch niet perse? Specs kunnen al lang voor enige release bekend zijn. Maar volgens mij wordt er al best lang gesleuteld aan php7 dus je kunt vast wel ergens een dev build vandaan halen als je zou willen.quote:Op zaterdag 21 maart 2015 22:05 schreef Robuustheid het volgende:
[..]
Je kan PHP 7 al uitproberen dan? De meest recente versie die gebruikt kan worden, is bij ons nog steeds PHP 5.6
Dat is wel mooi.quote:Op maandag 23 maart 2015 06:26 schreef totalvamp het volgende:
http://www.phpclasses.org(...)inally-Approved.html
EINDELIJK!
quote:Op maandag 23 maart 2015 14:37 schreef bondage het volgende:
Hier nog mensen belang bij een leuke functie als database opschoon mannetje?
https://www.starapple.nl/vacatures/58-sql-dba/
_
quote:Aanbod
3500 met niets bijzonders
quote:Op maandag 23 maart 2015 14:37 schreef bondage het volgende:
Hier nog mensen belang bij een leuke functie als database opschoon mannetje?
https://www.starapple.nl/vacatures/58-sql-dba/
_
Die viel mij ook op ja.quote:
Dit is inderdaad een voorbeeld van hoe je het absoluut niet moet doen. Leuk aanbod maar ik laat het liever aan me voorbij gaanquote:Op maandag 23 maart 2015 16:37 schreef Monolith het volgende:
[..]
Die viel mij ook op ja.
Zo trek je ook geen mensen natuurlijk. Zet er dan iets neer in de trant van '3500 euro, een zak beukenootjes en een eekhoorn' of iets dergelijks. Dat zou wel bijzonder zijn.
beter dan de eeuwige zoektocht naar een ondernemende teamplayer die van aanpakken weet.quote:Op maandag 23 maart 2015 16:41 schreef bondage het volgende:
[..]
Dit is inderdaad een voorbeeld van hoe je het absoluut niet moet doen. Leuk aanbod maar ik laat het liever aan me voorbij gaan
Zie jij dat vaak in vacatures? Ik zie toch voornamelijk zwaar op de inhoud gerichte vacatures voorbij komen.quote:Op maandag 23 maart 2015 21:39 schreef n8n het volgende:
[..]
beter dan de eeuwige zoektocht naar een ondernemende teamplayer die van aanpakken weet.
Nog niet geprobeerd nee, maar ik hou gewoon de RFC's in de gatenquote:Op zondag 22 maart 2015 22:30 schreef Robuustheid het volgende:
Yep, maar ik ga wel vanuit dat TwenteFC niet daar al mee loopt te klooien. Want dat PHP 7 is nog vrij buggy en vooral voorbehouden aan ontwikkelaars die contributies doen aan de PHP community.
Ik lees ze eigenlijk vrijwel nooit, het zijn wel de vervelende pro-actieve teksten die negatief opvallen (geschreven door zo’n ‘vlotte’ marketing-asshole).quote:Op maandag 23 maart 2015 21:51 schreef Monolith het volgende:
[..]
Zie jij dat vaak in vacatures? Ik zie toch voornamelijk zwaar op de inhoud gerichte vacatures voorbij komen.
Ik sta op de mailinglist van een aantal recruiters en daarnaast word ik sowieso wel vaak benaderd via LinkedIn en het zijn in ieder geval altijd vacatures die naast de primaire arbeidsvoorwaarden voornamelijk benadrukken dat er uitstekende opleidingsbudgetten zijn, met welke cutting-edge technologieën wordt gewerkt, enzovoort. Zelfs in de HR zijn ze niet helemaal achterlijk en weten ze wel dat ze de vacatures moeten aanpassen op hun doelpubliek. Dat de recruiters vaak zelf niet snappen dat bepaalde technologieën mijlenver uit elkaar liggen is natuurlijk een ander verhaal.quote:Op maandag 23 maart 2015 23:03 schreef n8n het volgende:
[..]
Ik lees ze eigenlijk vrijwel nooit, het zijn wel de vervelende pro-actieve teksten die negatief opvallen (geschreven door zo’n ‘vlotte’ marketing-asshole).
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 | <?php class Item<T> { protected $item; public function __construct(T $item = null) { $this->item = $item; } public function getItem() { return $item; } public function setItem(T $item) { $this->item = $item; } } class Test { public function runTest() { $item = new Item<StdClass>; var_dump($item instanceof Item); // true $item->setItem(new StdClass); // works fine // $item->setItem([]); // E_RECOVERABLE_ERROR } } ?> |
| 1 2 3 4 5 6 7 8 9 10 11 | RewriteEngine On php_flag display_startup_errors on php_flag display_errors on php_flag html_errors on php_flag log_errors on RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^(.*)$ index.php?querystring=$1 [L] |
Kijk eens in de network tab van firebug/developer tools, misschien zit er in je html een tag met een verkeerde of lege href/src die naar de index.php wordt doorgestuurd.quote:Op dinsdag 31 maart 2015 15:39 schreef boskameel het volgende:
Ik weet niet of dit hier hoort, maar kent iemand het probleem dat bij url rewrites 2 keer de regel wordt uitgevoerd?
Mijn htaccess ziet er zo uit:
[ code verwijderd ]
als ik bv naar http://mijndomein/blabla/ ga, dan wordt het index.php 2 keer opgeroepen. Zit er gewoon een foutje in, of is dit standaard?
[edit]
Ik zie dat het probleem zich alleen voordoet in firefox en ieDit is toch serverside?
[/edit]
Is het niet je browser die een request doet naar je favicon.ico?quote:Op dinsdag 31 maart 2015 16:14 schreef boskameel het volgende:
Thanks, ik zie het, het is de base href. Maar die heb ik nodig, anders zal ik alles moeten omzetten naar absolute paden.
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 | <?php $expiretime=10080; //expire time in minutes, 7 days = 7*24*60 $tmpFolder="pictures/"; $fileTypes="*.*"; foreach (glob($tmpFolder . $fileTypes) as $Filename) { // Read file creation time $FileCreationTime = filectime($Filename); // Calculate file age in seconds $FileAge = time() - $FileCreationTime; // Is the file older than the given time span? if ($FileAge > ($expiretime * 60)){ // Now do something with the olders files... echo "The file $Filename is older than $expiretime minutes\n"; //delete files: unlink($Filename); } } ?> |
Krijg je helemaal geen output? Alleen jpg verwijderen zou je hiermee moeten kunnen doen: $fileTypes="*.*"; veranderen in $fileTypes="*.jpg";quote:Op zondag 5 april 2015 17:36 schreef davedavy het volgende:
Een vraagje, ik ben zelf de PHP taal niet machtig maar met Google kom je al een heel eind. Laatst heb ik een leuk scriptje gevonden dat netjes in mijn map waar ik beveiligingscamera foto's opsla de foto's ouder dan 7 dagen verwijderde. Nu is mijn website leuk gecrasht en ben ik alles kwijt![]()
Met als gevolg, ik moet opnieuw .jpg's automatisch verwijderd krijgen die ouder zijn dan 7 dagen. Puur jpg's, anders verwijderd die alles eromheen ook
Ik heb zelf dit gevonden:
[ code verwijderd ]
https://naiboo.wordpress.(...)ys-or-10080-minutes/
Maar die doet niksWat doe ik fout?
Uiteraard heb ik $fileTypes="*.*" al veranderd naar $fileTypes="*.jpg" maar ik krijg totaal geen output, de jpg bestandjes staan er nog leuk in. En ze zijn ook ouder dan de aangegeven tijd.quote:Op zondag 5 april 2015 17:43 schreef bondage het volgende:
[..]
Krijg je helemaal geen output? Alleen jpg verwijderen zou je hiermee moeten kunnen doen: $fileTypes="*.*"; veranderen in $fileTypes="*.jpg";
Beiden ja, ik heb atm de tijd op slechts 1 minuut staan en hij verwijderd nog steeds nietsquote:Op zondag 5 april 2015 17:58 schreef TwenteFC het volgende:
Heb je wel de foutmeldingen aan staan? En zijn er uberhaupt .jpg afbeeldingen die ouder dan 7 dagen zijn?
| 1 | [05-Apr-2015 10:58:54 CST6CDT] PHP Warning: Module 'sqlite' already loaded in Unknown on line 0 |
| Forum Opties | |
|---|---|
| Forumhop: | |
| Hop naar: | |