[PHP/(My)SQL] voor dummies - Deel 12 | Digital Corner (DIG)

woensdag 7 september 2005 @ 23:27:19 #101

JeRa

quote:
Op woensdag 7 september 2005 22:02 schreef wonderer het volgende:
Ik wil graag backupbestanden van 200000 records terugzetten... hoe kan ik dat het beste doen? Uploaden via SQL gaat niet...

Je doet dit waarschijnlijk via phpMyAdmin? Die heeft de beperking van HTTP file uploads, enkele MB's dus. Wat je kunt doen:

andere tools gebruiken die geen limiet hebben en direct contact kunnen maken met de MySQL server

je backupbestanden opsplitsen zodat de afzonderlijke delen kleiner zijn dan de maximale toegestane limiet om te uploaden

donderdag 8 september 2005 @ 12:21:12 #102

markiemark

FR 1908

ik heb even een klein vraagje.. heb het niet eens nodig of zo, maar kan het hier niet ff zo proberen, maar wil het toch even weten..

stel ik heb een pagina met daarin een include.. kan ik dat dan zo doen dat de URL variabele meegestuurd wordt? dus bijv.

1
2
3

<?php
include "header.php?pagina=homepage";
?>

zodat header.php een actie uitvoert die afhangt van de get variabele pagina...

ben benieuwd..

Amsterdam, stad van hash en coke,
Waar de vrouwen zich vrouwelijk gedragen..
En de mannen ook..

donderdag 8 september 2005 @ 12:23:29 #103

Roonaan

Strictly

<?php
$pagina = 'homepage';
include 'header.php';
?>

Of

<?php
include "http://www.mijndomein.nl/header.php?pagina=homepage";
?>

volledige url dus. Lijkt me alleen niet verstandig vanuit performance point of view.

donderdag 8 september 2005 @ 13:53:47 #104

JeRa

De eerste oplossing van Roonaan is dus de beste

ik weet het natuurlijk niet zeker maar ik gok dat je een index.php hebt die zo wordt aangeroepen:

index.php?pagina=blaat

En dat je nu header.php wilt includen die dezelfde informatie doorkrijgt. Door deze te includen gaat PHP in feite de broncode van header.php in je index.php zetten, waardoor header.php dus exact dezelfde variabelen als index.php kan gaan benaderen. In feite doe je in header.php dus hetzelfde als hetgeen je in index.php doet om die variabele te achterhalen

donderdag 8 september 2005 @ 16:31:55 #105

Chandler

offtopic (beetje) misschien is het eens leuk om een PHP regex archive op te zetten?

The people who lost my respect will never get a capital letter for their name again.
Like trump...

donderdag 8 september 2005 @ 18:06:26 #106

JeRa

quote:
Op donderdag 8 september 2005 16:31 schreef Chandler het volgende:
offtopic (beetje) misschien is het eens leuk om een PHP regex archive op te zetten?

Die bestaan al, maar het zou wel eens leuk zijn om een archive te zien die zich ook aan de standaarden houdt

(probeer maar eens een eenduidige regular expression te vinden die een e-mailadres checkt).

vrijdag 9 september 2005 @ 11:05:22 #107

MaxPowered

Au Gurk!

Hoi,

Ik last laatst een artikel over SQL injection. Dus ik ff mijn site daarop gecheckt.

Een voorbeeld van SQL Injection uit het artikel:

1
2
3
4
5
6
7
8
9
10

<?php
mysql_connect("localhost", "root", "");
mysql_select_db("hack");

$query = mysql_query('SELECT bla FROM users ORDER BY bla '.$_GET['ORDER']);

while($row = mysql_fetch_array($query)) {
echo $row[bla];
}
?>

Als men daarna http://localhost/hack.php?ORDER=desc; DROP TABLE users zou uitvoeren, zou de tabel users verwijderd worden.
Mijns inziens is dit bullshit. Als ik het in de browser plak, krijg ik het volgende als ik op enter druk:
http://localhost/hack.php?ORDER=desc;%20DROP%20TABLE%20users

Is hiermee aangetoond dat SQL-injection niet werkt?

Alvast bedankt voor de tips,

m@x

