Posts by FangorN

Als je een audio-fragment op kunt vangen dan zou je het hiermee eens kunnen proberen. Het opslaan van snippets lijkt mij sowieso wel handig, want die kun je dan later nogmaals gebruiken mocht je iets initieel niet vinden, of kun je deze aan anderen laten horen.

Er moet natuurlijk wel een verband zijn tussen de twee tabellen (de employee id's moeten op een of andere manier overeenstemmen).

Probeer het eens met (NOT) EXISTS:

SELECT e.name
FROM employees e
WHERE NOT EXISTS (
    SELECT w.id
    FROM working_hours w
    WHERE w.employee = e.id
    AND w.date = '2015-07-09'
)

Overigens, als je enkel opslaat wanneer iemand niet beschikbaar is zegt dat niets over wanneer iemand wel beschikbaar is.

Als je bijvoorbeeld maar 4 dagen in de week werkt (ma-do) dan ben je morgen (vr) wel beschikbaar volgens deze query.

Wordt iemand dan op zijn vrije dag ingeroosterd?

Ik zou dus ook een soort van werktijden table verwachten, maar dan in de zin: wanneer is iemand beschikbaar (de tegenhanger van wanneer is iemand bezet - de working_hours tabel)

En hier probeer je dus de beschikbaarheid te bepalen via een query, maar zou het niet veel intuïtiever zijn om e.e.a. visueel weer te geven in een soort van timetable / kalender waar (gekleurde) blokken in staan die reeds ingeroosterde uren weergeven? Dan is in één oogopslag duidelijk wie er niet op enig moment beschikbaar is.

Oh en die "from" kolomnaam is niet heel erg handig gekozen, want dat is een gereserveerd woord :/.

Hey don't take my word for it, ik ben geen rechten expert.

Tis gewoon wat blue-sky thinking hiero. Maar goed, die blokkades zijn er niet voor niets he. En dat er (zomaar) weer uitslopen... I don't know man :).

Je zegt "country gebonden", dan denk ik aan een IP / ISP based systeem? Hoe gaat JavaScript (doorgaans clientside) dit oplossen?

Je zou kunnen denken aan een VPN of proxy, maar waarom zou je zo'n restrictie willens en wetens omzeilen, dat lijkt mij vragen om problemen? Tenzij je niet te traceren bent natuurlijk, maar goed, tis maar net hoe jouw moraal kompas is afgesteld.

Video niet beschikbaar = pech lijkt mij de simpele oplossing.

Daarbij gebruik je YouTube toch als een soort dienst, er is vast een soort van overeenkomst waar je onbewust mee instemt / in hebt gestemd, en dat wat jij vraagt staat daar hoogstwaarschijnlijk haaks op. Dat zou dan dus (op zijn minst) kunnen leiden tot... het jou ontzeggen van de dienst.

Citaat van ismail123

Ik raad eerder pdo of een framework aan omdat het flexibeler is om te wisselen met andere soorten databases.

Ugh.

Waarom wordt dit (nog steeds) aangehaald als reden om PDO te gebruiken? Het is flexibiliteit die je zelden gebruikt.

Okay, je moet het zo zien:
1. Je bent niet van plan om in de huidige opzet ooit nog een andere database te gebruiken dan MySQL --> gebruikt MySQLi. MySQLi is geschreven voor MySQL dus deze schoen past gewoon het beste.

2. Je bent er nog niet helemaal uit of het uiteindelijk MySQL gaat worden en je wilt deze keuze nog een beetje open houden. Je zou dan kunnen overwegen om PDO te gebruiken. PDO is niet geschreven voor een specifieke database, hier zijn de verschillende drivers voor. Zoals PDO_MYSQL.

Nog zo'n fabeltje: PDO is makkelijker "want je hoeft minder statements te leren voor het gebruik". Dit klopt om twee redenen niet:

1. De leercurve zit hem in het aanleren (en correct gebruik) van de specifieke driver die je gebruikt (in combinatie met PDO zelf), en niet in het handjevol methoden die je gebruikt.

2. PDO biedt geen data abstraction aan, dit zou een laag zijn die je zelf bovenop PDO zou moet zetten. Dit houdt in dat de syntax van je queries (de vorm van je SELECT-statements enzo) hoogstwaarschijnlijk database-specifiek zijn en daarmee is het dus technisch gezien onmogelijk om "vrij te schakelen tussen databases" wat dus het hele voordeel waar keer op keer aan gerefereerd wordt teniet doet.

Daarbij: noch MySQLi noch PDO is een wondermiddel waarmee alles in 1x Goed en Veilig wordt. Je zult je nog steeds moeten verdiepen in een veilig gebruik. Denk aan het selecteren van de juiste character encoding en het escapen van de DATA delen binnen je SQL.

Mocht je interesse hebben, op mijn homepage staat een artikel over MySQLi.

Citaat van 1qq23q

Dat snap ik, dat is ook de reden dat ik hem nog open heb, maar het gaat echt om het begin stadium er valt nog niet veel te lezen daarom twijfel ik of het beter is mensen eerst te laten registreren.

Als je je kermisattractie aan het bouwen (en testen) bent, stel je deze dan al open voor publiek?

Wanneer er iets te zien valt / het forum af is zou ik deze readonly toegankelijk stellen voor niet-ingelogde leden zoals A.Tytgat voorstelt... met nog wel de kanttekening dat het nogal afhangt van het soort content, dit bepaalt de mate van afscherming.

Stel bijvoorbeeld dat het forum een verzamelplaats is voor -ik noem maar wat- mensen met een aandoening of een zeldzame ziekte, ik weet niet of je werkgever daar bij zou moeten kunnen doordat deze site volledig crawlbaar is.

Dan heb je bijvoorbeeld een datingsite, waarbij je zelf wss heel strak kunt afstellen wat je deelt met wie.

En dan heb je nog community sites als deze.

Hangt allemaal nogal af van de content hoe iets werkt eh.

De eerste vraag die bij mij opkomt is: waardoor worden deze geblockt?
- door YouTube zelf (regio-gebonden content)?
- door een firewall?
- door een programma of administratieve rechten van het apparaat waar je op werkt?
- specifiek door je browser of een browser addon?
- iets anders?

Als je zegt "Dokter ik heb ergens pijn" kan een dokter niet meteen een recept uitschrijven :).

