[PHP/(My)SQL] voor dummies #117

Eerst een tip: gebruik de [php] en [/php] tags voor php, in plaats van [code] en [/code].

Tweede tip, als je died, dan hoef je geen else meer te gebruiken, dan heb je minder levels van indentation en das fijner om te lezen.
Derde tip, maak er functies van ipv losse files voor een functie. En maak er een klasse van.

Ga ik effe editten!

Heb t ge-edit, stond ook perongeluk 2x de zelfde code's

Maaru, even.. Heb het e.e.a geedit aan dit script, maar t meeste is copypaste werk.

Dat als ik die, dat ik geen else meer hoef te gebruiken ga ik even fixen, maar dat stukje functies, zou iemand daar mee me opweg kunnen helpen?

Zo ver was ik ook nog :p

Ja, het ID komt in de database voor, dat is het probleem.

quote:

Op zaterdag 16 augustus 2014 11:44 schreef Djurres het volgende:
Zo ver was ik ook nog :p

Ja, het ID komt in de database voor, dat is het probleem.

Dus de query slaagt en het aantal resultaten is niet 1. Hoeveel resultaten zijn er dan wel?
En weet je zeker dat je met de goede database verbindt, en dat er niet nog een andere database is waar dezelfde tabel in staat zonder het gezochte id?

quote:

Op zaterdag 16 augustus 2014 12:02 schreef Light het volgende:

[..]

Dus de query slaagt en het aantal resultaten is niet 1. Hoeveel resultaten zijn er dan wel?
En weet je zeker dat je met de goede database verbindt, en dat er niet nog een andere database is waar dezelfde tabel in staat zonder het gezochte id?

Even korte uitleg, het systeem is voor een X aantal comissies binnen een vereniging. De bedoeling is dat men de notulen hier upload zodat alles openbaar word voor alle commissies binnen de vereniging.

Om deze niet door elkaar te halen, heb ik meerdere tables binnen 1 db aangemaakt, voor iedere commissie, een table.

Na gecontroleerd te hebben of dit klopt, klopt dit allemaal. Ik heb namelijk ook een scriptje die de laatste 3 geuploadde notulen laat zien. Heb in iedere afdeling even een apart bestandje geupload, en wat me opvalt is dat als er 1 bestandje in staat, dat ik hem kan downloaden, alleen word er een verkeerde extensie mee gegeven. (zo ziet ie .doc als een .exe bestand oid.) Bij een .txt. of .pdf is er niets aan de hand.

Op het moment dat ik MEERDERE bestanden in de db heb staan kan hij de id's niet meer terug vinden, en krijg ik dus geen download.

quote:

Op zaterdag 16 augustus 2014 16:08 schreef totalvamp het volgende:

[..]

Klinkt alsof je het niet goed hebt opgelost. 3 aparte tabellen is sowieso niet nodig. Je kunt afdelingen makkelijk scheiden aan de hand van een id.

Voorderest lastog te helpen zonder code

Dat. En bestanden opslaan in de database is eigenlijk nooit een goed idee. Bestanden kunnen prima door een file system worden opgeslagen (die is daarvoor), zolang je het maar buiten de webroot doet. Dan hoef je in de db alleen op te slaan wat je als naam hebt gebruikt. De locatie is iets dat gewoon geconfigureerd kan worden en in code hoort.

quote:

Op zaterdag 16 augustus 2014 17:35 schreef Light het volgende:

[..]

Dat. En bestanden opslaan in de database is eigenlijk nooit een goed idee. Bestanden kunnen prima door een file system worden opgeslagen (die is daarvoor), zolang je het maar buiten de webroot doet. Dan hoef je in de db alleen op te slaan wat je als naam hebt gebruikt. De locatie is iets dat gewoon geconfigureerd kan worden en in code hoort.

En dat is het probleem, ik heb nergens geen ruimte buiten de webroot, dus vandaar in de DB. Nu komen er geen spannende dingen in te staan maar het moet natuurlijk wel veilig blijven,

Code staat een pagina terug

quote:

Op zaterdag 16 augustus 2014 16:08 schreef totalvamp het volgende:

[..]

Klinkt alsof je het niet goed hebt opgelost. 3 aparte tabellen is sowieso niet nodig. Je kunt afdelingen makkelijk scheiden aan de hand van een id.

Voorderest lastog te helpen zonder code

Code staat een pagina hiervoor

quote:

Op zaterdag 16 augustus 2014 17:38 schreef Djurres het volgende:

