PHP Mailing system

har du prøvet at google php newsletter system ??
http://www.phpkode.com/projects/category/php-newsletter/
http://www.phpkode.com/projects/item/simple-php-mailing-list/ ser interessant ud
http://www.phpkode.com/projects/item/mailinglist-system/ ser interessant ud


kører parrallelt på http://www.eksperten.dk/spm/975412

De er bare ikke simple, som jeg skrev, vil jeg gerne lave mit eget.
- Altså der skal ikke være alt det der med at installere det osv.
- Det som jeg tror mest på, er nærmest, at man bare laver en form for kontaktform, og så ændre der hvor man skriver hvem den er til, ændre det til $query .... osv...
- sådan at den bare sende til alt hvad der er i den database, men kan det overhovedet lade sig gøre ?

>>hvis der var en eller flere der kunne komme med en løsning, evt lave et færdigt script.
udvikleren.dk, og iøvrigt også eksperten.dk er hjælp til selv hjælp, du skal selv code

>De er bare ikke simple, som jeg skrev, vil jeg gerne lave mit eget.
hvad hindre dig i at downloade source coderne til de 2 der ser interessante ud, og lader dig inspirare af dem ??, der er ikke nogle grund til at opfinde den dybe tallarken flere gange
ellers kan du kiige på www.phpclasses.org (er pt meget lang tid om at svare), der er en masse gratis classer lige til at bruge, for at downloade fra phpclasses.org skal man ofte være registeret medlem, hvilke er gratis, og mam bliver ikke spammet

Det skyldes, at jeg også er ved at lave mit eget dashboard, hvor man netop skal kunne skrive det nyhedsbrev, henter jeg en af dem, kan jeg ikke bare sådan ligge det ind, til det design jeg har lavet, og de fleste gange, skal man logge ind et andet sted også, hvor jeg gerne vil have, at der bare er ét logind, og ikke to eller flere.
- Men finder sku nok en løsning...

i den meget sparsomme code du allerede har lavet, er der en stor "fejl", du anvender det gamle API/extension
brug tiden på at opdaterer alt din nuværende aktive code til nutidens std

ref http://php.net/manual/en/mysqlinfo.api.choosing.php

Recommended API
It is recommended to use either the mysqli or PDO_MySQL extensions. It is not recommended to use the old mysql extension for new development, as it has been deprecated as of PHP 5.5.0 and will be removed in the future.

mysqli (Procedural style) : hurtig lavet, ligner det gamle mysql
mysqli (Object oriented style) : kræver lidt mere arbejde
mysqli (Prepared Statements) : kræver noget mere arbejde

pdo : kræver noget mere arbejde
pdo (Prepared Statements) : kræver noget mere arbejde

set i bagklogskabens ulidlige klare lys vil jeg anbefale pdo, da man her kan skifte database uden at rette i PHP coden

set i bagklogskabens ulidlige klare lys vil jeg anbefale pdo, da man her kan skifte database uden at rette i PHP coden

Hvor tit sker det? Endnu vigtigere, hvor tit sker det i små projekter

PDO skal anbefales grundet den nemmere tilgang til prepared statements. Prep. statements lukker en del af de større sikkerhedsrisici der findes at ubehandlet værdier direkte i SQLen. Med at bruge PDO optager også en del resourcer i prod. miljøet, samt sænker hastigheden på et php script med en ret stor faktor. Igen er dette noget man sagtens kan leve med i små projekter.

Hvor tit sker det?

nogle virksomheder vil kun kører med én type db (afh intern support/kompetancer) feks mssql eller oracle eller ..., og så er det trist hvis man har udviklet til en anden db, men enig på webhoteller er mysql databasen den mest udbredte, så den bør man tilgå med enten mysqli eller PDO extension
så for at fremtids sikre sin code vil jeg anbefale PDO.

Endnu vigtigere, hvor tit sker det i små projekter

