Ik kijk in mijn glazen bol... en deze is troebel :).

Waarschijnlijk gaat er in dat script iets mis. Check je errorlogs.

Maakt het class-bestand ook een object van die class aan? Dat is nogal ongebruikelijk? Een class-bestand zou eigenlijk van zichzelf niets moeten "doen". Ook wil je dat soort includes waarschijnlijk niet in je webdirectory hebben staan? Ik kan nu rechtstreeks /include/database.class.php aanroepen, die elke keer ook meteen een connectie opzet? Mooie manier om je site lam te leggen :).

EDIT: en dat ding laden kost ~220ms, wat doe je daar allemaal?!

Hoe ziet de code voor query() er uit? Want die volgt niet echt de aanpak van PDO noch van MySQLi?

Ook doe je er verstandig aan om een JSON-result goede headers te geven.

EDIT: als deze $_POST data verwacht, moet je hier misschien ook op controleren. Alsmede andere instellingen zoals cookies enzo. Voordat je wat dan ook probeert te doen.

EDIT: je zou ook ff debugging aan kunnen proberen te zetten:

<?php
// zet dit bovenaan je script
ini_set('display_errors', 'stdout');
ini_set('display_startup_errors', true);
error_reporting(E_ALL);
?>

Maar als dat niet werkt zul je je logs moeten checken.

Enne... Ben je live aan het ontwikkelen ofzo?

Citaat van FangorN

Ik kijk in mijn glazen bol... en deze is troebel :).

Waarschijnlijk gaat er in dat script iets mis. Check je errorlogs.

Maakt het class-bestand ook een object van die class aan? Dat is nogal ongebruikelijk? Een class-bestand zou eigenlijk van zichzelf niets moeten "doen". Ook wil je dat soort includes waarschijnlijk niet in je webdirectory hebben staan? Ik kan nu rechtstreeks /include/database.class.php aanroepen, die elke keer ook meteen een connectie opzet? Mooie manier om je site lam te leggen :).

EDIT: en dat ding laden kost ~220ms, wat doe je daar allemaal?!

Hoe ziet de code voor query() er uit? Want die volgt niet echt de aanpak van PDO noch van MySQLi?

Ook doe je er verstandig aan om een JSON-result goede headers te geven.

EDIT: als deze $_POST data verwacht, moet je hier misschien ook op controleren. Alsmede andere instellingen zoals cookies enzo. Voordat je wat dan ook probeert te doen.

EDIT: je zou ook ff debugging aan kunnen proberen te zetten:

PHP

<?php
// zet dit bovenaan je script
ini_set('display_errors', 'stdout');
ini_set('display_startup_errors', true);
error_reporting(E_ALL);
?>

Maar als dat niet werkt zul je je logs moeten checken.

Enne... Ben je live aan het ontwikkelen ofzo?

Toon Meer

Aanvulling i.v.m. reports;
Ik gebruik

ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
error_reporting(E_ALL);

Werkt voor mij altijd, ook met een 500 foutmelding.

Betreft zijn $db-query zal het van een class komen.
Gelijk een Mysqli of PDO wrapper. Voorbeeldje : https://github.com/ThingEngineer/PHP-MySQLi-Database-Class

Citaat van Ferhat.Remory

Ik gebruik

ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
error_reporting(E_ALL);Werkt voor mij altijd, ook met een 500 foutmelding.

De waarde van de display_errors setting is al een tijdje geen boolean meer. En soms hapert een script zodanig dat je toch enkel een error 500 pagina ziet (en ligt het buiten je controle om dit gedrag anders in te stellen), in welk geval je toch in de logs zult moeten duiken. Jouw snippet en die van mij doen effectief waarschijnlijk hetzelfde.

Citaat van Ferhat.Remory

Gelijk een Mysqli of PDO wrapper. Voorbeeldje : github.com/ThingEngineer/PHP-MySQLi-Database-Class

Wow, dat is wel erg veel code voor iets redelijk simpels. Als je er over nadenkt is dat ook een grappig ding, immers, deze extend niet van een of andere abstracte database-class of interface die deze class implementeert, maar je hebt wel een complete abstractielaag... specifiek voor MySQLi? Zie je de contradictie hier? Wat is het punt daarvan dan?

EDIT: okay, toegegeven, die class kan heel veel. Maar vraag jezelf in alle eerlijkheid af. Bij normaal gebruik van een database, hoeveel van die code zul je dan gebruiken? En zou je dan al die code in één class moeten stampen?

