[PHP] Opzet van een nieuw PHP script... Tips nodig...

[Saeverix]

Hallo,

Ik ben bezig om voor mijn site een CMS te schrijven... Puur en alleen voor mijzelf, dus het hoeft niet heel erg uitgebreid en supergebruiksvriendelijk.

Ik heb bedacht om gebruik te maken van MYSQL om daarin alle pagina's en portfolio items in op te slaan. Hier verwacht ik ook geen problemen mee.

Alleen zit ik meer met het feit hoe ik het zal opbouwen (niet qua uiterlijk, maar qua coding). En dan zit ik met name met het volgende: Proberen om alles in 1 script te houden? Of voor elk deel van het CMS een apart script maken?

Ik heb hier nog geen ervaring mee, dus ik dacht laat ik eens vragen wat gelijk de meest nette en makkelijkste oplossing is...

Wat is aan te raden?

• Eén pagina voor het hele CMS (index.php)
• Of voor elk deel van het CMS een aparte pagina zoals: index.php, paginas.php, portfolio.php etc...

Kan iemand mij dit proberen uit te leggen, en dan vooral waarom het op die manier beter is...

Alvast bedankt!

[Verwijderd]

Ik zou het niet zo op een pagina per script houden, want heel veel onderdelen zul je toch onderling delen. Verder gebruiken veel CMS-en het zogenaamde 'MVC' (method view controller) patroon, zoek daar eens naar en kijk hoe andere cms-en het doen .

[Gomez12]

Voor elke functionele entiteit een ander script maken.

Php kent gewoon een include functie dus je maakt dan gewoon een index pagina die de benodigde functionaliteit include.
Op het moment dat je echt compleet andere functionaliteit als hoofdactiviteit op een pagina gaat gebruiken dan zou ik het weer gaan afsplitsen naar een nieuw view-bestand ( die weer functionaliteit include )...

Dingen als een ubb-parser / captcha wil je maar 1x in code hebben staan.

[Saeverix]

Heb eens zitten kijken bij de MVC (Model View Controller) maar op die manier word het wel erg complex voor een beginnende PHPer... Of heb ik dan op de verkeerde sites gekeken?

En voor de rest wil ik niet echt naar andere cms-en kijken, omdat ik die allemaal niets vind. Te log en uitgebreid...

Mijn doel is een simpele admin om Pagina's te toevoegen/wijzigen/verwijderen... En tegelijkertijd ook het menu automatisch te wijzigen als er een pagina bijkomt of verwijderd wordt.
Dit zelfde gaat gelden voor het Portfolio gedeelte, maar dan een iets andere opzet.

Maar het gaat erom dat ik de basis goed heb... En dat ik er later gewoon aan verder kan knutselen en uitbreiden zonder dat ik halverwege alles opnieuw moet doen.
Aangezien ik niet ervaring heb met het maken van "grote" scripts vraag ik dus om wat Do's en Dont's...

[dev10]