-= Rogue lvl 66 =- -= Warrior lvl 70 =- -= Warlock lvl 70 =-
----------============= Nordrassil =============----------

FOK!-Schrikkelbaas vrijdag 9 september 2005 @ 14:05:27 #108

Swetsenegger

Egocentrische Narcist

quote:
Op vrijdag 9 september 2005 11:05 schreef MaxPowered het volgende:
Hoi,

Ik last laatst een artikel over SQL injection. Dus ik ff mijn site daarop gecheckt.

Een voorbeeld van SQL Injection uit het artikel:
[ code verwijderd ]

Als men daarna http://localhost/hack.php?ORDER=desc; DROP TABLE users zou uitvoeren, zou de tabel users verwijderd worden.
Mijns inziens is dit bullshit. Als ik het in de browser plak, krijg ik het volgende als ik op enter druk:
http://localhost/hack.php?ORDER=desc;%20DROP%20TABLE%20users

Is hiermee aangetoond dat SQL-injection niet werkt?

Alvast bedankt voor de tips,

m@x

Nee, daarmee is aangetoont dat je browser aan url encoding doet

Een pagina terug staat er een discussie over sql injection. Tussen quotes heb je minder kans op injection, maar is nog wel degelijk aanzweig.

De uitkomst van de discussie was dat je sowieso ALTIJD userinput moet controleren.

 | FOK! Schrikkelbaasch

vrijdag 9 september 2005 @ 18:31:05 #109

JeRa

...en dat je in een query altijd het goede type moet laten vertegenwoordigen, om zo geen onnodige risico's of trage queries te introduceren

edit: overigens, ik geloof dat het al een tijdje zo is dat je in PHP geen meerdere queries in één keer kunt uitvoeren door puntkomma-gescheiden queries achter elkaar te zetten. Die injectie zou dus wrs niet eens willen werken

FOK!-Schrikkelbaas vrijdag 9 september 2005 @ 20:27:59 #110

Swetsenegger

Egocentrische Narcist

Ik heb 3 tabellen, hieronder de relevante velden

table ad

1 2	ad_id id_user

table user

1 2	user_id name

table rate

1
2
3

rate_id
user
rating

Ad heeft bij elke record een corresponderende user in ID-user
User spreekt voor zich
rate KAN een aantal records met de corresponderende user hebben.

Ik wil uit ad het totaal aantal reords van user
uit user de naam
uit rate de gemiddelde rate van desbetreffende user (indien die bestaat)

1
2
3
4
5
6
7

<?php
SELECT COUNT(ad.ad_id)  AS number, user.name, AVG(SUM(rate.rating))
FROM ad
INNER JOIN user ON (id_user = user_id)
RIGHT JOIN rate ON (id_user = user)
WHERE ad.id_user=1
?>

Dit geeft 'invalid use of group function' terug.

Mijn sql is niet zo sterk. Dus het zal ongetwijfeld aan mij liggen

Iemand die wat licht op de zaak kan schijnen?

[ Bericht 2% gewijzigd door Swetsenegger op 09-09-2005 20:56:40 ]

 | FOK! Schrikkelbaasch

vrijdag 9 september 2005 @ 22:02:10 #111

SuperRembo

Sinds 1998

Er moet nog een GROUP BY user.name bij en volgens mij moet het een LEFT JOIN zijn in plaats van RIGHT JOIN.

1
2
3
4
5
6

SELECT user.name, COUNT(ad.ad_id) AS number, AVG(SUM(rate.rating))
FROM user
INNER JOIN ad ON ad.id_user = user.user_id
LEFT JOIN rate ON rate.user = user.user_id
WHERE user.user_id = 1
GROUP BY user.name

FOK!-Schrikkelbaas vrijdag 9 september 2005 @ 22:03:57 #112

Swetsenegger

Egocentrische Narcist

quote:
Op vrijdag 9 september 2005 22:02 schreef SuperRembo het volgende:
Er moet nog een GROUP BY user.name bij en volgens mij moet het een LEFT JOIN zijn in plaats van RIGHT JOIN.
[ code verwijderd ]

Dat had ik inderdaad ook al geprobeerd.

'invalid use of group function'

als ik de AVG eruit haalt werkt dit prima overigens. Naam: 3 records.
In de SQL documentatie las ik dat AVG(SUM(field)) niet kan en dat je dan een subquery in de FROM statement moet gebruiken:

