Citaat van MBCompany

RewriteRule ^([a-zA-Z]+)\.html$ index.php?page=$1

Waarom doet iedereen dat toch?

Daarmee reserveer je effectief $_GET['page'] voor rewrite-doeleinden en "vervuil" je in zekere zin je $_GET namespace.

Je zou ook alles wat geen concreet bestand of directory is kunnen doorsturen naar index.php en dan met behulp van $_SERVER['REQUEST_URI'] en parse_url() bepalen welke pagina je probeerde te laden.

Voordelen van deze methode zijn:
- veel schonere .htaccess file
- je kunt $_GET weer op een volledig natuurlijke manier gebruiken, er zijn geen "gereserveerde" variabelen

Meh, je zou het ook met een subquery kunnen oplossen:

SELECT ...
FROM conversations c, messages m
WHERE messages.id = (SELECT MAX(id) FROM messages WHERE conversationId = c.id)
AND ...
ORDER BY c.favourite, m.id DESC
LIMIT 0, 30

Er vanuitgaande dat er een messages.id kolom is. Moet je trouwens niet ook aflopend sorteren op c.favourite? Eerst de favoriete conversaties, dan de normale?

Sorteren kan ook op id, immers, de reactionDates volgen dezelfde sortering als id's (een reactie die later gegeven heeft heeft zowel een hoger id als een latere datum).

Mogelijk moet je nog kijken naar indexen (bijvoorbeeld op messages.conversationId, als je niet al van foreign keys gebruik maakt, in welk geval er al automatisch geindexeerd wordt) om de query efficient te houden.

Een makkelijke manier is denk ik om bij een conversatie bij te houden wat de laatste reactie (het laatste reactie-id) is.

Je slaat dan weliswaar redundante (afleidbare) informatie op, maar je queries worden dan volgens mij een stuk simpeler :). In dat geval kun je via een simpele INNER JOIN meteen de juiste message.reaction ophalen.

... dat interpunction dough...

Wat voor systeem gebruik je (platform, webservertype, PHP versie en databasetype en -versie)?
Heb je de installatiestappen gevolgd?
Welke foutmeldingen krijg je?
Wat heb je geprobeerd?

Ah ik denk al, wat is een powerline, maar dat is dus (more commonly known as?) een HomePlug?

Oftewel, je had voorheen een draadloos netwerk met slechte ontvangst, en nu is je aangeraden om een vaste verbinding te gebruiken via je elektriciteitsnetwerk?

Ik weet niet precies wat het probleem is (de probleemomschrijving mocht ook wel iets duidelijker) maar in deze tijd zou alles toch redelijk plug-and-play moeten zijn. Als je de router kunt bereiken zou je op internet moeten kunnen?

Teken anders eens een plaatje:

[apparaat]--draadloos/UTP-kabel--[homeplug]--elektriciteitsnet--[homeplug]--UTP-kabel--[modem]--[the internets]

Waar stokt de communicatie vanuit je apparaat precies?
Krijg je een IP van je HomePlug / je router?

Ik heb verder geen ervaring met HomePlugs maar volgens mij was het belangrijkste dat je deze rechtstreeks in een stopcontact steekt, en dus niet in een stekkerdoos.

Verder lijkt mij dit een probleem wat door eliminatie van mogelijkheden opgelost kan worden, te beginnen met het inperken van het probleemgebied (waar gaat het precies fout).

Is het de bedoeling dat dit spel via een netwerk gespeeld wordt (en dus in feite een gedistribueerd systeem is) of zit iedereen achter dezelfde computer?

Dit bepaalt namelijk nogal in verregaande mate de architectuur van je spel. Als iedereen achter dezelfde computer zit dan hoef je ook geen login te hebben voor gebruikers, je zit toch bij elkaar.

Ook zou ik wat meer gaan denken hoe je het spel speelt. Even er vanuitgaande dat je allemaal knus achter dezelfde computer zit lijkt mij de eerste stap het starten van een nieuw spel. Dit omvat het vaststellen van het aantal deelnemers, eventueel de namen en een kleurtje die zij kunnen kiezen.