Kijk eens naar een framework als CakePHP (http://www.cakephp.org) of CodeIgniter (http://www.codeigniter.com/). CodeIgniter is mijn persoonlijke favoriet als framework. Op de website van CodeIgniter staat een basis video-tutorial voor een weblog-applicatie. Als je dit iets verder uitbreidt zit je al bijna op een simpel CMS. En met de documentatie van CodeIgniter kom je heel ver.

(CakePHP en CodeIgniter zijn wel allebei gebaseerd op MVC, maar ik vind het, met name voor een CMS, een hele relaxte manier van werken.)

[Alain]

Ik gebruik tegenwoordig 1 bestand om alle algemeen benodigde objecten aan te maken en de gevraagde actie te starten. Vroeger maaktte ik voor elke actie een bestand die hetzelfde 'header' bestand gebruiktten. Mijn motivatie om tegenwoordig 1 bestand te gebruiken is omdat ik het handig vind om alle algemene zaken in 1 bestand te regelen.

Ik denk niet dat je kunt spreken over een betere manier. Zolang je een duidelijke en reeele motivatie hebt om een bepaalde werkwijze te hanteren, is er niks mis.

[Saeverix]

Zo'n Framework ziet er erg makkelijk uit, maar van het echte PHP is niet heel veel meer over...
Aangezien ik toch zelf meer handigheid in PHP en MySQL wil krijgen ga ik denk ik toch voor mijn eigen opzet...

Ik begin ook al een beetje een idee te krijgen hoe dat MVC werkt, maar het lichtje is nog niet helemaal gaan branden...

[YopY]

quote: Werner

Zo'n Framework ziet er erg makkelijk uit, maar van het echte PHP is niet heel veel meer over...

Is nog steeds evenveel PHP hoor, alleen dan eenvoudiger (lees: veel voorkomende functionaliteit zoals het ontvangen / verwerken van requests, databasecommunicatie e.d. is minder code / geregel voor nodig) . Volgens mij gaat elke beginnende PHP-er wel met een eigen CMS en dergelijke bezig, en dat is verder niet erg enzo, zolang je er maar niet teveel tijd aan besteed of gaat denken dat je een geweldig iets neergezet hebt - en het vervolgens op internet gaat zetten als voorbeeld van anderen.

Voor het probleem zelf zou ik twee dingen doen:

* Een PHP bestand per pagina-onderdeel (krijg je files als index.php, portfolio.php, etc)
* Een PHP bestand per applicatie-onderdeel (een php voor de databaseverbinding en eventuele queries, eentje voor een BBCode parser, etc)

Dat is redelijk te bevatten, lijkt me. MVC en dergelijke is leuk en handig en weet ik veel wat nog meer, maar als je geen of weining verstand hebt van de taal zelf, de ideeen achter de techniek, objectgeoriënteerd programmeren etc, kom je niet veel verder.

[Cartman!]

Kijk eens naar Zend Framework, volledig MVC te gebruiken en een geweldige library aan code. Het grote voordeel boven CakePHP en CodeIgniter is dat je niets hoeft te installeren of configureren oid. Je bent vrij in welke componenten je gebruikt en hoe.

Meer info op http://framework.zend.com

[Saeverix]

Ben zelf maar eens begonnen iets te bedenken... Frameworks wil ik sowiezo nog even overslaan aangezien ik zoveel mogelijk wil leren van PHP en MySQL. Daarna kan ik altijd nog "lui" worden en gebruik gaan maken van Frameworks

Ik heb nu 1 aanspreekpunt: index.php
Hierin heb ik een switch zitten die kijkt naar bijvoorbeeld ?page= om de juiste pagina te includen.
Verder heb ik natuurlijk ook de header en footer als include file...

Alle functies heb ik in "functions.php" waarmee ik alles kan oproepen.
Ik heb alleen voor het wijzigen en invoeren van Database info gekozen voor 2 aparte files. Namelijk "edit.php" en "add.php". Weet niet of dat een logische keuze is, maar het maakte het allemaal wel gemakkelijker vond ik... (ivm. het meesturen van informatie zoals bijvoorbeeld ?page)

Voor de rest ben ik nog aan het coden... Maar het begint er aardig als een CMS uit te zien inmiddels.

Als jullie na het lezen van dit verhaaltje nog tips hebben hoor ik dat natuurlijk graag.

[harrald]

Ik zelf werk met een template systeem ( smarty ).
Op deze manier houd je de code en de html compleet gescheiden van elkaar. Dit zorgt dus voor overzichtelijke code en overzichtelijke html.
Nog belangrijker het is zeer makkelijk te leren. Ik programmeer zelf nog maar een maand of 2 php.

Ik maak gebruik van een php bestand loader.php waar ik al mijn classes en database connectie include. Deze loader.php kan je dan weer gemakkelijk includen in bijv je index.php of een andere pagina.

In het geval van een cms maak ik een secure.php hier check ik of de user ingelogd is. zoja ->include loader.php zo nee -> stuur de gebruiker door naar login.php. Deze secure.php include je in al je php files als index.php enz. ( loader hoeft dus niet meer speciaal geinclude te worden)

Dit zet een mooie basis voor relevante code in je php files. Logisch vervolg is object georienteerd programmeren.

Op deze manier werken helpt mij om veel van mijn code te hergebruiken, en vooraal de boel overzichtelijk te houden.

Wat dingen om op te googelen/handige links:
sessionstart()
smarty
voorbeeld inlog script
Ik zou idd eerst zo ver mogelijk weg blijven van allerlei kant en klare oplossingen, je leert het meest door alles zelf uit te proberen.

[ Voor 14% gewijzigd door harrald op 29-09-2008 21:42 ]

[Verwijderd]

Cartman! schreef op maandag 22 september 2008 @ 23:13:
Het grote voordeel boven CakePHP en CodeIgniter is dat je niets hoeft te installeren of configureren oid.

bij CodeIgniter moet je toch ook niets installeren? enkel de php-bestanden van CodeIgniter uploaden, een klein beetje configureren (gegevens voor je database, startuppagina) en het is klaar voor gebruik.

[flashin]

Ik zelf werk met een template systeem ( smarty ).
Op deze manier houd je de code en de html compleet gescheiden van elkaar. Dit zorgt dus voor overzichtelijke code en overzichtelijke html.
Nog belangrijker het is zeer makkelijk te leren. Ik programmeer zelf nog maar een maand of 2 php.

Smarty ja, overkill ftw. Heel veel mensen zweren erbij, maar waarom zou je in een parser (die PHP uiteraard is) NOG een parser gaan gebruiken die in feite niet zo heel veel doet (maar wel relatief veel load veroorzaakt).

Ik zou kijken naar MVC of een andere denkwijze gebruiken om je programma in te ontwikkelen.

[wackmaniac]

flashin schreef op dinsdag 30 september 2008 @ 10:31:
[...]
Smarty ja, overkill ftw. Heel veel mensen zweren erbij, maar waarom zou je in een parser (die PHP uiteraard is) NOG een parser gaan gebruiken die in feite niet zo heel veel doet (maar wel relatief veel load veroorzaakt).

Misschien vanwege de cache-functionaliteit die er kant en klaar al aardig inzit?

Maakt verder ook niet zoveel uit of je Smarty gebruikt of gewoon een bak met php-bestanden aanwijst als templates aanwijst en daar uitsluitend zaken mee toont.

flashin schreef op dinsdag 30 september 2008 @ 10:31:
Ik zou kijken naar MVC of een andere denkwijze gebruiken om je programma in te ontwikkelen.

Nog een mooie reden om Smarty te gebruiken: een duidelijke scheiding tussen view en model / controller.

[ Voor 25% gewijzigd door wackmaniac op 30-09-2008 14:02 ]

[Verwijderd]

harrald schreef op maandag 29 september 2008 @ 21:34:
*knip*
voorbeeld inlog script
*knip*

Voorbeeld lijkt me niet heel er serieus te nemen, als er in een "Een veilig login systeem met sessies" die niet voor beginners bedoeld is al hééél erg basic SQL injecties zitten,....

Zelf gebruik ik voor al mijn opdrachten een zelf ontwikkeld "framework" dat ik in de loop van de jaren steeds verbeterd en voor een groot deel opnieuw geschreven heb. Hiermee kan ik elk systeem dat ik wil in een lege versie gooien met een ingebouwde login.

Hier maak ik gebruik van een index.php die altijd aangeroepen wordt, hier komen de standaard dingen in als classes, databaseverbindingen, e.d. Verder maak ik mapjes per onderdeel, bijv. voor cms:

code:

./pages/
        cms/
            index.php
            toevoegen.php
            wijzigen.php
            verwijderen.php

Deze worden dan in een array gepleurt:

PHP:

$page['cms']['']              = './pages/cms/index.php';
$page['cms']['toevoegen']     = './pages/cms/index.php';
$page['cms']['wijzigen']      = './pages/cms/wijzigen.php';
$page['cms']['verwijderen']   = './pages/cms/verwijderen.php';

Deze worden dan geinclude op de volgende manier:

PHP:

if (file_exists($page[$_GET['var1']][$_GET['var2']]))
{
    include($page[$_GET['var1']][$_GET['var2']]);
}

Bijv.: http://localhost/site/beheer/cms/toevoegen/. Waar de $_GET-variabelen geset worden dmv een .htaccess.

Verder moet je ook opletten op beveiliging, hier gebruik ik een zelf gemaakte class voor die in de index.php aangeroepen wordt, hier zal ik verder niet op in gaan, dan wordt het een beetje lange post. Mocht je daar tips/voorbeelden van willen zien dan kan ik dat evt. wel posten.

Ook erop letten dat je in de pagina's iets maakt waardoor ze niet direct aan te roepen zijn, hiervoor gebruik ik een constante die ik een waarde geef in de index.php en in de bestanden check ik of deze correct is.

Hier heb ik al vele systemen mee gemaakt en het werkt voor mij sneller, qua ontwikkelen, dan CodeIgniter, daar heb ik ook al een keer een projectje mee gedaan, maar dat vind ik persoonlijk toch niks en zal ik ook niet snel weer gaan gebruiken.

Dit zelfde principe gebruik ik voor de voorkant. maar dan met want andere classes e.d.

Succes ermee, deze ga ik in de gaten houden.

[moozzuzz]

Ikzelf werk ook steeds met een centrale index.php die dan een config en enkele ondersteunende standaard-functies laadt. Daarna wordt de gevraagde pagina/actie opgebouwd/uitgevoerd (zie ook post GuidoH ivm .htaccess)

code:

./config.inc
./index.php
./modules/
./support.inc

In de huidige vorm (maar ben aan 't bedenken of dit verbeterd kan worden) worden er modules geladen die alle acties en alle ondersteunende functies bevatten. Deze modules beslissen op basis vd get-aprameters wat ze moeten uitspoken (edit, show, add, remove, whatever). Elke module is één bestand.

code:

./modules/news.inc
./modules/wusers.inc

Ik ben nu aan 't denken om de modules op te splitsen in logica die de get verder interpreteert en op basis daarvan een "actie"functie laadt en een (apart) module-support-bestand met de acties.

code:

./modules/news.inc
./modules/news.support.inc
./modules/wusers.inc
./modules/wusers.support.inc

De oplossing van GuidH vind ik ook wel leuk, maar er moet dan ook steeds nog een "ondersteunende subacties"bestand zijn denk ik:

code:

./modules/news.inc          // logica op basis van url/database/...
./modules/news.show.inc     // tonen
./modules/news.add.inc
./modules/news.remove.inc
./modules/news.edit.inc
./modules/news.list.inc
./modules/news.react.add.inc
./modules/news.general.inc  // alle news-typische ondersteunende functies

bookmarked :^p

[prototype]

Kortste reply in dit topic: Symphony of een andere Rails clone ;-)

[Verwijderd]

Ik heb op dit moment de classes die ik gebruik in aparte map zitten:
./inc/classes/cms.inc.php

code:

./modules/news.inc          // logica op basis van url/database/...
./modules/news.show.inc     // tonen
./modules/news.add.inc
./modules/news.remove.inc
./modules/news.edit.inc
./modules/news.list.inc
./modules/news.react.add.inc
./modules/news.general.inc  // alle news-typische ondersteunende functies

Zou je eens toe kunnen lichten wat er dan in news.inc en news.general.inc zou komen?

Het is misschien nog wel overzichtelijker om het in een mapje te gooien, dan krijg je als je 10 modules er in hebt niet 100 bestanden daar in, maar 10 mapjes.

Waar wij binnenkort een begin aan gaan maken is een multi-user(/multi-site) CMS, waar een admin gebruikers aan kan maken en hier vervolgens module's aan kan koppelen. Dat gaat waarschijnlijk via dit principe, maar dan nog net even een stapje verder.

[AW_Bos]

Laat ik dan ook maar even met de deur in dit topic vallen. Ik ben namelijk ook bezig met een eigen CMS.
het is nog niet volledig op OOP gebaseerd, maar dat zal wel een keertje gaan komen...

Mijn CMS kent verschillende modules, die gewoon een simpel php-bestand zijn die in de webroot staan. contact.php, page.php, webshop.php en vaak te openen zijn (apache configuratie) zonder de extentie.

Nu gebruik ik Multiviews voor de prachtige URL opbouw, net als GoT hier gebruikt.
De pagina uit de page-module staan gewoon in de database geplaatst met 2 mogelijke opties:
Toon in het menu, volgorde in het menu....

Verder wordt de hele layout geregeld door middel van een handige template-parser die van Smarty afgeleid is (een fork dus) met de naam Template Lite. Deze schijnt sneller te zijn dan Smarty...

Misschien kan dit wat inpiratie geven voor de bouw van een eigen CMS.

---

@guidoh. Ik hoop dat je wel .php als extentie gebruikt voor de modules of dat je ze buiten de webroot hebt staan. Want anders is de broncode snel te downloaden van de modules .

[ Voor 8% gewijzigd door AW_Bos op 30-09-2008 18:29 ]

[Verwijderd]

Ariën Clay schreef op dinsdag 30 september 2008 @ 18:28:
@guidoh. Ik hoop dat je wel .php als extentie gebruikt voor de modules of dat je ze buiten de webroot hebt staan. Want anders is de broncode snel te downloaden van de modules .

Dat gedeelte met .inc is een quote, gebruik zelf altijd .php.

offtopic:
Elishaaa...

[ Voor 3% gewijzigd door Verwijderd op 30-09-2008 18:34 ]

[moozzuzz]

Verwijderd schreef op dinsdag 30 september 2008 @ 17:55:
Zou je eens toe kunnen lichten wat er dan in news.inc en news.general.inc zou komen?

De mapjes was ik ook aan 't denken :^), maar dat is een detailke hé.

news.inc
--> systeempje dat je $_GET of $_POST interpreteert en afhankelijk daarvan een "actie" uitvoert, wellicht een switch oid in combi met een check of

news.general.inc
vnl i/h bij de admin-acties zijn er vaak herbruikbare dingetjes te bedenken (zoals lijstjes) die in verschillende acties/schermen terugkomen. Ik heb dan snel de neiging om daar snel iets generieks voor te maken zodat ik dat in de verschillende acties gewoon kan oproepen. Voor een nieuws-sectie zou ik kunnen denken aan een klein functie-tje dat je string elegant afknipt op een bepaalde maximum-lengte.

Noteer wel: mijn projectjes zijn ver van professioneel hé ;^)