små projecter har det med at vokse sig størrer , opbygger man sin code fornuftigt vil man ofte kunne genbruge dele af det i andre sammenhæng

PDO skal anbefales grundet den nemmere tilgang til prepared statements.

det er korrekt det er nemmere at bruge prepared statements under PDO fremfor i mysqli, men nu ved jeg ikke om spørgeren vil bruge prepared statements, eller klare sikkerheden på anden måde
så jeg vil slå på fremtids sikring som argument

PDO skal anbefales grundet den nemmere tilgang til prepared statements.

Njaahh ... den vigtigste årsag til at Zend (php.net) anbefaler PDO og/eller MySQLI er, at det gamle MySQL-API er deprecated og kan ventes at udgå i en af de næste PHP-versioner.

Prep. statements lukker en del af de større sikkerhedsrisici der findes at ubehandlet værdier direkte i SQLen

Hvilke huller lukker prepared statements ikke for i dén forbindelse?

Med at bruge PDO optager også en del resourcer i prod. miljøet, samt sænker hastigheden på et php script med en ret stor faktor. Igen er dette noget man sagtens kan leve med i små projekter

Dokumentation? En af de helt store fordele ved prepared statements er jo netop, at de performer langt bedre ved gentagne kald med forskellige parametre.

I følge mysql.com og Zend (samt bunker af udviklererfaringer) er prepared statements hurtigere til visse ting, men lidt langsommere til andre. Jeg er dog ikke bekendt med, at der skulle være væsentlige situationer, hvor afviklingshastigheden er laver 'med en ret stor faktor' - men jeg ser frem til at blive gjort klogere =)

Derudover hænger afviklingshastighed ikke nødvendigvis sammen med forbrug af RAM/CPU. Der er masser af situationer, hvor et hurtigere script faktisk sluger flere ressourcer end et tilsvarende, der afvikler langsommere. Den slags er langt mere komplekst end som så.

Endelig er de sikkerhedsmæssige fordele ved brug af prepared statements så massive, at der skal rigtig mange bagdele til for at opveje fordelene.

/mvh

PDO skal anbefales grundet den nemmere tilgang til prepared statements.

Njaahh ... den vigtigste årsag til at Zend (php.net) anbefaler PDO og/eller MySQLI er, at det gamle MySQL-API er deprecated og kan ventes at udgå i en af de næste PHP-versioner.

Det er noget sludder. At sige du skal bruge en ting fordi en anden udgår er ikke en anbefaling. Det er en betingelse. At bruge PDO som alternativ til MySQLi API er en anbefaling.

Prep. statements lukker en del af de større sikkerhedsrisici der findes at ubehandlet værdier direkte i SQLen

Hvilke huller lukker prepared statements ikke for i dén forbindelse?

Forstår ikke dit spørgsmål. Men måske dit kryptiske spørgsmål er afledt, at min lige så kryptiske formulering. Jeg mener:

Prep. statements lukker en del af de større sikkerhedsrisici der findes ved at man som begynder normalt blot bruger ubehandlet værdier/data direkte i sine SQL queries. Naturligvis kan du stadig gøre dette - men så bruger du ikke prep. statements efter hensigten.

Med at bruge PDO optager også en del resourcer i prod. miljøet, samt sænker hastigheden på et php script med en ret stor faktor. Igen er dette noget man sagtens kan leve med i små projekter

Dokumentation? En af de helt store fordele ved prepared statements er jo netop, at de performer langt bedre ved gentagne kald med forskellige parametre.

