Citaat van Digi-Expert

Ik miste een $db

Ik heb hier nog even over nagedacht, en ik denk dat dat niet kan kloppen. Als dat namelijk het geval was, dan zou $db->query() in eerste instantie stuk moeten lopen met een foutmelding als "Fatal error: Uncaught Error: Call to a member function query() on something".

Echter, de code liep vast op fetch_object() met een melding die het sterke vermoeden wekt dat je zoekquery $query (soms, maar mogelijk niet altijd) een onjuist format heeft.

Daarom blijf ik dus bij mijn eerdere conclusie op grond van de door jouw verschafte code. Misschien was je hier inmiddels mee aan het schuiven geweest, maar als je een foutmelding opgeeft die niet bij een codefragment hoort, of vice versa, dan is het vrijwel onmogelijk om op grond hiervan te zeggen wat er daadwerkelijk mis is...

Citaat van Digi-Expert

Ik begrijp niet wat er met de error bedoelt word. Kan iemand mij dat misschien uitleggen?

Een soortgelijke foutmelding wordt hier uit de doeken gedaan. PHP is eigenlijk best wel superduidelijk wat betreft foutmeldingen. Het is gewoon een kwestie van het kruimelpad volgen. En gewoon woord voor woord lezen wat er staat.

Volledigheidshalve hier ook een breedsprakige variant van de bovenstaande melding.

Er staat:

Citaat van Digi-Expert

PHP Fatal error: Uncaught Error: Call to a member function fetch_object() on boolean in regel 329.

Oftewel: in eerste optiek gaat er dus iets mis met fetch_object(). Je eerste stap zou dan ook het er bijpakken van de documentatie moeten zijn. De functie/methode verwacht een object van de klasse mysqli_result, maar kreeg in plaats hiervan een Boolse waarde (true of false).

Conclusie: de code liep dus stuk omdat de parameter niet het juiste type had.

Nu weten we dus waardoor de fout werd veroorzaakt, en pas vanaf dat moment kun je gaan werken naar een oplossing. Immers, als je niet weet wat er fout gaat, wat ben je dan aan het oplossen?

Dus, op de plek waar je een mysqli_result-object zou verwachten stond een Boolean. Hoe kan dit? $result was het resultaat van het uitvoeren van de query()-methode. We pakken de documentatie er weer bij. We zijn geïnteresseerd in het resultaat, dit staat in de functie/methode definitie:

Citaat van PHP.net

Return Values
Returns FALSE on failure. For successful SELECT, SHOW, DESCRIBE or EXPLAIN queries mysqli_query() will return a mysqli_result object. For other successful queries mysqli_query() will return TRUE.

Oftewel, of de query was geen SELECT-query, in welk geval je ook geen resultaten op kunt halen, ofwel de query was syntactisch incorrect (had niet de juiste vorm) kon niet worden uitgevoerd, bijvoorbeeld omdat deze niet juist was geformatteerd.

En om dat op te lossen, zou je je query moeten debuggen.

Het interpreteren van dit soort foutmeldingen omvat dus twee stappen:

1. lees wat er staat, en loop hier stap voor stap doorheen
2. Read The Flipping Manual

Nota Bene: de topicstarter vroeg uitleg over de foutmelding. Wat je vervolgens moet doen om deze foutmelding te doen laten verdwijnen is vers twee. Hiertoe moet je eerst weten wat er precies aan de hand is.

Dan zou je spelers als uitgangspunt moeten nemen, en dan een LEFT JOIN doen, zodat als je geen resultaten in andere tabellen vindt, je nog wel de spelers ziet, en de rest van de kolommen (die geen resultaat hebben) NULL tonen.

Misschien mis je nog wat entiteiten? Bijvoorbeeld teams, als het inderdaad teams zijn die tegen elkaar spelen. En dat evenement is een wedstrijd (team A vs team B op een bepaalde datum, tijd en locatie). En dan staan mogelijk niet al je spelers opgesteld in een opstelling voor een wedstrijd.