[Gomez12]

Verwijderd schreef op dinsdag 30 september 2008 @ 17:55:

Waar wij binnenkort een begin aan gaan maken is een multi-user(/multi-site) CMS, waar een admin gebruikers aan kan maken en hier vervolgens module's aan kan koppelen. Dat gaat waarschijnlijk via dit principe, maar dan nog net even een stapje verder.

Geinteresseerd, wat is het stapje verder?
Want multi-users bouw ik op dit moment op dezelfde manier op als single-users alleen hebben de modules rechtenchecks erin zitten.
In het meest extreme geval leidt dit tot het inladen van 100 modules die vanwege de rechtenchecks toch geen view / logica gedeelte hebben. Maar qua code is dan wel alles eenduidig.
Alleen leidt dit soms tot kleine view-bugs als : iemand mag wel posts viewen maar geen posts quoten, qua view is dit dezelfde actie dus zit er ook een quote knopje in. De logica erachter is alleen niet aanspreekbaar...

[Verwijderd]

Gomez12 schreef op dinsdag 30 september 2008 @ 21:05:
[...]

Geinteresseerd, wat is het stapje verder?
Want multi-users bouw ik op dit moment op dezelfde manier op als single-users alleen hebben de modules rechtenchecks erin zitten.
In het meest extreme geval leidt dit tot het inladen van 100 modules die vanwege de rechtenchecks toch geen view / logica gedeelte hebben. Maar qua code is dan wel alles eenduidig.
Alleen leidt dit soms tot kleine view-bugs als : iemand mag wel posts viewen maar geen posts quoten, qua view is dit dezelfde actie dus zit er ook een quote knopje in. De logica erachter is alleen niet aanspreekbaar...