Daarna is het een "loop" van spelersbeurten waarbij er gedobbeld wordt. Je zou dit spel volautomatisch kunnen laten lopen, maar dan is er niet zoveel leuks aan. Mogelijk kun je een sort van interactie met muis / toetsenbord hebben zodat je op die manier de dobbelsteen schudt en gooit ofzo?

En dan is daar de "eindiging" van het spel. Wanneer houdt deze op? Wanneer de eerste persoon het doel bereikt. Ook moet je even kijken wat er gebeurt als je niet uitkomt met het gegooide aantal ogen (ik weet al niet meer wat voor mogelijkheden je dan allemaal had, mocht je ook terug dan?). Of moeten alle spelers "binnen" zijn om het spel te laten beeindigen.

Dan zou je nog kunnen denken aan het voortijdig afbreken van het spel, of het opslaan van de toestand zodat je op een ander moment kunt verder spelen.

Als de basis er is zou je kunnen gaan nadenken over hoe je het spel verder aankleedt. Hadden de vakjes van ganzenbord niet ook speciale velden? Dat je in 1x af bent, X vakken vooruit gaat, of Y achteruit, of een beurt overslaan, dat soort dingen?

En dan kun je nog verschillende speelborden ontwerpen waar je uit kunt kiezen als je het spel start, of dat je een compleet random bord laat genereren.

Ik denk dat de truuk is dat je in eerste instantie nadenkt over wat je wilt kunnen doen, en dan pas kijkt naar het hoe. Hoe je je database en code op zet volgt namelijk vrij logisch uit wat je wilt kunnen doen.

Draai het dus om als je begrijpt wat ik bedoel.

Citaat van Tim

Deze kunnen wij niet zonder kennis van jouw broncode achterhalen.

En zelfs dan misschien niet. Zelfs wanneer je deze tabel weer uit de doden opwekt zijn er mogelijk nog andere tabellen, en werken tabellen mogelijk samen doordat hier verbanden tussen bestaan.

Het lijkt mij een foutgevoelige manier om je database op die manier te "herstellen". Het klinkt alsof je een site gemigreerd hebt zonder de database mee te nemen. Dat of de installatie is mislukt / je hebt de stappen niet juist of niet volledig doorlopen.

En wat Tim zegt, als je er niet bijvertelt om wat voor applicatie / product het gaat blijft het voor ons ook gissen.