[..]

En dat is het probleem, ik heb nergens geen ruimte buiten de webroot, dus vandaar in de DB. Nu komen er geen spannende dingen in te staan maar het moet natuurlijk wel veilig blijven,

Code staat een pagina terug

[..]

Code staat een pagina hiervoor

zelfs shared-hosting heeft vaak een public_html ( achtige ), met daaronder een mapje waar je domein staat, hier kun je best een mapje in donderen :-)

Verder kun je bijvoorbeeld afbeeldingen die toch al publiekelijk beschikbaar moeten zijn natuurlijk gewoon in de public folders kieperen.

let wel, dat je je configuratie bestanden niet zomaar van buiten beschikbaar maakt.

je zou even kunnen kijken naar htaccess, daarmee zou je eventueel ook het probleem van folders op kunnen lossen door ze te 'verbieden' ;-)

quote:

Op zaterdag 16 augustus 2014 18:48 schreef amvrosios het volgende:

[..]

zelfs shared-hosting heeft vaak een public_html ( achtige ), met daaronder een mapje waar je domein staat, hier kun je best een mapje in donderen :-)

Verder kun je bijvoorbeeld afbeeldingen die toch al publiekelijk beschikbaar moeten zijn natuurlijk gewoon in de public folders kieperen.

let wel, dat je je configuratie bestanden niet zomaar van buiten beschikbaar maakt.

je zou even kunnen kijken naar htaccess, daarmee zou je eventueel ook het probleem van folders op kunnen lossen door ze te 'verbieden' ;-)

Ah, okay.

Maar, kan je me uitleggen waarom je dit beter niet in een database kan zetten? Hack gevoelig?

Ik heb namelijk cookiestealing, xss geprobeerd, en
mysql injection geprobeert op onderandere de get_page?id=4 enzo, heb nergens een leak of gat gevonden..

quote:

Op zondag 17 augustus 2014 11:15 schreef Djurres het volgende:

[..]

Ah, okay.

Maar, kan je me uitleggen waarom je dit beter niet in een database kan zetten? Hack gevoelig?

Ik heb namelijk cookiestealing, xss geprobeerd, en
mysql injection geprobeert op onderandere de get_page?id=4 enzo, heb nergens een leak of gat gevonden..

Ik denk dat de fout hierin zit. Of doet die query functie iets met die {} rondom de variabele?


En verder wordt het id niet escaped. SQL injectie gevoelig dus.

Heeft iemand hier MySQL partitioning gebruikt voor grotere datasets?

Ik wil ongeveer 11 GB aan gegevens per jaar per gebruiker opslaan, na deze periode worden ze verwijderd. Is het ontbreken van FKs een groot nadeel in de praktijk wanneer partitioning wordt gebruikt?

laat maar! Heb het helemaal zelf opgelost

[ Bericht 97% gewijzigd door Djurres op 19-08-2014 21:08:25 ]

quote:

Op zondag 17 augustus 2014 11:15 schreef Djurres het volgende:

[..]

Ah, okay.

Maar, kan je me uitleggen waarom je dit beter niet in een database kan zetten? Hack gevoelig?

Ik heb namelijk cookiestealing, xss geprobeerd, en
mysql injection geprobeert op onderandere de get_page?id=4 enzo, heb nergens een leak of gat gevonden..

je wilt configuratie bestanden simpelweg niet in het public gedeelte hebben staan omdat je maar een keer pech hoeft te hebben en de hele wereld heeft je configuratie in handen.

het uitdelen van bestanden via een database is simpelweg een belachelijk idee omdat een database daar niet op gebouwd is ( sterker nog, het wordt er alleen maar kutter op )

quote:

Op dinsdag 19 augustus 2014 19:47 schreef Djurres het volgende:
laat maar! Heb het helemaal zelf opgelost

Laat je post staan dan, zodat anderen ervan kunnen leren

quote:

Op dinsdag 19 augustus 2014 19:47 schreef Djurres het volgende:
laat maar! Heb het helemaal zelf opgelost

je configuratie veranderd naar getenv('geheimding') en deze environment variabelen buiten je document root geset?

Sorrysorrysorry, was een oplossing betreft een andere vraag, had wat problemen met checkboxes en de mail functie, bovenstaand probleem is nog niet opgelost maar had dm van iemand gekregen en dat gaat k ff proberen

Ik ben even benieuwd hoe jullie het volgende probleem zouden tackelen.
Het gaat om een zoekfunctie, waarbij synoniemen van bepaalde woorden ook gematched moeten worden.