SELECT AVG(sum_field) FROM (SELECT SUM(field) AS sum_field FROM table GROUP BY field)

maar wanneer ik dit overneem krijg ik een sql error 'nearby SELECT SUM(fiels....' etc.

In de documentatie staat geen sql versie vermeld, dus ik neem aan dat dit gewoon op SQL 4.0.24 werkt

[ Bericht 18% gewijzigd door Swetsenegger op 09-09-2005 22:09:47 ]

 | FOK! Schrikkelbaasch

vrijdag 9 september 2005 @ 22:17:20 #113

SuperRembo

Sinds 1998

Subquery's zijn dacht ik mogelijk vanaf MySQL 4.1.

FOK!-Schrikkelbaas vrijdag 9 september 2005 @ 22:20:08 #114

Swetsenegger

Egocentrische Narcist

Een tweakert had de oplossing

1
2
3
4
5
6

SELECT user.name, COUNT(ad.ad_id)  AS number, AVG(rate.rating) AS average
                        FROM user
                        INNER JOIN ad ON ad.id_user = user.user_id
                        LEFT JOIN rate ON rate.user = user.user_id
                        WHERE user.user_id =".$_GET['id']."
                        GROUP BY user.name"

 | FOK! Schrikkelbaasch

FOK!-Schrikkelbaas vrijdag 9 september 2005 @ 22:27:46 #115

Swetsenegger

Egocentrische Narcist

Een nadeel, als er geen rating is, laat hij de rest ook niet zien

 | FOK! Schrikkelbaasch

vrijdag 9 september 2005 @ 22:40:15 #116

Roonaan

Strictly

waarom heb je zo'n komische naamgeving in je tabellen?
wrom niet gewoon:
[users]
user_id, user_name, user_whatever
[ads]
ad_id, ad_user
[ratings]
rate_id, rate_value, rate_user

Heb je vervolgens nergens meer problemen met ambigue fields of de noodzaak om de table.field constructie te gebruiken..

vrijdag 9 september 2005 @ 22:50:02 #117

SuperRembo

Sinds 1998

Ja da's handig zeg. Nu hoef je niet meer soms "table." voor een veldnaam te zetten, nee je zet er altijd "table_" voor

vrijdag 9 september 2005 @ 23:01:55 #119

JeRa

quote:
Op vrijdag 9 september 2005 22:50 schreef SuperRembo het volgende:
Ja da's handig zeg. Nu hoef je niet meer soms "table." voor een veldnaam te zetten, nee je zet er altijd "table_" voor

Ik snap deze opmerking niet

wat zeg je nu eigenlijk?

FOK!-Schrikkelbaas vrijdag 9 september 2005 @ 23:02:03 #120

Swetsenegger

Egocentrische Narcist

Ik gebruik nergens ambigue fields zoals je ziet.

En waarom niet zoals roonaan zegt... tja geen idee. Ik vind naamgeving irritant, zou alles het liefst een nummer geven

Overigens werkt de query wel, maar je moet natuurlijk in je life table wel dezelfde veldnamen gebruiken als in je test tabel

 | FOK! Schrikkelbaasch

vrijdag 9 september 2005 @ 23:02:53 #121

SuperRembo

Sinds 1998

Ik ben niet lui hoor. Je moet weten wat je doet. Zelfs als je al je veldnamen in je database uniek maakt, dan is dat nog geen garantie dat je veldnamen in een query uniek zijn.

vrijdag 9 september 2005 @ 23:04:35 #122

Light

quote:
Op vrijdag 9 september 2005 23:02 schreef Swetsenegger het volgende:
Ik gebruik nergens ambigue fields zoals je ziet.

En waarom niet zoals roonaan zegt... tja geen idee. Ik vind naamgeving irritant, zou alles het liefst een nummer geven

Overigens werkt de query wel, maar je moet natuurlijk in je life table wel dezelfde veldnamen gebruiken als in je test tabel

Dat lijkt me sowieso een vereiste

fokstok.nl

vrijdag 9 september 2005 @ 23:07:10 #123

SuperRembo

Sinds 1998