Ik weet niet of dit inmiddels is veranderd in de API, maar als ik van deze vraag / dit antwoord uit mag gaan, dan (is zo'n extra voorziening er niet maar) kun je dit oplossen via een workaround door de plaatsnaam op een of andere manier aan de zoekterm te plakken.

If you have tags like <script> and HTML breaking your application this means you are not escaping output.

Also, if you want to have access to a more exotic range of characters this means your entire application must be able to handle UTF-8 or a similar character encoding.

Given the sample you posted on the first page, I think it is better to completely rewrite this, I am not sure if a file-based approach is a good idea, it is probably better to use a database for storing data.

And then there is the way HTTP works: this is a request-response chess game. It is probably not the best protocol for something like a chat to begin with. You will need to have some kind of polling mechanism which checks if there are new messages unless you fancy refreshing your webpage manually all the time.

I mean, have you considered IRC? This is a protocol specifically designed for chat. Or other technologies which also might be better suited for chat than HTML, for that matter.

Wijkt dit niet af van je oorspronkelijke vraagstelling, daar heb je het wel over een database?

Ik begrijp het niet helemaal meer? Speelt het oorspronkelijke probleem nog of is er een ander probleem?

Ik denk dat we hier met zijn allen proberen dit soort vraagstukken op te lossen, of andere en mogelijk betere werkwijzen aan te dragen, maar die moeten dan wel gebaseerd zijn op een kloppend verhaal, anders gaan we niet van eenzelfde uitgangspunt uit en sluiten de adviezen hier niet bij aan...

Dus eh... Geef ff opnieuw een situatieschets en vertel daarbij wat het probleem precies is - als er uberhaupt nog een probleem speelt.

Simpelweg omdat iets juist wordt weergegeven wil niet zeggen dat iets juist is opgeslagen.

MySQL is redelijk intelligent als het gaat om vertalingen tussen verschillende character encoderingen dus het kan zijn dat daarom alles op dit moment goed getoond wordt... totdat je je CE van je document / je database-connectie een keer instelt.

Het afwezig zijn van een CE-aanduiding in je Content-Type header van je JSON-response was mijn voornaamste aanleiding om hierop te reageren, naast de wat rare opzet van deze JSON-response dus... Dit zou wat mij betreft gewoon text/html moeten zijn (met CE) omdat het HTML is, geen JSON.

Ik zou zeggen, denk er nog eens over na en controleer via je browser developer tools eens wat je CE van je document / AJAX response is en controleer of je een _set_charset() functie aanroept bij het maken van je database-connectie...

EDIT: en het is dus beter om overal expliciet een "charset" in te stellen in je header()s.

Uhm, waarom retourneer je HTML als JSON :/.

Doe (bij voorkeur) een van de twee volgende dingen:
- retourneer het gewoon als HTML; als je een AJAX-call doet via jQuery kun je een "hint" meegeven over het te verwachten reponstype (dataType, met als waarde json of html)

of, wellicht beter,
- retourneer alleen relevante data als JSON, en genereer de HTML in je callback-functie

Voordeel van de laatste methode is dat er veel minder data over de lijn gaat.

Ik zou je afraden om in MySQLi over te stappen naar prepared statements. Dit is namelijk nogal ... ruk. Daarnaast heeft het geen enkele toegevoegde waarde en wordt alles mogelijk trager.

Prepared statements in MySQLi zijn namelijk "echte" native prepared statements in-the-MySQL-sense-of-the-word, oftewel, elke SELECT-query resulteert in het daadwerkelijk uitvoeren van TWEE queries (1x voor de prepare, 1x voor de execute). En dan is de syntax van prepared statements in MySQLi nogal omslachtig.

Dan nog iets heel anders: in alle discussies over het escapen van DATA heb je altijd te maken met een CONTEXT (HTML, SQL, et cetera) maar wat nogal eens altijd wordt vergeten is dat al die escaping functionaliteit alleen goed werkt als je op de correcte manier omspringt met je character encoderingen.

Heb je bijvoorbeeld al gedacht aan de character encoding (CE) van:
- je code-bestanden zelf, met welke CE zijn je PHP/HTML/etc-bestanden opgeslagen (wellicht minder doorslaggevend qua security, maar daarom niet minder belangrijk)
- het gegenereerde HTML-document middels meta tag of PHP-header()
- de connectie met je database middels een set_charset() functie
- de CE van je tabellen
- de CE waarmee de data in deze tabellen (daadwerkelijk) is opgeslagen?

Ook in de Content-Type header van je JSON-respons zie ik geen CE aanduiding...

Kun je bijvoorbeeld het volgende stukje goed tonen/transporteren:

Citaat

A good day, World!
Schönen Tag, Welt!
Une bonne journée, tout le monde!
يوم جيد، العالم
좋은 일, 세계!
Một ngày tốt lành, thế giới!
こんにちは、世界！

Toon Meer

?

Het is meestal beter om een whitelist te hanteren (definieer wat je toestaat) in plaats van een blacklist (definieer wat je verbiedt). Als je namelijk in de laatste variant een geval vergeet... ben je nat.

Daarnaast hoop ik dat je, als je je bezig houdt met functionaliteit als een forum (en dus met USER INPUT), je veel aandacht besteedt aan veiligheid / de beveiliging.

Ben je je bijvoorbeeld bewust van (het belang van):
- character encoderingen
- een kloppend HTML-document
- (input filtering en) output escaping
?

Ik weet niet hoe uitgebreid die PriceWatch API is maar hetgeen je wilt bouwen klinkt haast als een soort van kennissysteem.

Naast het simpelweg binnenhalen van de "rauwe" hardware-data zul je ook een hoop dataverrijking moeten doen, want als een moederbord bijvoorbeeld een Socket 1150 processor socket heeft, dan heeft dit consequenties voor welke processoren hier op passen.

Ik neem aan dat je enkel PC's wilt kunnen samenstellen die je ook aan kunt zetten en dat ze dan wat doen?

Hetzelfde geldt het aantal en type PCI Express sloten (dit bepaalt welke en hoeveel videokaarten je hier op kunt prikken), en zo ook voor het geheugen en andere randapparatuur et cetera.

En naast deze "hardwarecompatibiliteitsregels" zou je je systeem ook nog kunnen verrijken met (naast "prijs") andere "dimensies" zoals toepassingsgebied (videobewerking, tekstverwerking, gaming, grafisch design, iets anders) die je als een soort van "geschiktheidssscore" koppelt aan stukken hardware. En misschien kun je nog hele andere invalshoeken bedenken waarop je systemen samenstelt.

Dus voordat je uberhaupt gaat denken over technische oplossingen denk ik dat je wel even zoet bent met het uitdenken van hoe dat systeem in eerste instantie functioneel zou moeten gaan werken.

Kun je je in nginx niet bedienen van dezelfde strategie als .htaccess / apache?

Vraag je een bestaand bestand / bestaande directory op (denk aan css, javascript maar ook standalone php scripts): serveer maar.

Stuur al het overige door naar index.php (alwaar je met $_SERVER['REQUEST_URI'] bepaalt welke pagina je opvroeg en "bereken" je of deze pagina bestaat.

Dat lijkt mij veel eenvoudiger en intuitiever dan een of meer blacklists en allerlei specifieke regels.

En hierbij is het helemaal handig als je dus je applicatie-code buiten je webdirectory zet zodat je geen "botsingen" krijgt tussen de namen van scripts en URLs die je aanroept. Zet enkel in je webdirectory wat je wil uitvoeren (index.php en standalone scripts, en misschien een soort van algemeen config-bestand waarin de paden van je applicatie zitten enzo).

Hm, maar als je er al jaren mee bezig bent, dan heb je ondertussen toch al een beetje je weg gevonden binnen PHP?

Ben je op zoek naar een opfriscursus of meer een soort van introductie tot gevorderde thema's?

Mogelijk zou je kunnen kiezen voor een pakket (ik noem maar een dwarsstraat: wordpress) of framework (laravel, symfony) wat je eens nader bestudeert, al was het maar om een kijkje in de keuken te nemen bij wat grotere producten. Je zou dan kunnen kijken naar aanpak/organisatie in code en de manier waarop je functionaliteit/extensies bouwt ofzo.

Of wil je zelf je eigen dingen in elkaar blijven zetten (is ook nuttig/leerzaam). Wat zou je willen (kunnen) bouwen?

Heh, die LOI-cursus:

Citaat van LOI

De opleiding is speciaal toegespitst op PHP versie 6.

Cool :).

Verder klinkt dat toch een beetje als een crash course voor de beginner.

Misschien is het handig als je aangeeft of je hier al iets (en wat) van afweet? HTML? CSS? JavaScript? Webtechnieken? Andere programmeertalen? Wat is je technische achtergrond? Heb je hobbymatige ervaring? Oftewel: wat is je instapniveau?

Daarnaast is het wellicht ook handig als je aangeeft wat je hiermee hoopt te kunnen gaan doen (wat je mogelijk nu nog niet kan).

Dan stuurt deze cursus toch een beetje aan op (simpele) dingen zelf maken. Terwijl, afhankelijk van wat je na afloop wilt kunnen (maken), het misschien wel verstandiger is om een van de vele standaard (gespecialiseerde) pakketten of frameworks te gebruiken of aan te schaffen in plaats van je eigen wiel uit te vinden. Oftewel: wat wil je na afloop kunnen?

En tot slot, als je je om/bij laat scholen tot een soort van programmeur is het een pre als je een nette werkhouding hebt en in abstracte concepten kunt denken, met andere woorden, je gedachten enigszins kunt structureren en met een zekere analytische kijk kunt redeneren over code/programmastructuren. Oftewel: kun je denken in abstracte concepten?

Oh, en het moet je natuurlijk ook een beetje aanspreken. Ik weet niet of "Het wordt voor mij betaald" een hele sterke motivatie is :). Oftewel: wat is je motivatie?