Voorbeeld;

Een gebruiker zoekt op "appel", alle soorten gerechten waarbij appel in het Naam veld voorkomt moeten getoond worden.

Echter is er een tabel waarin staat dat er de volgende synoniemen zijn voor het woord appel: "banaan" en "peer".

Wanneer een gebruiker dus zoekt op bijv. "peer" moeten ook de resultaten terug komen die een gebruiker zou krijgen wanneer deze op "appel" had gezocht.

quote:

Op woensdag 20 augustus 2014 22:31 schreef robin007bond het volgende:

[..]

Kan het ook zijn dat hetzelfde woord meerdere synoniemen kent? Dat "peer" bijvoorbeeld ook iets kan zijn uit een hele andere context en dus niet bij de soorten fruit hoort?

Ja, ook dat nog.

quote:

Op woensdag 20 augustus 2014 23:25 schreef robin007bond het volgende:

[..]

Misschien zeg ik iets stoms hoor.

Maar kan je niet een aparte tabel maken met synoniemen en met allemaal foreign keys van dingen die synoniem van elkaar zijn binnen een bepaalde context?

Dat je dus een row hebt met appel, banaan en peer (als dat synoniemen zouden zijn natuurlijk ) en dan met een join legt naar de synoniemen zodra de zoekopdracht wordt gedaan?

Ik volg je mischien niet helemaal, maar wat ik bedoel; een gebruiker doet een zoekopdracht via een tekstveld, hier vult hij appel in.

Vervolgens submit hij deze, en moet er een query uitgevoerd worden waar ik op dat moment alleen de waarde "appel" heb.

Heel simpel gezegd krijg je dan zo iets SELECT * FROM gerechten WHERE naam LIKE '%appel%'

Dus ook appelmoes wordt getoond, maar dit moet ook perenmoes zijn omdat het ( in dit voorbeeld dan ) een synoniem is.

Jouw suggestie is dus om een aparte tabel te hebben waarbij je zo iets krijgt:

naam - synoniem
appel - peer
appel - banaan
appel - etcetc

maar hoe koppel ik die 3 rijen dan weer efficient terug naar de gerechten tabel, zodat hij ook hier op gaat zoeken.

Ik had zelf het idee om tijdens het toevoegen van die synoniemen of gerechten al alle matchende rijen op te zoeken, en alle koppelingen al direct opslaan zodat ik hier op kan joinen wanneer een gebruiker zoekt.

Maar dat is naar mijn idee ook wel een beetje lomp.

Je sluit je foreach niet eens af?

quote:

Op zondag 24 augustus 2014 14:22 schreef Igen het volgende:
O ja, het gaat dus fout bij het volgende stukje code:
[ code verwijderd ]

Bij die laatste regel regel met "$name = ..." ontstaat dus een aanroep naar __autoload met die schijnbaar totaal willekeurige letters en cijfers als class-naam.

Iemand enig idee waarom?

omdat de functie call_user_func eerst de callback mee moet krijgen en als tweede argument de parameter. Nu doe je het andersom

mixed call_user_func ( callable $callback [, mixed $parameter [, mixed $... ]] )

quote:

Op zondag 24 augustus 2014 16:12 schreef remi1986 het volgende:

[..]

omdat de functie call_user_func eerst de callback mee moet krijgen en als tweede argument de parameter. Nu doe je het andersom

mixed call_user_func ( callable $callback [, mixed $parameter [, mixed $... ]] )
[ code verwijderd ]

Nee hoor, volgens mij wil hij als callback GetName van de betreffende childclass aanroepen. Op zich is het valide code, maar wellicht is GetName niet static.

quote:

Op zondag 24 augustus 2014 16:57 schreef Igen het volgende:
Ja, dat was de fout hoor! Bedankt!

Geen probleem. Vraag me alleen wel af wat je probeert te bereiken, want erg logisch ziet het er niet uit.

quote:

Op zondag 24 augustus 2014 17:52 schreef Igen het volgende:

[..]

Heb voor m'n persoonlijke website een simpele CMS gemaakt, als programmeeroefeningetje. De data bestaat uit een boomstructuur van pagina's, subpagina's, koppen, alinea's, plaatjesgalerijen, losse plaatjes, embedded youtube-filmpjes enz. Het stukje code wat ik liet zien, maakt een menuutje waar je kan kiezen uit de geldige soorten inhoud die je op een bepaald punt kan invoegen (een plaatje of filmpje bijv. alleen in een galerij, etc.).
[ code verwijderd ]

