Waarom een vraag stellen als ik het antwoord al geef? I.P.V te discussiëren over wat ik wel en niet wil en waarom doet er niet toe toch?
Waarom reageer je gepikeerd op deze opmerking als je een vraag hebt van het niveau "het werkt niet" en niet aan kunt geven (onderbouwing?) waarom je deze oplossingsrichting gekozen hebt? Al gedacht aan andere oplossingen? Dedicated PHP 7 server? Of ben je enkel geïnteresseerd in een oplossing voor je directe probleem? Meedenken verboden?
Waarom wil je op twee benen (blijven) hinken? Wat werkt er niet in 5.6 wat wel werkt in 7 of andersom?
Wat @Ferhat.Remory zegt.
En dit is misschien ook een goed moment om de documentatie-site van PHP te "leren lezen".
Kijk bijvoorbeeld eens naar wat mysqli_query retourneert:
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, mysqli_query retourneert ofwel een object van de klasse mysqli_result, ofwel een boolean (true of false).
Gaan we terug naar je foutmelding:
Citaaterror Notice: Object of class mysqli_result could not be converted to int in C:\xampp\htdocs\restaurant\aanmelden.php on line 12
Omdat het een SELECT-query betrof kon hier false uitrollen indien de query was mislukt (meestal doordat deze syntax-fouten bevat), of een object van de klasse mysqli_result. Mooi, de query ging dus in ieder geval niet fout. Maar vervolgens wil je een object behandelen als een getal en het lukt PHP (terecht) niet om zelf de omzetting te doen om de vergelijking te kunnen maken.
Oftewel: de foutmelding geeft precies aan wat er mis is, en op welke regel het fout ging. Bij dit probleem was het probleem dus niet het probleem maar het interpreteren van (wat) de foutmelding (betekent). Meestal leren mensen pas programmeren wanneer ze hun eigen code moeten gaan debuggen 
.
Maar op het moment dat je deze relatie wilt updaten in de database, dus aanpassen of verwijderen, ga je dit dan doen door middel van 'WHERE auto_id = x AND dakdrager_id = x'. Waarom niet gewoon 'WHERE rel_id = x'.
En dat doe je alleen als je extra attributen hebt, zoals ik hier al aangaf:
tenzij deze relatie aanvullende informatie heeft die je apart wilt aanspreken
Anders, als relaties tussen twee of meer tabellen veranderen, is het veel makkelijker om de relaties op grond van de tabel die je als uitgangspunt neemt te verwijderen en opnieuw te inserten. In dat geval is een auto increment id nogal loos.
Mijn advies voor het koppelen van dakdragers bij auto's zou zijn een extra relatie tabel te maken. Waarin je aangeeft per row, welke dakdrager op welke auto past. Die tabel qua velden ziet er dan ongeveer zo uit.
id
dakdrager_id
auto_id
Een koppeltabel heeft geen apart id nodig tenzij deze relatie aanvullende informatie heeft die je apart wilt aanspreken, dan is zo'n id handig / gerechtvaardigd. Anders is deze gewoon niet nodig.
$query = $db->query("SELECT * FROM automodel WHERE brand_id = ".$_POST['brand_id']." AND status = 1 ORDER BY model ASC"); -Edit-
Los hiervan is dit knetter onveilig. Deze query is vatbaar voor SQL-injectie. Ook zou je voor de goede orde moeten controleren of $_POST['brand_id'] een positief geheel getal is (input filtering), dan zijn verdere controles eigenlijk overbodig maar dan zou het voor de goede orde nog steeds verstandig zijn om deze informatie te escapen in je query (output escaping).
On a side note: Als je na controle (en voor uitvoering van de query) constateert dat $_POST['brand_id'] géén positief geheel getal is dan heeft het simpelweg geen zin om ook maar te proberen deze query uit te voeren omdat dat nooit (zinnige) resultaten zal opleveren. Het is misschien verleidelijk om een typecast te doen op brand id - (int) $_POST['brand_id'] - maar dat is toch min of meer een hack... Het lijkt mij beter om je input te controleren, zoals altijd eigenlijk.
Is voor wat je nu wilt doen het extenden van classes en/of het hebben van een soort van "core" en "application" directory (laatstgenoemde directory wordt eerst gecontroleerd op classes) niet afdoende? Classes zijn van zichzelf al prima uitbreidbaar mits je je bedient van protected (en niet van final)?
En wie zou dit aan moeten kunnen passen/uit moeten kunnen breiden, en in hoeverre mag dit programmeerbaar zijn? Je zou ook gewoon hele sobere core-modules kunnen hebben, wat sowieso wel een goed idee is om je codebase een beetje klein te houden.
Je kunt code niet eindeloos abstract houden. Op een gegeven moment moet deze iets concreets doen. En dan moet je tot op zekere hoogte vastleggen hoe iets werkt en wat iets doet / kan doen m.a.w. je zult een aantal ontwerpbeslissingen moeten nemen die dit vastleggen, je offert altijd "vrijheid" op naarmate je applicatie concreter wordt (specifiekere zaken doet).
Je case is op dit moment veel te algemeen. Je wilt iets maken dat modulair is en schaalbaar met als uiteindelijk doel dat iets (onder andere?) forward compatible is. Uhm, sorry dat ik het zo zeg, maar dat is eigenlijk gewoon de manier waarop je in het algemeen (object georiënteerde) code zou moeten schrijven?
Op een gegeven moment moet je de stap abstract > concreet maken anders zal je code nooit iets concreets doen.
Wat versta jij precies onder plugins (hoe zou dit in de praktijk eruit moeten zien)? Om die vraag te kunnen beantwoorden is het ook wel handig als je weet waarvoor je de plugins precies schrijft? In wat voor behoefte voorzien deze? Er bestaat niet zoiets als een universeel programmeer recept (er zijn nu eenmaal verschillende oplossingen voor verschillende vraagstukken, is ook de reden dat er meerdere design patterns bestaan), noch zijn plugins per definitie de oplossing voor jouw specifieke probleem, wat deze ook moge zijn.
Om vast te kunnen stellen of de gekozen oplossingsrichting juist is is het misschien handig om ons te vertellen wat je precies probeert te bereiken.
Nu zeg je min of meer "ik heb een hamer gekozen, hoe moet ik deze gebruiken" terwijl de daadwerkelijke klus die je probeert uit te voeren het snoeien van de heg is.
Zoals een van de reacties op SO ook opmerkt:
CitaatI would ask for you to give more information of the nature of php app your writing, And how you see plugins fitting in.
Yep, schrijf een wrapper om cURL, dat neemt iig een hoop werk omtrent het handmatig bouwen van HTTP-requests uit handen. Ain't nobody got time fo dat.
Misschien zou je zelfs aan iets met AJAX requests via jQuery kunnen denken? Maar dat hangt een beetje af van hoe je omgaat met de API.
Waar het in ieder geval om gaat is het vinden van een makkelijke manier om GET, POST etc. requests te bouwen. De rest lijkt mij een kwestie van het volgen van de documentatie. Hopelijk is die een beetje op orde anders verzandt het al snel in het porren van een onhandelbare black box. In dat geval moet je gewoon die lui gaan platbellen en -mailen totdat ze komen met ofwel antwoorden ofwel fatsoenlijke documentatie.
Zou je los van de techniek niet eerst eens de scope vaststellen, zoals @Luc aangeeft? Ik bedoel, vervult het een specifieke wens, bijvoorbeeld voor een kookclub, of een programmeer- of schaakvereniging? Dan kun je wat je maakt een stuk beter afstemmen op je doelgroep in plaats van dat je een half CMS / generiek forum bakt. Bijvoorbeeld een nette weergave voor codefragmenten 
ingeval je een forum voor een programmeerclub maakt.
Hierin, in dat stukje waarin je je toespitst op die groep, zit dan een zekere meerwaarde. Anders, als het niet zo specifiek is, kun je zo iets beter van de plank trekken (open source).
Als het is om te oefenen, zou ik eens beginnen met eerdergenoende spec. Ontwerpen, voordat je gaat uitvoeren. Implementatiedetails (techniek of pakket) kun je naar een later stadium verhuizen, maar dit lijkt mij trouwens zeker niet offtopic.
Nog wat voer: sticky topics en verschillende indelingen voor weergave van forumberichten (platte lijsten met threads en replies zoals dit forum, of een boomstructuur waarbij je reactie-op-reactie-op-reactie kunt hebben ofzo, waarbij reacties worden ingesprongen).
ik zit momenteel in Tenerife.
Gelukkig één iemand die zijn prioriteiten op orde heeft
Dus wanneer de website af is, zoek ik een SEO expert.
Dus wanneer het huis klaar is, ga je eens over het fundament nadenken? 
Enne... Wat blijft laden? Welke resources kunnen niet geladen worden? Mogelijk een afbeelding? Of een JavaScript bestand? Die je wellicht via HTTP opvraagt in plaats van HTTPS?
Kijk eens in je netwerktab op welk(e) bestanden de browser blijft hangen. Indien DA van tabellen gebruik maakt en daar zit een afbeelding in die niet geladen kan worden dan kan de browser hier blijven steken en vervolgens de tabel(len) niet renderen.
En mogelijk is het browsercache? Heb je geprobeerd cache uit te zetten en/of de pagina te refreshen (Ctrl-F5 enzo)?
Als je een clean install doet en het probleem blijft spelen zou je eens aan de clientside kijken of daar iets aan de hand is. Al eens een andere browser geprobeerd? En welke gebruik je nu? Wellicht kun je daar op zoeken, specifiek i.c.m. de browser waarin de problemen optreden.
Ik ben zelf een systeem aan het ontwikkelen middels API's, zou voor jezelf een basis maken en vanuit hier verder werken. Zo heb je de applicatie onder eigen beheer, open-source projecten zijn vaak gevaarlijker om te gebruiken omdat men de code kan inzien en dus makkelijker kan misbruiken.
Dit klinkt paradoxaal, zijn de gebruikte API's ook opensource? 
opensource is niet per definitie goed of slecht / veilig of onveilig, maar als een heleboel mensen hier naar kijken en code wordt onderhouden dan kan dit ook tot veilige(re) en transparante(re) oplossingen leiden omdat je kunt zien dat iets goed is aangepakt. Dit is eigenlijk de tegenhanger van security through obscurity die meer in het straatje van closed source past, waar mogelijk allerlei enge dingen gebeuren in een monolithische black box. Maar ja, elk voordeel heb zijn nadelen eh :p.
(enne, ten overvloede, security through obscurity is doorgaans geen goede aanpak)
pretty much this (1 minuut Googlen).
Oftewel, zoek in de address components van je results naar entries van het type locality en kijk dan of die zelfde set een long_name of short_name heeft. Maar zoals bovenstaande link beschrijft biedt deze werkwijze (reverse geocoding) weinig garantie van slagen.
Uhm, de bovenstaande query is om op een specifieke datum te kijken of een specifieke persoon verlof heeft? Voor welk overzicht gebruik je dit? En wat wil je precies bepalen?
Voor het totaaloverzicht waarmee je de thread begon was het mogelijk handiger geweest dat voor elke dag dat iemand verlof heeft er een aparte database-entry was, maar je kunt het ook nog wel in PHP uitrekenen. Hierbij helpt het altijd om een plaatje te tekenen. Stel dat je voor een bepaalde periode (zeg tussen X en Y) wilt weten wie er verlof heeft. Er kunnen dan 3 dingen aan de hand zijn (die relevant zijn):
- de einddatum van een verlofperiode valt voor Y (en startte voor X)
- de volledige verlofperiode valt binnen X en Y
- de start van een verlofperiode start na X (en eindigt na Y)
Hier zou je dan wat mee kunnen gaan rekenen, ofwel in SQL door condities op te leggen ofwel in PHP door wat dingen uit te schrijven / uit te rekenen. Maar het hangt er helemaal vanaf wat voor overzicht je precies aan het maken bent en wat je precies wilt weergeven.
Heb je een strategie in je hoofd? Daarna is het toch gewoon een kwestie van code kloppen? Maak eerst een blauwdruk.
Wat je wilt is een tweedimensionale matrix: personeelsleden X datums.
Je hebt dus sowieso alle personeelsleden nodig. Dat lijkt mij een aparte query. Het kan namelijk voorkomen dat sommige personeelsleden geen verlof hebben (in een bepaalde periode).
Daarna ga je alle dagen van een periode (week? maand? jaar?) uitdraaien. De dagen dat personen verlof hebben zul je dan moeten markeren.
Wat je dus nodig hebt is nog een query die het verlof van personeelsleden voor een periode uitleest.
Vervolgens sla je dit op in een handige dataset, bijvoorbeeld een (genest) array verlofdatum => id's van personeelsleden. Wanneer je dan een rij van de tabel aan het weergeven bent controleer je of die datum (rij) en personeelslid (kolom) in de dataset voorkomt. Deze cel markeer je dan met "Verlof" of wat dan ook.
Zie je hoe je met het uitstippelen van een plan dit een stuk eenvoudiger wordt? Eerst bepaal je een aanpak, de rest is een kwestie van aan de molen draaien.
Afhankelijk van wat je probeert te doen zijn er andere, en mogelijk betere, oplossingen.
Indien het "inloggen.php" script controles bevat voordat toegang verleend zou mogen worden aan andere code-onderdelen dan is het wellicht beter om include te veranderen in require; wanneer een include niet slaagt wordt enkel een warning geproduceerd (waarna de code-uitvoer normaal wordt hervat) maar require produceert een fatal error wat verdere uitvoering stopzet.
Het hangt er verder natuurlijk helemaal vanaf hoe jouw pagina's zijn opgebouwd, wat jouw applicatie precies doet en hoe ver je met de materie bent.
Een potentieel gevaar met het includen-van-een-bestand-middels-een-querystring-parameter is dat het vaak ook is toegestaan om externe bestanden te includen. Dit soort bestanden kunnen gebruikt worden om lekken bloot te leggen en in te breken op jouw site. Zorg dus dat je de invoer uit $_GET valideert, of nog beter, gebruik een andere constructie waarbij er geen ruimte is voor ongewenste interpretaties.
Citaat van AaronWe hebben altijd al gezocht naar een teamlid die iets kon scripten/designen.
Dit keer doen we dit niet.
+
Citaat van AaronDit was reeds doorgegeven aan Koen. Hij kan alleen aan de code.
=
(Ook lijkt het quoten niet helemaal lekker te lopen, maar dat is bijzaak)
Wanneer de bezetting/activiteit van een crew slinkt lijkt het mij belangrijk dat meerdere personen diverse (en dezelfde) taken kunnen uitvoeren. Ik snap (en weet :p) dat voor dit soort zaken een lange adem nodig is, maar uiteindelijk is een community zo actief als haar leden ;). Geen enkele mate van inspanning van (enkel) een crew kan hier tegenop.
Positief denkend zijn
Ah well :p.