quote:
Op vrijdag 9 september 2005 23:01 schreef JeRa het volgende:

[..]

Ik snap deze opmerking niet wat zeg je nu eigenlijk?

Roonaan stelt voor om voor elk veld in de tabel "users" de string "user_" te plakken. Dan zijn de veldnamen uniek, en hoek je (meestal) geen tabelnamen te vermelden voor de veldnamen in je query.

In plaats van

1	SELECT foo.name, bar.name FROM foo INNER JOIN bar ON bar.id = foo.id

krijg je dan

1	SELECT foo_name, bar_name FROM foo INNER JOIN bar ON bar_id = foo_id

Ik zie 't voordeel niet. Ik zie wel nadelen.

vrijdag 9 september 2005 @ 23:20:55 #124

saban

hoi?

Iemand een suggestie welke NL boek ik kan kopen om MySQL meer onder de knie te krijgen ?

Ik heb nu 2 PHP/MYSQL boeken liggen, maar die gaan niet verder dan SELECT .. WHERE .. LIKE

ne okuyon, bokmu var?

FOK!-Schrikkelbaas vrijdag 9 september 2005 @ 23:29:26 #125

Swetsenegger

Egocentrische Narcist

quote:
Op vrijdag 9 september 2005 23:04 schreef Light het volgende:

[..]

Dat lijkt me sowieso een vereiste

Ja dat is best handig

 | FOK! Schrikkelbaasch

FOK!-Schrikkelbaas vrijdag 9 september 2005 @ 23:40:35 #127

Swetsenegger

Egocentrische Narcist

quote:
Op vrijdag 9 september 2005 23:34 schreef gelly het volgende:

[..]

Heb je wel eens code van jezelf van zegmaar 3 jaar terug eens bekeken ? Ik doe het zelf ook hoor, maar achteraf pas ik alle variabelen weer aan zodat het voor iedereen leesbaar is. En voor mij over 3 jaar.

Nee, want 3 jaar geleden schreef ik nog geen code (tenminste, geen PHP)

Maar ik kan het nog verassend goed lezen en het zit best aardig in elkaar.

Mbt veiligheid heb ik hier en daar een steekje laten vallen af en toe. Ondertussen alweer recht getrokken.

 | FOK! Schrikkelbaasch

vrijdag 9 september 2005 @ 23:54:46 #128

Light

quote:
Op vrijdag 9 september 2005 23:07 schreef SuperRembo het volgende:

[..]

Roonaan stelt voor om voor elk veld in de tabel "users" de string "user_" te plakken. Dan zijn de veldnamen uniek, en hoek je (meestal) geen tabelnamen te vermelden voor de veldnamen in je query.

In plaats van
[ code verwijderd ]

krijg je dan
[ code verwijderd ]

Ik zie 't voordeel niet. Ik zie wel nadelen.

Ik schrijf

1	SELECT foo.name, bar.name FROM foo INNER JOIN bar ON bar.id = foo.id

het liefst als

1	SELECT foo.name, bar.name FROM foo INNER JOIN bar USING(id)

Da's net weer iets korter

fokstok.nl

zaterdag 10 september 2005 @ 00:04:14 #129

The_Terminator

Weet iemand toevallig hoe een bestandslijst kan worden verdeeld over meerdere pagina's? Ik gebruik voor mijn Fok! uploader nu een bestandslijst die gewoon in zijn geheel op één pagina staat. Maar de bestandslijst is onderhand zo lang geworden dat ik een pagina van bijna één meg moet downloaden om de lijst in te kunnen zien. Iemand een oplossing?

zaterdag 10 september 2005 @ 00:06:51 #130

JeRa

quote:
Op zaterdag 10 september 2005 00:04 schreef The_Terminator het volgende:
Weet iemand toevallig hoe een bestandslijst kan worden verdeeld over meerdere pagina's? Ik gebruik voor mijn Fok! uploader nu een bestandslijst die gewoon in zijn geheel op één pagina staat. Maar de bestandslijst is onderhand zo lang geworden dat ik een pagina van bijna één meg moet downloaden om de lijst in te kunnen zien. Iemand een oplossing?

Gaat het over SQL? Dan kun je simpelweg een LIMIT toepassen

zaterdag 10 september 2005 @ 00:10:17 #131