Het is eigenlijk zaak dat je bij het einde begint: welke informatie wil je uiteindelijk kunnen beheren (en wat wil je automatiseren, is dit tevens een planningstool voor spelers?) en op welke informatievragen wil je antwoord kunnen geven in de vorm van overzichten en rapportages? Vervolgens kijk je welke informatie je daarvoor nodig hebt en hoe je deze organiseert.

Is dit bijvoobeeld voor beheer van de eigen club of om bij te houden welke clubs er allemaal tegen elkaar spelen of wat?

Citaat van Twan025

Maar goed, om mijn SEO skills een te testen is het ook weer interessant om te kijken of ik hoog kan score op bepaalde 'hot' crypto termen in Google. En hierdoor kun je dan ook meteen bezoekers aantrekken.

Tenzij je een of andere marketingmachine hebt zou je dat kunnen proberen, maar anders is daar niet tegenop te concurreren. Dat is net zoiets als proberen nummer 1 te bereiken met een keywoord als "hypotheek" in de huizenmarkt...

In plaats van dat verloren gevecht aan te gaan kun je je energie beter steken in een strategie waarbij je je op een of andere manier kunt onderscheiden in deze markt.

Zo zou je bijvoorbeeld kunnen (proberen :p) uit te leggen wat de legitimiteit van dit betaalmiddel is, en hoe deze nu precies werkt (tot nu toe wordt er voornamelijk gepapagaaid dat dit betaalmiddel steeds breder geaccepteerd wordt en in de lift zit). Want voor sceptici zoals ik zal ik hier nooit iets mee gaan doen omdat:
- ik niet weet hoe dit werkt, en hier ook nog geen plausibele uitleg over heb gezien
- het niet gekoppeld is aan enige economie, wat ervoor zorgt dat de prijs veel teveel fluctueert wat het in wezen op voorhand ongeschikt maakt als betaalmiddel
- de waarde (dus) in feite gebaseerd is op "wat de gek ervoor geeft" (waar is de waarde op gebaseerd?)

Cryptocurrency is wat mij betreft de grootste legitieme variant van een modern piramidespel. Tot zover zijn het de gebruikers zelf die hier waarde aan toekennen (praktische toepassingen daargelaten, wellicht kun je daar wat meer over vertellen?) door zelf een soort van schaarsheid te creëren. Natuurlijk trekt dit mensen aan die gaan voor het snelle geld. Maar dat is niet hoe een economie werkt of overleeft.

Daarnaast: wat is het doel van de site: informatie verstrekken? En het publiek: startende beleggers? Als je hier mogelijk wat verder op inzoomt kun je je al onderscheiden, keerzijde is wel dat je je dan richt op een specifieke(re) club mensen.

Misschien nog een probleem: er is geen autoriteit die dit reguleert (dit wordt zelfs uitgelegd al een pluspunt?). Vergelijk dit met een festival waar je plastic fiches kunt kopen voor consumpties. Deze zijn, als je alles terugrekent, natuurlijk schreeuwend duur, maar dat is nu eenmaal het betaalmiddel op dat festival en de hoeveelheid fiches die je moet betalen voor een consumptie ligt in ieder geval vast, het is niet zo dat je ineens 5 fiches moet betalen voor een biertje in plaats van de gebruikelijke 1 of 2 fiches. Kijk je dan naar cryptocurrency. Daar zijn totaal geen grenzen en is er ook niemand die bepaalt wat het waard is behalve misschien de waan van de dag op de beursvloer.

Wellicht een uitdaging: stel als doel met je site een criticus te overtuigen van het nut en wellicht de noodzaak van deze moderne betalingsvormen, of het in ieder geval aannemelijk(er) te maken :).

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.

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

