Tja, elk script heeft een eigen opbouw van de database Je kan niet de database-queries voor script A implementeren voor script B.

Ik zou DirectAdmin aanraden.

- Veel support voor
- Veel scripts om de boel (voornamelijk via CLI) te beheren
- Makkelijk losse software (PHP, MySQL, Apache, Exim, Dovecot etc..) te upgraden via Custombuild

Dat de frontend uit het jaar kruik stamt vind ik niet echt een argument, want ook hier kan je weer andere theme's voor installeren. Sommige kosten nou eenmaal geld, sommige weer niet.

Citaat

see skins for the rest of the values, eg bandwidth, ubandwidth, quota, uquota..etc.

En ja, ik hoop dat DA een keer meer aandacht aan hun API gaat besteden.

Tuurlijk, het zit er gewoon in...
http://www.directadmin.com/features.php?id=583

Jammer dat er maar 20% van de mogelijkheden duidelijk gedocumenteerd is.

Citaat van eeyk

Tja als ik de tijd had deed ik het maar ik moet op dit moment nog gigantisch veel pagina's maken en update voor 4 verschillende websites.

Dan had je ook anders kunnen reageren. En zoveel moeite is het nou ook weer niet om het direct toe te passen.

Citaat van eeyk

Alsjeblieft, doe niet bijdehand.

Pardon, doe ik bijdehand? Goede foutafhandeling bouw je in je script, niet achter je functies (die die-method).
Een script moet gewoon netjes in elk geval ten einde komen, en niet met een doodsteek.

Je moet het IN je script bouwen, en NIET er achter.

Gebruik gewoon een echo met een double-quote, dan hoef je die single-quotes niet meer te escapen.

Jeetje, dat moet wel een lang project zijn geweest. In 2011 had ik al toegang tot het nieuwe design.

Ligt er een beetje aan wat voor site het is. Vergeet niet dat logo's onder het merkenrecht vallen.

je moet maar net een advocaat of jurist hebben die er anders over denkt, waarna je een sommatie tot verwijdering krijgt vanwege inbreuk op merkenrecht. Dus wees voorzichtig.....

Citaat van victor

Aar, waarom zou er geen html voor je setcookie mogen staan? Dat is natuurlijk onzin.

Reza, ob_start() is inderdaad een slordige manier. Gewoon net scripten...

@TS

Google eens http://www.phphulp.nl/php/tutorial/p…ready-sent/738/

Hoezo onzin? Het mag gewoon niet, omdat een cookie een HTTP-header is, en daar mag geen HTML voor staan, omdat headers voor de HTML worden geladen.
outputbufferign kan, maar zou een flinke sloot geheugen kunnen kosten, performance die je beter kan krijgen door gewoon goed te scripten.

Of je neemt een VPS af?

Ik gok dat je server geen SPF-record heeft?
http://nl.wikipedia.org/wiki/Sender_Policy_Framework

Citaat van simone75

en ik heb deze source gekocht en ben hem dus aan het aanpassen.

Daar heb je het probleem van de ellende steeds. Je weet niet wat je koopt, ook niet hoe je het op moet lossen?
Wat houdt je tegen om zelf eens wat te maken? DAAR leer je van, NIET van dingen zomaar kopen.....

KOPEN kan je LATER nog wel eens doen als je KAN PROGRAMMEREN.

Citaat van simone75

Heb het zo aangepast maar het werkt nog steeds niet

Niet verwonderlijk, je past mijn tip niet toe.

Met andere woorden, plaats de expressie om twee gelijke tekens, de delimiters, deze scheiden de expressie van eventuele modifiers.

Het biedt wel een voordeel. Je $_SERVER array is goed gevuld, en relatieve includes werken...

persoonlijk zou ik alsnog gewoon het volledige pad gebruiken...

.. of sterker als, aan een dergelijk PHP-script.
Niet vervelend bedoeld, maar dat is je al een half jaar geleden al eens duidelijk gemaakt. Maak gewoon een keuze:

- Leer PHP, begin bij het begin van de tutorials
- Zoek een andere hobby.

Maar halverwege instromen in een super-complex script waarvan je niet eens hoe het werkt, dat gaat echt niet werken. Het gaat niet alleen om te kunnen programmeren, maar ook om de theorie. Denk aan veiligheid, verschil tussen strings en integers en wanneer je die gebruikt, en wat functies precies doen, en wat 'variabelen buiten quotes' en waar dat goed voor is....

Waar komt $data vandaan?

Je kan ook display_errors eens op 1 zetten, en indien je IE gebruikt de 'gebruiks vriendelijke foutmeldingen' omschakelen.