Het gaat dan meer om multi-user backend, dus dan worden er een aantal modules toegevoegd, laten we als voorbeeld even zeggen dat de volgende module's aanwezig zijn:

• Pagina's
• Webshop
• Gastenboek

Dan maak ik als admin voor Pietje van BedrijfX een nieuwe gebruiker aan, hier activeer ik dan "Pagina's" en "Gastenboek" voor. Nu logt Pietje in en op dat moment wordt er gekeken welke module's hij mag gebruiken, deze worden dan ingeladen. De overige module's wordt niks mee gedaan als hij hier geen rechten voor heeft.

Hij kan daar nu dus gebruik van maken. Op het moment dat hij ook een webshop wil hebben, is het voor de admin enkel een kwestie van rechten geven op de module "Webshop". Het voordeel hiervan is dat er voor simpele site's zonder meerwerk, in enkele uren een compleet werkende site. Ook heb je dan op het moment dat er bugs in zitten of dergelijke, dat dit zodra het opgelost is gelijk voor elke gebruiker doorgevoerd is.

Technisch heb ik hier al het een en ander voor gemaakt, gebaseerd op het eerder uitgelegde systeempje, enkel het inladen van module's en het inloggen zijn ingrijpend veranderd.

Het gaat dus niet om dat ook Sjaak van BedrijfX in kan loggen, die dan andere dingen kan. Dit is misschien in later stadium ook wel interessant, maar nu gaat het er meer om dat Kees van BedrijfY ook een site via het zelfde systeem kan beheren, met andere module's.