Tot slot #2:
"Werken met PHP" gaat veel verder dan PHP alleen: je zit met je ontwikkelomgeving (IDE) en andere applicaties (denk aan een versiebeheersysteem, een bug trackingsysteem, een projectsysteem, etc.), de daaromheen liggende technieken (HTML, XML, CSS, JavaScript (oa JSON), MySQL, webservices etc.), beheer van de verschillende web-omgevingen (stukje systeenbeheer) - mogelijk ben je maar 50% van de tijd (en mogelijk minder) van de tijd daadwerkelijk code aan het kloppen...

Tot slot #3:
De beste manier om een taal te leren (in zijn algemeenheid) is volgens mij nog door hem vaak te spreken en vele, vele voorbeelden en concepten te bestuderen. Het is dus vooral leren door te doen. PHP-land (en de IT-wereld) is ook continu in beweging dus het is ook een kwestie van dingen bijhouden.

Weet waar je aan begint :).

Meh, in een poging om niet meerdere keren allemaal dezelfde dingen op te schrijven is het in dit geval een beetje gebackfired. Daarbij zijn niet alle opmerkingen hier ook van toepassing (vandaar "in grote lijnen").

Het loginscript waar ik naar verwees maakt gebruik van cookies. De user class hier... goochelt met sessievars, ik kan in eerste oogopslag niet echt overzien wat er gebeurt. De __construct methode van een user object lijkt mij iig te lang / te complex.