Je hebt het over een error, hoe luidt deze?

Dus je gebruikt nu WP_Query? En je krijgt niet het gewenste resultaat terug?

Tijd om uit te zoeken wat er aan je database gevoerd wordt.

Of zet logging (tijdelijk) aan in de database zelf.

Tegelijkertijd zou je een native MySQL query kunnen bouwen die wel werkt, en dan kijken of je een soortgelijke variant kunt bouwen met WP_Query. Als dit niet lukt, maak je een custom query.

De correcte syntax in dit geval (voor een typecast) is:

CONVERT(pm4.meta_value, UNSIGNED)

UNSIGNED als je enkel met niet-negatieve waarden te maken hebt, maar wellicht is SIGNED veiliger.

Let ook heel erg goed op met vergelijkingen - als de typen op meerdere plaatsen niet kloppen kan dit voor vreemde resultaten zorgen, vergelijk:

mysql> SELECT '2' >= '0' AND '2' <= '100000';
+--------------------------------+
| '2' >= '0' AND '2' <= '100000' |
+--------------------------------+
|                              0 |
+--------------------------------+
1 row in set (0.00 sec)


mysql> SELECT 2 >= 0 AND 2 <= 100000;
+------------------------+
| 2 >= 0 AND 2 <= 100000 |
+------------------------+
|                      1 |
+------------------------+
1 row in set (0.00 sec)

In het eerste geval heb je te maken met allemaal strings, hier wordt dus de alfabetische (lexicografishe) sortering gebruikt. Hierbij valt '2' niet tussen '0' en '1-met-nog-spul-hier-achter'.

In het tweede geval heb je te maken met enkel getallen, hier wordt dus een numerieke sortering gebruikt. Daarbij valt 2 wel tussen 0 en 100000.

Je begeeft je al heel snel op glad ijs als je typen gaat combineren zoals je in bovenstaande SQL doet. Dit gaat waarschijnlijk nog goed omdat MySQL je string (pm4.meta_value) automatisch typecast naar een getal in je vergelijkingen aan het einde van je query.

Maar netter/beter is dus een wat strictere omgang met typen. En idealiter zat je data al op de goede manier opgeslagen in je database uiteraard.

Staat er iets in je errorlogs?

Heb je al eens een die('lalala') voor / na die query gezet, om te kijken of je script(s) uberhaupt zover komen of het schip ergens eerder strandt?

Heb je de broncode (view > source) van de output bekeken, wellicht wordt er iets verkeerd gerenderd, valt het van je scherm of wat dan ook, dus het is er wel, alleen je ziet het niet?

Wat zegt je netwerk tab bij het opvragen van de pagina? Internal server error (al lijkt mij dat sterk dat dit per browser verschilt)? 200 OK?

Mogelijk zijn er pagina's gecached? Staat alle cache uit?