En dan komen er altijd extra module's die een klant wil als meerwerk, bijv. een facturatie-systeempje als uitbreiding van de webshop, op het moment dat we deze gemaakt hebben voor BedrijfY, kunnen we deze voor BedrijfX ook activeren.

Zoals ik het nu doe moet ik dan deze mapjes en bestanden kopieren naar andere site en hier helemaal in implementeren, het is de bedoeling dat dit hiermee met een simpel knopje geactiveerd kan worden door de admin.

Hoe dit verder technisch in z'n werk gaat heb ik al redelijk ver uitgedacht en al deels uitgewerkt.

[ZanomiX]

Ik zou, om het allemaal basic te houden, opteren voor een include systeem met één index pagina. Zo hoef je niet steeds je lay-out aan te passen. Je kan ook natuurlijk verschillende pagina's maken en hierin je lay-out includen, maar dat zou nogal vreemd zijn . Die switch zou ik weglaten, zo maak je het enkel maar dynamischer...

[Saeverix]

ZanomiX schreef op woensdag 01 oktober 2008 @ 15:30:
Ik zou, om het allemaal basic te houden, opteren voor een include systeem met één index pagina. Zo hoef je niet steeds je lay-out aan te passen. Je kan ook natuurlijk verschillende pagina's maken en hierin je lay-out includen, maar dat zou nogal vreemd zijn . Die switch zou ik weglaten, zo maak je het enkel maar dynamischer...