Ik gaf maar een voorbeeld op je vraag waarom hij dat als query gebruikte. Maar inderdaad, het is veel code

Citaat van Ferhat.Remory

Ik gaf maar een voorbeeld op je vraag waarom hij dat als query gebruikte. Maar inderdaad, het is veel code

Dat begrijp ik, maar de topicstarter moet wat meer duidelijkheid geven over het hoe en wat. Hij geeft ons een halve puzzel en dan is het moeilijk om een voorstelling te maken van het complete plaatje. Natuurlijk is dit een class of library die hij gebruikt, maar hier weet ik inhoudelijk niets van, dus doe ik hier ook geen aannames over, ik zeg alleen "ik ken deze aanroep niet, vertel hier eens wat over", of spoor in ieder geval aan op verduidelijking.

Dit is ook eigenlijk weer zo'n vraagstuk waarbij het probleem niet echt het probleem is, maar meer de aanpak van het probleem. In dit geval is het gewoon zaak dat je weet/uitzoekt wat de foutmelding is. Het "probleem" hier is dus informatie-vergaring, als dat eenmaal is opgelost (door te weten waar je moet kijken of hoe je dit kunt debuggen) dan is het wegwerken van de interne serverfout waarschijnlijk triviaal. Het probleem hier is dus het gebrek aan een strategie om duidelijk te krijgen wat er precies fout gaat, en (voor nu, in ieder geval :)) niet de daadwerkelijke fout zelf.

moet wel of je plaatst het niet goed

De pagina geeft inmiddels een 200 OK status dus wss heeft ie al wat gewijzigd.

Is het nu opgelost?

1 little thing;
mag je dit wel in cookie opslaan?

1. $HTTP_USER_AGENT = $_COOKIE['HTTP_USER_AGENT'];
2. $hostname = $_COOKIE['hostname'];

(En ook IP?)
"Mogen" in welke zin? Juridisch? Of technisch?

Het heeft in ieder geval weinig zin. Elke page-access is deze informatie beschikbaar via $_SERVER, waarom zou je dat apart in cookies bijhouden? Daarnaast zijn dit HTTP_-variabelen, en dus niet heel erg betrouwbaar. Cookies zijn ook manipuleerbaar, dus, afhankelijk van verdere code, maakt het dit makkelijker om je voor te doen als iemand die je niet bent? Lijkt mij een hoop boekhouding voor niets inderdaad.

Tenzij de TS onze gegevens aan het verzamelen is :s.

Toch fijn dat de topicstarter ff laat weten wat de status is.

Citaat van Frenzo.Brouwer

Daarnaast wil ik een digitaal vinger afdruk maken om rechtsgeldige overeenkomsten te kunnen maken voor bedrijven. Heb inmiddels de cookies verwijderd en aangepast naar $_SERVER. Loop alleen vast op het weergeven van de succesmelding.

Ik kan op dit moment niet meer in het oorspronkelijke document ("Helaas! U heeft geen rechten om dit document in te zien!") dus kan niet zien wat je hiermee bedoelt. Het is in ieder geval niet nodig om deze gegevens over te hevelen naar het script want al deze informatie kun je rechtstreeks in dat script opvragen.

Het is in wezen simpel: je doet een AJAX-call en roept daarmee een script aan dat een aantal handelingen verricht. Na afloop kun je een status terugmelden. Deze status (response) kun je gebruiken om te bepalen wat er gebeurt. Als alle handelingen zijn geslaagd geef je een "succes" status terug, anders een "mislukt" status.

Citaat van Frenzo.Brouwer

Het zou ook goed zijn als de pagina na het uitvoeren van de ajax call naar een andere pagina wordt door verwezen zoals index.php?page=getekend&id=3 Dat zou ook makkelijk zijn voor het afhandelen van de procedure

Dat lijk mij niet direct nodig, je maakt immers gebruik van AJAX dus je kunt interactief delen van een pagina verversen. Daar zou je dus (na de "succes" status van hierboven) ook een tekst + linkje kunnen presenteren om weg te navigeren, bijvoorbeeld naar een pagina waar je een eigen kopie van het document kunt opvragen. Als het ondertekenen is geslaagd zou je dit ook onklaar kunnen maken om verder duidelijk te maken dat de gebruiker klaar is.