Ik zie geen documentatie voor initieel gebruik, of een SQL-bestand voor de creatie van tabellen (mogelijk heb ik deze over het hoofd gezien?). En ook geen notities over eventuele minimale PHP/MySQL versies i.v.m. compatibiliteit.

Voor de rest is hier *in grote lijnen* hetzelfde aan de hand als bij het script waar ik naar verwees:
- geen expliciete character encoding (bijvoorbeeld in je database connectie, het escapen van output is nog niet geimplementeerd, mogelijk regelt twig dit?)
- geen "one point of entry" wat voor een beter overzicht / betere security kan zorgen
- het ontbreken van een soortement van autoloader
- het gebruik van "global" in classes (is een beetje "not done" in OOP)
- geen opdeling van "acties" in logische eenheden of "acties" in verkeerde class

En dan iets wat ik keer op keer zie (en niet alleen hier):

<?php
if ($someSecurityCheck === false) {
    // security check failed, user should not be here
    header('Location: elsewhere.php');
}
// SOME IMPORTANT OR SENSITIVE CODE
// ...
?>

headers worden pas verstuurd vlak voordat er output wordt geproduceerd. Stel dat een niet-geauthoriseerd persoon deze pagina bezoekt, dit is wat er achtereenvolgens gebeurt:

1. check levert false op, we stappen het if-statement in
2. er wordt een (HTTP) header geset
3. *** // SOME IMPORTANT OR SENSITIVE CODE wordt uitgevoerd ***
4. einde script, headers + output worden verstuurd en je wordt effectief geredirect

De misvatting is nog altijd dat header('Location: ...') je direct transporteert naar een andere locatie, en dat klopt nog altijd niet. Als je dit zo wilt laten werken, zorg dan dat je altijd een exit; statement laat volgen op deze header() call. Of mogelijk beter: maak een redirect() functie of methode waarin je deze twee statements (header + exit) samenneemt, zodat je dit nooit vergeet.

(EDIT: ik durf te wedden dat sommige lezers nu naarstig op zoek gaan naar dit soort passages LOL)

Daarnaast (en dit voert wellicht wat verder dan de scope van dit project) zit er (nog) geen fancy URL's en/of een soort van rechtenmanagement (Access Control List of equivalent) in.

Mogelijk is dat op dit moment nog niet begroot in je project, maar iets om wellicht wel rekening mee te houden in de toekomst, oftewel, is je ontwerp ook zodanig dat deze nog verder uitgebouwd kan worden?

Als ik de code vlug bekijk zou je in grote lijnen de aantekeningen bij dit loginscript kunnen bekijken / volgen.

Citaat van webDev

dit kan je oplossen door `from` te doen

Dit kun je ook voorkomen door een handigere naam te kiezen. Je zou ook kunnen gaat voor een variant waarbij je alle kolommen voorziet van een unieke prefix, bijvoorbeeld wh_from. In beide gevallen hoef je geen backticks te gebruiken.

Tenzij je overal consequent backticks omheen zet (wat nogal bewerkelijk is en de query slechter leesbaar maakt) zou ik (alleen al) in het kader van uniformiteit (en tis gewoon verdomd onpraktisch) dit probleem gewoon op voorhand uit de weg gaan.

Tevens: /offtopic