The_Terminator

quote:
Op zaterdag 10 september 2005 00:06 schreef JeRa het volgende:

[..]

Gaat het over SQL? Dan kun je simpelweg een LIMIT toepassen

Nee, het is gewoon een loop. Alle bestanden worden uit de upload dir opgevraagd en de bestandsnamen worden op de pagina weergegeven.

zaterdag 10 september 2005 @ 00:18:29 #132

JeRa

quote:
Op zaterdag 10 september 2005 00:10 schreef The_Terminator het volgende:

[..]

Nee, het is gewoon een loop. Alle bestanden worden uit de upload dir opgevraagd en de bestandsnamen worden op de pagina weergegeven.

Dan moet je alle bestandsnamen opvragen en in een array stoppen. Je moet weten hoeveel bestandsnamen je op één pagina wilt hebben. Het aantal pagina's dat je dan hebt is:

$aantalPaginas = ceil($totaalAantalBestanden / $bestandenPerPagina);

Vervolgens vraag je een paginanummer op dat loopt van 0...n - 1 met n = aantal pagina's. De items die je uit je array moet opvragen zijn dan:

$eersteItem = $paginaNummer * $bestandenPerPagina;
$laatsteItem = min($eersteItem + $bestandenPerPagina, $totaalAantalBestanden);

en die werk je dan met een loopje af

de pagina's wil je natuurlijk laten zien als 1...n, maar dat is puur cosmetisch (je telt 1 op bij de interne waarde).

[ Bericht 2% gewijzigd door JeRa op 10-09-2005 00:23:31 ]

zaterdag 10 september 2005 @ 01:31:38 #133

wonderer

Hung like a My Little Pony

Ik probeer met

1
2
3
4
5

<?php
echo ini_get("session.use_trans_id");
echo ini_get("output_buffering");
echo ini_get("output_handler");
?>

uit te vinden waarom ie niet flusht, maar het laat niks zien? Doe ik wat fout? Is er een instelling die dit soort dingen "verbiedt"? Klopt het dan ook dat ik ini_set niet kan gebruiken?

Ik snap er geen fuck meer van.

"Pain is my friend. I can trust pain. I can trust pain to make my life utterly miserable."
"My brain is too smart for me."
"We don't need no education." "Yes you do, you just used a double negative."

zaterdag 10 september 2005 @ 01:34:26 #134

The_Terminator

quote:
Op zaterdag 10 september 2005 00:18 schreef JeRa het volgende:

[..]

Dan moet je alle bestandsnamen opvragen en in een array stoppen. Je moet weten hoeveel bestandsnamen je op één pagina wilt hebben. Het aantal pagina's dat je dan hebt is:

$aantalPaginas = ceil($totaalAantalBestanden / $bestandenPerPagina);

Vervolgens vraag je een paginanummer op dat loopt van 0...n - 1 met n = aantal pagina's. De items die je uit je array moet opvragen zijn dan:

$eersteItem = $paginaNummer * $bestandenPerPagina;
$laatsteItem = min($eersteItem + $bestandenPerPagina, $totaalAantalBestanden);

en die werk je dan met een loopje af de pagina's wil je natuurlijk laten zien als 1...n, maar dat is puur cosmetisch (je telt 1 op bij de interne waarde).

Dankje, daar kan ik wel wat mee

zaterdag 10 september 2005 @ 01:42:49 #135

wonderer

Hung like a My Little Pony

Notice: ob_flush(): failed to flush buffer. No buffer to flush. in /home/fluidint/public_html/chats/chatfunctions.php on line 153

Die "foutmelding" krijg ik trouwens. Hoe kan er nou geen buffer zijn??

"Pain is my friend. I can trust pain. I can trust pain to make my life utterly miserable."
"My brain is too smart for me."
"We don't need no education." "Yes you do, you just used a double negative."

zaterdag 10 september 2005 @ 10:13:04 #136

Roonaan

Strictly

omdat je geen ob_start() gebruikt hebt?

zaterdag 10 september 2005 @ 10:17:13 #137

Roonaan

Strictly

quote:
Op vrijdag 9 september 2005 23:02 schreef SuperRembo het volgende:
Ik ben niet lui hoor. Je moet weten wat je doet. Zelfs als je al je veldnamen in je database uniek maakt, dan is dat nog geen garantie dat je veldnamen in een query uniek zijn.