Als het een javascript error betreft, probeer dit eens (verder niet uitgetest). Ook gebruikmaking van een framework (jQuery) helpt het voorkomen dat je crossbrowser incompatibiliteit hebt.

Het komt niet heel vaak voor dat iets in browser X wel werkt, en in browser Y niet dus Ik ben heel benieuwd waar dit aan ligt.

Weet je heeeeeeeel zeker dat beide browsers zich in dezelfde toestand bevinden? Dus bijvoorbeeld dat je in beide browsers bent ingelogd als gebruiker X?

Bekijk je ook in beide browsers de goede (en dezelfde) pagina?

Ook: als dit soort UPDATEs niet in database-transacties staan dan is dit een potentiële bron van fouten.

Wanneer de controle van het huidige bedrag en het wijzigen van dit bedrag (in wat voor zin dan ook) niet in één ondeelbare actie gevangen zit (oftewel, niet in een database-transactie zit) dan kan er gesjoemeld worden met deze bedragen.

- waar komt $userID vandaan?
- welke waarde heeft $userID?
- zijn deze waarden hetzelfde in de verschillende browsers (of breder: is de toestand van beide browsers hetzelfde)?
- je controleert niet of er een resultaat is, maar gaat er vanuit dat deze er is, beter is om dit expliciet te controleren met mysqli_num_rows($jeResult) of het object georienteerde equivalent
- minder waarschijnlijk, maar zeker iets om rekening mee te houden: kloppen al je character encoderingen?
- zet het rapporteren en weergeven van foutmeldingen aan

<?php
// zet dit helemaal bovenaan het eerste bestand dat wordt ingeladen
error_reporting(E_ALL);
ini_set('display_errors', 'stdout');
?>

(EDIT: ook bij het ontwikkelen is het aan te raden om deze instellingen te gebruiken, je kunt fouten meteen wanneer ze optreden oplossen; voorkomen is beter dan genezen)

Het oplossen van bugs is vaak een proces van eliminatie waarbij je in eerste instantie een situatie creeert waarbij je het jezelf makkelijk maakt om een probleem op te lossen.

Dit doe je onder andere door:
- het "zoekgebied" te verkleinen - waar speelt het probleem precies?
- foutmeldingen aanzetten - laat het systeem het werk voor je doen; idealiter legt het systeem meteen de vinger op de zere plek

Uit een eerder fragment van jou:

$sql = "SELECT username, password, admin, gebruiker FROM inlog WHERE username='$username' AND password='$password'";
 $query = mysqli_query($conn, $sql);


// etc.

Waar komen in dit geval $username en $password vandaan en hoe zien deze er uit?

Een systeem kan simpel zijn en nog steeds veilig, hier hoef je niet veel voor te doen maar je moet de onderliggende principes wel een beetje begrijpen.

Ik kan wel toelichting geven op je code maar ik kan je niet in 2 zinnen overdragen wat belangrijk is. Dat is toch meer leren door het te doen. Een vuistregel die je wel altijd kunt hanteren of in je achterhoofd zou moeten houden is de volgende:

filter input, escape output

filter input houdt in: controleer je invoer - dit kan van alles zijn (formulier, URL variabelen etc.). Als je verwacht dat bepaalde invoer een bepaalde vorm moet hebben, controleer hier dan op. Bijvoorbeeld: als je verwacht dat $_GET['id'] een getal bevat, controleer dit!

escape output betekent: ontdoe data (waar nodig) binnen een bepaalde context van haar speciale betekenis. Bijvoorbeeld: de karakters < en > in de tekst '<b>dikgedrukt</b>' hebben in de HTML-context eem speciale betekenis: deze duiden (mogelijk) de begrenzingen aan van HTML tags. Om deze karakters binnen HTML van hun speciale betekenis te ontdoen zijn hier escape-functies voor zoals htmlentities() en htmlspecialchars().

Zo zijn er ook escape-functies voor andere contexten, zoals de _real_escape_string() functies voor MySQLi om de DATA delen in je SQL van mogelijk speciale betekenis te ontdoen.

Dat is namelijk precies wat een SQL-injectie is: je voegt een stuk tekst (DATA) in in je query die vervolgens als SQL geinterpreteerd wordt terwijl dit eigenlijk enkel als DATA gebruikt mocht worden. Met een SQL-injectie wordt meestal de werking van de query gemanipuleerd zodat deze een andere betekenis krijgt / iets anders doet dan eigenlijk de bedoeling.

Security dingetje: waarom komt $password vandaan in je $sql string? Escape je deze ook of komt deze rechtstreeks uit $_POST? In het laatste geval is je query mogelijk vatbaar voor SQL-injectie.