(Ik geloof dat het niet netjes is om HTML direct in de code te genereren, maar dat is weer een ander verhaal)

Maar al die classes hebben dus een statig GetName die een bepaalde naam teruggeeft of hoe moet ik het zien?

Wat een vage constructies je hier soms ook tegenkomt

Eerst uit de database een rijtje namen halen, en dan vervolgens aan de class vragen van "hee hoe heet jij?"

quote:

Op zondag 24 augustus 2014 18:26 schreef Igen het volgende:

[..]

Ja.

[..]

Klopt. Ik wil niet dat de eindgebruiker rechtstreeks in de HTML-code kan zien hoe de klassen intern heten.

Daar heeft de gebruiker niet zo veel aan hoor.

Dit soort bijzondere constructies zijn ook echt schering en inslag in PHP.

quote:

Op zondag 24 augustus 2014 18:49 schreef Igen het volgende:

[..]

Ik vond het netjes om het zo te abstraheren. Maar misschien heb je gelijk en is het overbodig. Niet dat de code er veel anders van zou worden, op z'n simpelst zou het zoiets worden:
[ code verwijderd ]

Gebruikt nog steeds dezelfde constructies. Welke constructie vind je eigenlijk zo "bijzonder"?

De hele manier waarop je data in de database en de code zelf verwoven lijken te zijn.
Sla dan dit soort informatie in zijn geheel op in de database.
Sowieso heb ik het idee dat hier weer een brij aan inheritance ipv composition wordt gebruikt.

quote:

Op zondag 24 augustus 2014 18:49 schreef Igen het volgende:

[..]

Ik vond het netjes om het zo te abstraheren. Maar misschien heb je gelijk en is het overbodig. Niet dat de code er veel anders van zou worden, op z'n simpelst zou het zoiets worden:
[ code verwijderd ]

Gebruikt nog steeds dezelfde constructies. Welke constructie vind je eigenlijk zo "bijzonder"?

het idee van classes is dat je er objecten van maakt. Een getname functie zou dan logischerwijs betekenen dat je de naam van het desbetreffende object krijgt, en niet de naam van de class.

Waarom zet je die screenname niet in de database erbij dan? Scheelt je loopen door al die classes en hoef je ook niet in elke class die functie aan te maken.

Phred is an open-source initiative aimed at providing PHP with a consistent, completely object-oriented coding standard that enjoys a comfortable API for creating modern-day web applications with native support for Unicode, with components for internationalization and localization, clear-cut fundamental data types focused on performance and reliability, enhanced testing and debugging, and other features.

[…]

PHP 6 or Uniphant vs. Elecorn
Most of the hopes for a better PHP were being put in PHP 6 announced around 2006. However, PHP 6 became more like a mythical creature over the time, a creature that no one has ever seen. The new features that were planned for PHP, including the highly anticipated Unicode support, had never got released under PHP 6 label. Instead, the PHP 6 development branch was discontinued and only some of the features were backported into the 5.x versions afterwards, still without built-in Unicode. There was no beta or even alpha version of PHP 6.

One of the main reasons behind PHP 6 getting abandoned was a disagreement inside the development team as to which character encoding would serve best for storing and processing Unicode strings. Despite of the fact that the team then picked UTF-16 as the internal encoding to be used for Unicode, the development ran out of steam and eventually came to a halt. This happened not only because the choice of UTF-16 turned out to be suboptimal, but also because of the immense body of work that was required to be done for the PHP's core and all the extensions by the developers becoming less and less enthusiastic with the direction that was chosen and due to other issues. Andrei Zmievski, who was the head of the PHP 6 project, later admitted that he would probably choose UTF-8 over UTF-16 if it was possible to start over.

[...]

こんにちは, Phred
The idea of Phred is resonating with the principle of separation of concerns. Let the PHP's core contributors remain focused on the language's underpinnings and further improve the PHP's engine to make it even faster, effectively providing a high-performance foundation upon which a consistent and completely object-oriented coding standard can be implemented by PHP developers themselves.

By extending PHP 7, which is now twice as fast, Phred converts PHP into an up-to-date and clean standard advantageous for creating sophisticated web sites and applications to be used by people all over the world, while keeping performance at a high level. Fortunately, the OOP-related features that are already present in PHP 5.6 and PHP 7 have made this possible. And not to forget the vital OOP infusions into the language that were faithfully made by some of its core contributors, most notably Nikita Popov.