tuurlijk niet, maar dat maakt de kans erop stukken kleiner. Daarnaast is het in je resultset met mysql_fetch_assoc ook iets practischer, zeker als je extract zou gebruiken., of stomweg var_export bij het bekijken van je query resultaten.

Mijn belangrijkste pre is het feit dat je in ieder geval een houvast hebt qua naamgeving, en dat je er over nagedacht hebt hoe je je velden noemt, in plaats van maar wat te kiezen.

-r-

zaterdag 10 september 2005 @ 20:33:19 #138

wonderer

Hung like a My Little Pony

quote:
Op zaterdag 10 september 2005 10:13 schreef Roönaän het volgende:
omdat je geen ob_start() gebruikt hebt?

Dat moet ook niet... hij moet niet bufferen, hij moet alles meteen uitspugen, maar dat werkt op de een of andere manier niet. Ik probeer uit te vinden waarom niet, maar dat schiet niet op. Ik WEET dat hij buffert, want als de loop tot een eind komt, spuugt ie wel alles uit. Alleen als ik dus flush doe, zegt ie dat er geen buffer is...

"Pain is my friend. I can trust pain. I can trust pain to make my life utterly miserable."
"My brain is too smart for me."
"We don't need no education." "Yes you do, you just used a double negative."

zaterdag 10 september 2005 @ 21:04:14 #139

SuperRembo

Sinds 1998

quote:
Op zaterdag 10 september 2005 10:17 schreef Roönaän het volgende:

[..]

tuurlijk niet, maar dat maakt de kans erop stukken kleiner. Daarnaast is het in je resultset met mysql_fetch_assoc ook iets practischer, zeker als je extract zou gebruiken., of stomweg var_export bij het bekijken van je query resultaten.

Mijn belangrijkste pre is het feit dat je in ieder geval een houvast hebt qua naamgeving, en dat je er over nagedacht hebt hoe je je velden noemt, in plaats van maar wat te kiezen.

-r-

Je moet er zeker nadenken. Ik ben ook wel een voorstander van tabelnamen in meervoudsvorm. En engels natuurlijk.
Maar ik hou ook van duidelijke namen, dus categories en niet cats of iets degelijks. Wat doe je dan met de veldnamen? Ga je daar ook overal category_ voor zetten, of kort je het daar wel af tot cat_?
Nee, ik vind het nog steeds niks die table prefix.

FOK!-Schrikkelbaas zaterdag 10 september 2005 @ 21:07:29 #140

Swetsenegger

Egocentrische Narcist

Offtopic, weet iemand een site met mooie iconen gratis en voor niets uiteraard?

 | FOK! Schrikkelbaasch

zondag 11 september 2005 @ 00:38:44 #141

JeRa

quote:
Op zaterdag 10 september 2005 21:07 schreef Swetsenegger het volgende:
Offtopic, weet iemand een site met mooie iconen gratis en voor niets uiteraard?

Hier moet je vast & zeker wel wat mee kunnen

zo niet, dan zul je toch wat specifieker moeten zijn vrees ik

zondag 11 september 2005 @ 09:17:56 #142

Roonaan

Strictly

quote:
Op zaterdag 10 september 2005 20:33 schreef wonderer het volgende:

[..]

Dat moet ook niet... hij moet niet bufferen, hij moet alles meteen uitspugen, maar dat werkt op de een of andere manier niet. Ik probeer uit te vinden waarom niet, maar dat schiet niet op. Ik WEET dat hij buffert, want als de loop tot een eind komt, spuugt ie wel alles uit. Alleen als ik dus flush doe, zegt ie dat er geen buffer is...

Dan moet je ook geen ob_flush() gebruiken, maar gewoon flush().

Je moet er rekening mee houden dat IE niet zoveel nuttigs doet als er eerst niet iets van 256 characters uitgegooid zijn.

zondag 11 september 2005 @ 12:01:26 #143

JeRa

Output buffering is een hel in PHP, zoals ik al twee keer eerder heb gezegd in deze reeks