Dan stop je een heleboel informatie in je sessie. Dat is helemaal niet nodig en ook onhandig. Stel dat je iemand (anders) een admin maakt - dan zou deze persoon opnieuw in moeten loggen? Deze informatie is immers niet bijgewerkt in zijn/haar sessie. Ook als je iemand het admin-recht ontneemt, gaat dit pas in als deze persoon opnieuw inlogt. Kortom: dit soort data in je sessie veroudert snel en loopt dan niet meer gelijk met de data in je database.

Het is gewoon in meerdere opzichten beter en verstandiger om elke page-access deze gegevens opnieuw te "berekenen" aan de hand van het user-id in de sessie (het enige veld wat relevant is om te onthouden qua gebruikers-informatie). Deze informatie sla je bijvoorbeeld op in een user-object wat overal in je code beschikbaar is. Na een page-refresh wordt dit user-object opnieuw opgebouwd met actuele informatie uit je database.

- welke waarde zit er in $_SESSION['gebruiker']?
- start je je sessie / zet je je sessie voort met session_start() voordat je $_SESSION gebruikt?
- hoeveel resultaten levert deze query op en kloppen deze resultaten?

Citaat van emreeatsaoy

Maar doordat de id-nummering verkeerd is kan de unieke gebruiker zijn eigen adressen niet laten wijzigen.

Uhm, ik neem aan dat je op een of andere manier bijhoudt dat iemand is ingelogd? Bij voorkeur via een sessie. Hier kun je ook het user-id van de ingelogde gebruiker in opslaan. In plaats van dat je het user id uit $_GET haalt haal je deze nu uit $_SESSION.

Het lijkt mij het handigst dat je als je naar de edit-pagina navigeert, je een verwijzing naar het user-id meegeeft, bijvoorbeeld edituser.php?id=64

Op de edituser.php pagina (die natuurlijk alleen toegankelijk is voor een admin) controleer je of $_GET['id'] een numerieke waarde bevat en als dat het geval is haal je de bijbehorende user data op.

Een losse checkbox heeft meestal gewoon de waarde "1", wat deze betekent wordt gevangen door de naam ("admin", "gebruiker"). Impliceert het een trouwens niet het ander? Een admin is altijd ook een gebruiker?

Anyhoo, ik neem aan dat je in de database een kolommetje is_admin, is_gebruiker o.i.d. hebt waar je een 0 of een 1 in opslaat? Om deze checkbox opnieuw aan te vinken doe je een hele simpele check (letterlijk en figuurlijk :)):

<input type="checkbox" name="admin" value="1"<?php echo ($userRecord['is_admin_kolom'] ? ' checked="checked"' : '') ?>" />

Als je op den duur een wat complexer rechtenmanagement hebt moet je misschien overstappen op een andere aanpak/database inrichting.

Dat bedoel ik niet. Je verwijst nu naar het script prijs1.php. Dat klinkt als een standalone script waarin je alles regelt (connectie maken, andere includes en functies inladen etc.).

Zo heb je waarschijnlijk ook henk.php, piet.php en klaas.php waarin je dezelfde includes stopt. Vaak zit daar veel code in die hetzelfde is.

Maar wat als je nu één script hebt waarin alles (on-demand) wordt geregeld en via welke alle informatie wordt verwerkt? Een soort van kapstok waar je alles aan op hangt. Een van de voordelen is dan ook dat je altijd hetzelfde (interne) directory-pad als uitgangspunt hebt. Ook hoef je dan geen requires gebruiken die er zo uitzien ../../../../something.php afhankelijk van waar het bestand waarin je required staat. Het uitgangspunt is altijd index.php in je root. Vaste Uitgangspunten Zjin Fijn.

Vergelijk je website met een huis. In jouw geval heeft deze een heleboel voor- en mogelijk achterdeuren :). Wat nu als je site slechts één voordeur heeft?

Wat je ook nog kunt proberen in de aanroep van je .load() is het pad te laten beginnen met een slash (/) of, zoals Ferhat voorstelde, een volledige URL inclusief http(s)://. Dit lost echter het probleem van je relatieve verwijzingen (je requires in zo'n bestand) niet op...

Persoonlijk zou ik het "onderliggende probleem" oplossen: zorg dat als je bestanden wilt invoegen of inladen altijd een vast uitgangspunt (je document of website root) kunt gebruiken.

Misschien is het handiger als je "one point of entry" hebt in je website, oftewel, stuur alles (op wat voor manier dan ook) langs index.php, dan heb je dit soort problemen niet.

Het zou niet van toepassing zijn geweest als je dit had vermeld.