Die switch gebruik ik om het veiliger te houden. In plaats van include('$_GET[page]'); zoals jij denk ik in je hoofd hebt... Ook heb ik in de switch een default: opgegeven, zodat hij bij een willekeurige andere pagina aanvraag automatisch naar de home pagina gaat.

Mochten ze op een of andere manier erachter komen welke files er nog meer op mijn server staan dan kunnen ze die op de standaard include manier heel gemakkelijk includen wat niet helemaal de bedoeling is...

Tenzij je een oplossing heb waar ik niet aan gedacht heb...

Maar inmiddels is mijn scriptje al dermate opgebouwd dat ik me er al aardig mee kan redden... En volgens mij nog redelijk overzichtelijk ook.

[Niekk]

voor pagina's kan je ook overwegen meteen een cache in te bouwen.

PHP:

<?php
$paginas = array(); // in deze array zet je de pagina's die toegestaan zijn, deze array haal je bijvoorbeeld uit een db

if(in_array($_GET['p'], $paginas)) { // als de pagina aangeroepen mag worden
    if(cache_exists($_GET['p']) && cache_time($_GET['p']) < 300) { // als er een cache te vinden is, EN als die minder als 300 sec oud is
        show_cache($_GET['p']);
    } else {
        include 'paginas/'.$_GET['p'].'.php';
    }
}
?>

Dit is een voorbeeld met functies. Persoonlijk zou ik een class gebruiken, maar een class voorbeeld maken kost nu even te veel tijd.
$_GET['p'] is in dit geval dus een soort van pagina ID. Bedenk wel dat iedere pagina een eigen ID moet hebben. Dus bijvoorbeeld index.php?p=blogPage<nummer> . Dit geeft je dan de mogelijkheid om voor iedere pagina een eigen cache te houden. Eventueel kan je de include op regel 8 dan net iets anders doen, zodat je voor een blogPage gewoon blogPage.php hebt, en die een ID mee geeft en dat die ID dan uit de database wordt geplukt. Anders krijg je voor ieder artikel een aparte PHP pagina. Je kan anders ook een tweede get parameter maken met het ID. Dus bijvoorbeeld index.php?p=blogPage&id=4567876543

Ik hoop dat dit nuttig was

Success verder !