ik geloof dat de enige methode om het een beetje te laten werken is ob_flush() en flush() direct na elkaar aan te roepen als je wilt flushen, maar ook dat geeft geen garanties.

zondag 11 september 2005 @ 12:19:54 #144

Roonaan

Strictly

ob_flush() moet je alleen gebruiken als je ob_start() hebt gebruikt. Aangezien hij dat niet heeft gedaan zou een enkele flush() voldoende moeten zijn. Echter zijn er voor sommige browsers wel wat haken en ogen, being dat er minimaal aantal bytes verzonden moet zijn voordat de browser begint met renderen.

zondag 11 september 2005 @ 13:26:03 #145

JeRa

Ben ik het mee eens, ware het niet dat ik het vreemd blijf vinden wat er in de PHP manual staat:

quote:
flush() has no effect on the buffering scheme of your webserver or the browser on the client side. Thus you need to call both ob_flush() and flush() to flush the output buffers.

'output buffers' zijn in deze context de output buffers van PHP en de webserver, etc. Feitelijk zeggen ze daar niet dat je ob_start() hebt moeten aanroepen voordat je de ob_flush();flush(); methode gebruikt.

zondag 11 september 2005 @ 13:58:33 #146

Roonaan

Strictly

misschien niet, maar ob_flush geeft wel een notice als je geen ob_start hebt gebruikt, vandaar. op zich zou je dus iets kunnen doen als:
for($i = 0, $c = ob_get_level(), $i < $c; $i++) ob_end_flush(); maar of dat nu zo'n succes is?

-r-

zondag 11 september 2005 @ 14:29:56 #147

SuperRembo

Sinds 1998

quote:
Op zondag 11 september 2005 13:58 schreef Roönaän het volgende:
misschien niet, maar ob_flush geeft wel een notice als je geen ob_start hebt gebruikt, vandaar. op zich zou je dus iets kunnen doen als:
for($i = 0, $c = ob_get_level(), $i < $c; $i++) ob_end_flush(); maar of dat nu zo'n succes is?

Maar die doet als ik 't goed begrijp dus niets als je geen ob_start() hebt gebruikt?

zondag 11 september 2005 @ 15:03:52 #148

JeRa

quote:
Op zondag 11 september 2005 13:58 schreef Roönaän het volgende:
...maar of dat nu zo'n succes is?

Daar zal de vraagsteller zich over moeten buigen, maar ik geloof dat het sowieso al geen succes was dus het is het proberen waard

[offtopic]
Is er een bepaalde reden waarom je het niet zo doet?

1
2
3

while (ob_get_level() > 0) {
ob_end_flush();
}

Dit is imo beter leesbaar en het introduceert geen twee nieuwe variabelen.

zondag 11 september 2005 @ 15:08:09 #149

Roonaan

Strictly

Omdat je dan continue ob_get_level aan het evalueren bent.

zelf met for($i = 0; $i < count($array); $i++).. is ook niet altijd het beste.

-r-

zondag 11 september 2005 @ 17:02:27 #150

wonderer

Hung like a My Little Pony

quote:
Op zondag 11 september 2005 12:01 schreef JeRa het volgende:
Output buffering is een hel in PHP, zoals ik al twee keer eerder heb gezegd in deze reeks ik geloof dat de enige methode om het een beetje te laten werken is ob_flush() en flush() direct na elkaar aan te roepen als je wilt flushen, maar ook dat geeft geen garanties.

Maar het werkt prima op twee verschillende servers, dat is het hele punt. Ik roep ob_implicit_flush aan en hij spuugt alles netjes uit. Alleen op die ene server doet ie dat dus niet en ik probeer alles dat ik kan bedenken om uit te vinden waar dat aan ligt.

Ik weet lang niet zo veel van PHP als jullie, dus ik doe maar wat en hoop dat ik de fouten kan interpreteren. Ik snap gewoon niet waarom ie het op de ene server wel doet en op de andere niet.

"Pain is my friend. I can trust pain. I can trust pain to make my life utterly miserable."
"My brain is too smart for me."
"We don't need no education." "Yes you do, you just used a double negative."

Forum Opties
Forumhop:
Hop naar:	(afkorting, bv 'KLB')

[PHP/(My)SQL] voor dummies - Deel 12

» digital corner

» digital corner