Har desværre ikke længere mine benchmarks liggende. Dette var et simpelt benchmark på SELECT col FROM table LIMIT 1. Du er dog velkommen til at udføre benchmarks og modbevise min påstand.
Men... PDO er et abstractions lag der gør tilgangen lettere til MySQLi, PostGreSQL og andre DB API'er. PDO_MYSQL kunne tidl. ikke fungere uden at du installere MySQL driveren. Jeg kan dog se at PDO er blevet udvidet. Dog som ekstra note, kan du også koble PDO sammen med PHPs egen MySQLind driver.
Da PDO er et abstractions lag, ligger der naturligvis en masse ekstra kode til behandling af dine queries. Endvidere i og med at du bruger et entry point, $pdo->query() til at eksekvere SQL til MySQL, PostGre m.fl. sker der behandling/parsing af SQL queries før disse bliver sendt til den respektive DB for udførelse. Øget brug af RAM hænger sammen med at jo mere kode du indlæser i PHP, des mere RAM skal benyttes.

I følge mysql.com og Zend (samt bunker af udviklererfaringer) er prepared statements hurtigere til visse ting, men lidt langsommere til andre.

Enig, prepared statements er hurtigere. Det skyldes at prep. statements parses og lægges i mem. Der er dog væsentlig hastighedsforskel på et prep. statement udført via PDO eller direkte med f.eks. MySQLi driveren. Årsagen kan læses i tidl. afsnit.

Derudover hænger afviklingshastighed ikke nødvendigvis sammen med forbrug af RAM/CPU. Der er masser af situationer, hvor et hurtigere script faktisk sluger flere ressourcer end et tilsvarende, der afvikler langsommere. Den slags er langt mere komplekst end som så.

Jeg har efterhånden skrevet en del optimeringskode, så jeg er helt med på hvad du snakker om. I de fleste tilfælde, så er hastighed noget du vinder på bekostning af RAM. Og frigør du RAM, sænker det typisk hastigheden - fordi du da skal gemme din data oftere. Men i nogle enkeltstående situationer vinder du både hastighed og RAM.

Endelig er de sikkerhedsmæssige fordele ved brug af prepared statements så massive, at der skal rigtig mange bagdele til for at opveje fordelene.

Enig.

Det er noget skvadder

Ja, det er jo derfor, jeg skriver, at du tager fejl. Zend skriver larmende tydeligt:

It is recommended to use either the mysqli or PDO_MySQL extensions

- og som vi jo alle ved, betyder "to recommend" at anbefale. Jeg går udfra, vi er enige om, det hermed er tydelig konstateret, hvem der 'skvadrer' i denne tråd. De siger ikke, du skal bruge noget andet - men skriver klart og tydeligt, at de anbefaler PDO eller MySQLI. (kilde) *o)

Prep. statements lukker en del af de større sikkerhedsrisici der findes ved at man som begynder normalt blot bruger ubehandlet værdier/data direkte i sine SQL queries.

Jeg efterlyser bare de huller, prepared statements ikke lukker. Du skriver "en del", så du må vel mene, der er sikkerhedsrisici ved ubehandlet værdier/data, brugt direkte i SQL queries, som prepared statements ikke imødegår. Hvilke?

Jeg er ikke rigtig klar over, om du 'skvadrer' videre her, men når du skriver:

PDO MySQLi, kan ikke fungere uden at du installere MySQLi driveren

- ved jeg ikke, hvad du mener. MySQLI har ikke noget med PDO at gøre. PDO kan forbinde til MySQL - men ikke igennem MySQLI

Til dine betragtninger vedr. performance, henholder jeg blot til mysql.com, Zend og egne (og såmænd også andres) erfaringer: I rigtig mange situationer er prepared statements (PDO eller MySQLI) væsentligt hurtigere end det gamle MySQL-API. I andre situationer er det marginalt langsommere. Med PDO får man tilmed det klasselag forærende, som mange skriver i alm. langsom, fortolket PHP-kode.

Men i nogle enkeltstående situationer vinder du både hastighed og RAM.

Helt korrekt - og der er da ingen, som kan garantere, vi ikke kommer til dén diskusion en dag. I nærværende tråd kan vi dog nøjes med de forhold, som gør sig gældende for de situationer, vi taler om her.