(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.

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

Is het nu opgelost?

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.

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 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?

Ook voor de toekomst is het misschien handig dat -als je toch een soort van eigen framework hebt- dat je een systeem bouwt voor het bouwen van formulieren. Dan hoef je dat maar 1x te doen. Dit scheelt je later een hoop tijd en werk. Alle componenten (formulierveld-typen) en functionaliteit (validatie, gebruiksvriendelijke foutafhandeling) heb je dan al. Je kunt na afloop daarvan razendsnel nieuwe formulieren bouwen en als je de wens hebt om complexe formulier-elementen te verzinnen en uit te werken dan kan dat ook.

Bijvoorbeeld als volgt.

De waarde (#ear-tab) moet tussen quotes. Vreemd dat deze fout in een aangekocht stuk code zit?

Je zou dus dit stukje:

if (location.hash && $(self).find('a[href=' + location.hash + ']').length > 0) {
    setActive($(self).find('a[href=' + location.hash + ']').parent());
}

Kunnen vervangen door:

if (location.hash && $(self).find('a[href="' + location.hash + '"]').length > 0) {
    setActive($(self).find('a[href="' + location.hash + '"]').parent());
}

Dit soort foutmeldingen ("selector unrecognized expression") kun je trouwens prima in de Google gooien.

Citaat van Frenzo.Brouwer

De bestanden die niet gevonden worden waren niet relevant voor deze pagina.

Zolang je niet weet waarom iets niet werkt, is het onverstandig om aan te nemen dat bepaalde zaken geen invloed hebben op je probleem.

Andere foutieve of afwezige JavaScript kan wel degelijk de werking van andere JavaScript breken.

En misschien is het iets heel simpels .

Verander dit:

<script href="includes/profielbeheer_systemen/avatar/js/script.js"></script>

Eens naar:

<script src="includes/profielbeheer_systemen/avatar/js/script.js" type="text/javascript"></script>

De server mist op de avatar pagina op dit moment in ieder geval:
/css/jquery.range.css
/js/jquery.range.js

Verder heb je meerdere divs met id "previews", dat zal sowieso niet werken.

Waarschijnlijk is het ook de bedoeling dat één tab actief is in het begin.

Maar dat lijkt ook niet te werken, mogelijk vanwege de eerdere bestanden die niet gevonden kunnen worden, dat breekt mogelijk de rest van je functionaliteit, dus repareer dat eerst.

Ik krijg deze foutmeldingen niet, maar ik kan met het test-account het uiterlijk van de avatar niet veranderen. Ook lijkt het schakelen tussen de selecties van de verschillende gezichtsdelen niet te werken.

Zie de developer console, waarschijnlijk incompatibele versies:

Citaat

Uncaught Error: Bootstrap's JavaScript requires jQuery version 1.9.1 or higher, but lower than version 3

Het heeft geen zin om dingen verder te analyseren als je weet dat er zaken breken. Repareer eerst deze zaken en kijk dan of de problemen nog optreden.

Citaat van Ferhat.Remory

Zet het dan even open voor het Gast account. Niet iedereen gaat zich aanmelden om iets na te kijken..

Pretty much this. Heb je toevallig een gast- of testaccount wat hiervoor gebruikt kan worden?

Ik ga er van uit dat dit ook PHP-code betreft, dus om nu aan de buitenkant te kijken wat er misgaat vertelt ons waarschijnlijk ook niet alles.

Aangezien het een betaald script is heeft dit wel enige kwaliteit neem ik aan of kan deze verkeren, heb nooit iets met codecanyon gedaan.

Waar gaat het precies mis? Wat verwacht je dat de functionaliteit (zou) moet(en) doen, maar lijkt dat niet te doen? Heb je al gekeken of anderen soortgelijke problemen hebben? De meeste programmeerproblemen zijn immers niet uniek.

Wat nu als je de zoekmachines een zoekmachinevriendelijke variant van de content serveert... oh wait