[PHP] Hedendaags website bouwen met eigen code

[RobbyTown]

Even een korte intro. Jaren terug ooit mijn eigen website gebouwd. Deze werkte op Templatepower en PHP. Zo was PHP en HTML/CSS mooi van elkaar gescheiden (wat phpbb ook gebruikt).

Dit is allemaal nog uit de tijd van phpfreakz, webfanaat, wmcity, sitemaster, phpxp (de oude garde kent die sites wel )

PHP is doorontwikkeld en mijn oude website code werkt dus niet meer anno 20019 . Om alles aan te passen kan ik denk alles opnieuw opbouwen.

Al een tijdje gebruik ik Wordpress (lekker makkelijk) met een template en die een beetje aangepast. Hoewel Wordpress prima werkt en ik 80% van de functies/code niet benut en om het naar de hand te zetten vele plugins (nadeel van veel plugins is dat wordpress dan toch een stukje trager word) nodig heb wil toch graag mijn eigen 'code' maken.

Nadeel van Wordpress is wat eigen dingen kun je minder makkelijk in wordpress bouwen. Denk aan de dodenherdenking, dan heeft Tweakers een speciale pagina voor 1 of 2 min...

Mijn vraag
Wat is tegenwoordig een goede (geen mega uitgebreide zoals smarty, smarty is denk ik ook te oud aangezien ik veel oude topics vind) template parser?

Wat ik al gevonden of geprobeerd heb
https://www.minatica.be/c...ml-en-php-code-(geen-OOP)
Geen idee als dit nog goed is, is ook al bijna 10 jaar oud..., eigenlijk zo oud als mijn code....

[Nivali]

Wellicht niet alleen bij een template engine houden maar een compleet framework als laravel bijvoorbeeld? Disclaimer; zit zelf ook al jaren niet meer in het PHP wereldje maar enkele jaar terug was Laravel nog wel hip.

[Josk79]

Twig is een mooie template engine. Tip: gebruik composer om packages te installeren (composer require "twig/twig:^2.0").

[DJMaze]

RobbyTown schreef op woensdag 17 april 2019 @ 19:18:
Wat is tegenwoordig een goede (geen mega uitgebreide zoals smarty, smarty is denk ik ook te oud aangezien ik veel oude topics vind) template parser?

Twig en TAL zijn eigenlijk anno 2019 de varianten waar je naar moet kijken.

Ik ben zelf overgestapt op TAL en heb hiervoor mijn eigen PHP code geschreven omdat ik PHPTAL traag vind en de oorspronkelijke Zope TAL is natuurlijk niet in PHP.
De mijne is op basis van PHP's XMLReader en PHPTAL is op basis van DOMDocument

Ik heb natuurlijk naar beiden gekeken en van beide de voor/nadelen goed tegen elkaar afgewogen.
Hier staat in simpele woorden het resultaat: https://dragonflycms.org/Forums/viewtopic/t=25487.html
Daar staat ook een stukje over Smarty en hoe ik een mega project met Smarty heb omgevormd naar TAL.

[ Voor 14% gewijzigd door DJMaze op 17-04-2019 20:00 ]

[Xantios]

Wil je echt een template engine en niks anders ? Dan zou ik voor twig gaan.

Gezien je zelf al aangeeft dat je een website wilt hebben, kijk ook zeker naar Laravel.

Al zou wordpress eigenlijk ook wel moeten voldoen voor de meeste zaken, wat zijn de specifieke dingen waar je tegenaan loopt?

[Hiroj]

Xantios schreef op donderdag 18 april 2019 @ 01:18:
Wil je echt een template engine en niks anders ? Dan zou ik voor twig gaan.

Gezien je zelf al aangeeft dat je een website wilt hebben, kijk ook zeker naar Laravel.

Al zou wordpress eigenlijk ook wel moeten voldoen voor de meeste zaken, wat zijn de specifieke dingen waar je tegenaan loopt?

Vergeet niet dat Laravel een eigen template engine heeft genaamd Blade.

Laravel is - wanneer je basis OOP begrijpt - onwijs prettig om mee te werken. Een website in elkaar zetten is dan ook zo gepiept.

[Low-Tech]

Een hele andere optie die misschien het overwegen waard is: blijf WordPress gebruiken maar dan puur als CMS. Maak gebruik van de WP API om een headless frontend te bouwen, dan heb je de volledige vrijheid in de frontend ook qua taal.

[Josk79]

Welke functionaliteit wil je in je website? Wil je bestaande code zoveel mogelijk hergebruiken?

[reddevil]

Ligt er een beetje aan inderdaad wat je wil. Ik heb een eenvoudige website gemaakt (zo goed als statische content, geen config) met https://github.com/klein/klein.php en twig templates. Supersnel

[RobbyTown]

Josk79 schreef op donderdag 18 april 2019 @ 09:38:
Welke functionaliteit wil je in je website? Wil je bestaande code zoveel mogelijk hergebruiken?

Daar is geen beginnen aan denk ik aangezien templatepower in de start post niet meer werkt. Op de huidige PHP versie 7. Als dat wel werkte kon ik heel de code grote delen hergebruiken. Hoog uit wat PHP functie aanpassingen die niet meer werken onder versie 7.

De link van minatica is ongeveer de code/structuur hoe de website is gebouwd maar dan met template power. Maar goed die codes zijn alle 2 10 jaar oud.

Wordpress is meer blog gericht. Ik gebruik nu enkel de pagina functie. Het is vooral static pagina (dus een admin panel en connectie met de db is niet hard nodig) af en toe komt er wat bij op de portfolio pagina en stukje over mij zal wat veranderen. Dit kan door kwestie van de .tpl file aan te passen.

[Xantios]

Hiroj schreef op donderdag 18 april 2019 @ 08:28:
[...]

Vergeet niet dat Laravel een eigen template engine heeft genaamd Blade.

Dit is mij bekend.
bedoelde het als een of/of ... Of gebruik Twig, of gebruik Laravel (dus met blade)

Overigens, als je het graag wilt kun je ook Twig gebruiken in Laravel (geen idee waarom je dat precies zou willen, maar het kan)

[BernardV]

@RobbyTown Je zegt dat de TemplatePower code niet meer werkt, dat klopt, maar is heel makkelijk op te lossen.

Als je hier de laatste versie download: http://templatepower.codocad.com/download.php
Dan open je het bestand "class.TemplatePower.inc.php"
Op regel 64 en 409 vervang je '__contruct' door '__construct'
Op regel 407 vervang je de functienaam 'TemplatePower' door '__construct'

Dan werkt het ook onder php7 zonder foutmelding met de simple.tpl die op de site staat.

Getest:

PHP:

<?php
include_once('class.TemplatePower.inc.php');

$tpl = new TemplatePower('simple.tpl', T_BYFILE);
$tpl->prepare();

$tpl->assign('name','Ron');

$tpl->printToScreen();

Resultaat:

code:

~/Downloads/TemplatePower3.0.2.1 $ php test.php && php -v

<html>
<head>
  <title>Simple Template Example</title>
</head>
<body>
  <H2>Welcome Ron!</H2>
</body>
</html>

PHP 7.2.13 (cli) (built: Dec  7 2018 10:41:23) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.2.13, Copyright (c) 1999-2018, by Zend Technologies

[ Voor 41% gewijzigd door BernardV op 18-04-2019 13:47 ]

[Barryvdh]

Xantios schreef op donderdag 18 april 2019 @ 13:11:
[...]


Dit is mij bekend.
bedoelde het als een of/of ... Of gebruik Twig, of gebruik Laravel (dus met blade)

Overigens, als je het graag wilt kun je ook Twig gebruiken in Laravel (geen idee waarom je dat precies zou willen, maar het kan)

Omdat je liever Twig gebruikt? Wij gebruiken Twig binnen groot deel van onze Laravel projecten.
(Maar tegenwoordig is Blade ook best prima, alleen is die minder strikt met code in je templates)

[Xantios]

Barryvdh schreef op donderdag 18 april 2019 @ 14:20:
[...]

Omdat je liever Twig gebruikt? Wij gebruiken Twig binnen groot deel van onze Laravel projecten.
(Maar tegenwoordig is Blade ook best prima, alleen is die minder strikt met code in je templates)

Snap best dat je Twig fijner vind ( sterker nog, ik ben het volledig met je eens) maar omdat Blade al in het framework ingebakken zit ben ik wat terughoudend om het te vervangen voor Twig.

Maar als het een legitieme optie is, dan trap ik Blade vandaag nog de deur uit.
Snap nu overigens wel waarom de DebugBar twig ondersteuning heeft

Gelukkig bouw ik voornamelijk API's, dus echt veel heb ik met Blade niet te maken.

[Hydra]

RobbyTown schreef op donderdag 18 april 2019 @ 12:57:
Wordpress is meer blog gericht. Ik gebruik nu enkel de pagina functie. Het is vooral static pagina (dus een admin panel en connectie met de db is niet hard nodig) af en toe komt er wat bij op de portfolio pagina en stukje over mij zal wat veranderen. Dit kan door kwestie van de .tpl file aan te passen.

Waarom dan niet gewoon een static site generator die vanuit AsciiDoc of Markdown je site genereert? Gebruik ik ook voor m'n blog.

[Barryvdh]

Xantios schreef op donderdag 18 april 2019 @ 14:27:
[...]


Snap best dat je Twig fijner vind ( sterker nog, ik ben het volledig met je eens) maar omdat Blade al in het framework ingebakken zit ben ik wat terughoudend om het te vervangen voor Twig.

Maar als het een legitieme optie is, dan trap ik Blade vandaag nog de deur uit.
Snap nu overigens wel waarom de DebugBar twig ondersteuning heeft

Gelukkig bouw ik voornamelijk API's, dus echt veel heb ik met Blade niet te maken.

Om eerlijk te zijn ben ik nog niet helemaal 100% happy met de TwigBridge hoor, moet de upgrade naar V2 nog keer goed afronden, maar weinig tijd helaas.

[veltnet]

Waarom gebruik je PHP zelf niet als template taal? Waarom zou je uberhaupt een aparte taal/markup nodig moeten hebben voor templates?

[Compizfox]

veltnet schreef op donderdag 18 april 2019 @ 15:23:
Waarom gebruik je PHP zelf niet als template taal?

Omdat PHP niet geschikt is daarvoor. (ja, ik weet dat PHP is begonnen als templatetaal, maar anno nu is het daar niet geschikt voor)

Waarom zou je uberhaupt een aparte taal/markup nodig moeten hebben voor templates?

Omdat je business logic en presentatie wilt scheiden en je een taal nodig hebt om die verschillende eisen die dat oplevert te ondervangen.

[CH4OS]

veltnet schreef op donderdag 18 april 2019 @ 15:23:
Waarom gebruik je PHP zelf niet als template taal? Waarom zou je uberhaupt een aparte taal/markup nodig moeten hebben voor templates?

Hoe zag je dit voor je dan? Twig en Blade zijn beide in PHP-geschreven template engines, zie niet waarom je het wiel opnieuw zou uitvinden.

Uiteindelijk wil je logica en opmaak gescheiden hebben. Het laatste wat je wilt is die twee mengen, dan breng je complexiteit naar je website die je niet wilt.

[ Voor 17% gewijzigd door CH4OS op 18-04-2019 15:46 ]

[Josk79]

CH4OS schreef op donderdag 18 april 2019 @ 15:45:
[...]
Hoe zag je dit voor je dan? Twig en Blade zijn beide in PHP-geschreven template engines, zie niet waarom je het wiel opnieuw zou uitvinden.

Het ironische is dat PHP oorspronkelijk een soort van template engine is. Dus Blade en Twig hebben het wiel opnieuw uitgevonden...

(PHP is in deze vergelijking dan wel meer een 'vierkant' wiel)

Maar de vraag is wel: Waarom PHP en niet sec HTML? Welke dynamische functionaliteit is nodig?

[Travelan]

Hedendaags en PHP, twee woorden die ik niet zo vaak meer naast elkaar zie staan ;-)

Ga voor simpel. KISS.

Kijk ook eens naar bijv. static engines als Jeckyll e.d.

[veltnet]

Hoe zag je dit voor je dan? Twig en Blade zijn beide in PHP-geschreven template engines, zie niet waarom je het wiel opnieuw zou uitvinden.

Uiteindelijk wil je logica en opmaak gescheiden hebben. Het laatste wat je wilt is die twee mengen, dan breng je complexiteit naar je website die je niet wilt.

Dat je zaken wil scheiden is duidelijk...daar ben ik het helemaal mee eens...daarvoor kun je bijvoorbeeld een MVC achtige structuur gebruiken,.
Maar waarom je voor de templates geen PHP zou mogen gebruiken is mij niet duidelijk.

En voor de duidelijkheid...ik ben geen hobbyist. Heb meer dan 40 jaar ervaring met het ontwikkelen van software...waarvan bijna 20 jaar o.a. in PHP

[isomis]

Gezien jouw geschiedenis zou ik even wat tijd besteden aan Laravel. Ik denk dat dit het best bij je aansluit.

[CH4OS]

veltnet schreef op donderdag 18 april 2019 @ 16:04:
Dat je zaken wil scheiden is duidelijk...daar ben ik het helemaal mee eens...daarvoor kun je bijvoorbeeld een MVC achtige structuur gebruiken,.
Maar waarom je voor de templates geen PHP zou mogen gebruiken is mij niet duidelijk.

Tja, uiteindelijk wordt er natuurlijk altijd PHP gebruikt; er moet immers een manier zijn om hetgeen de backend heeft geparsed door te geven naar de view. Maar in de view wil je niet logica hebben, daar wil je enkel PHP gebruiken voor het weergeven van zaken en niet aldaar dingen gaan parsen. En ik denk dat daar de verspreking over en weer in zit.

En voor de duidelijkheid...ik ben geen hobbyist. Heb meer dan 40 jaar ervaring met het ontwikkelen van software...waarvan bijna 20 jaar o.a. in PHP

Ik ben enkel even benieuwd naar wat voorbeelden, omdat ik het vermoeden had dat er iets anders gezegd werd dan bedoeld. Zowel Twig als Blade gebruiken immers ook PHP. Sterker nog, de gecachete Blade-views in Laravel zijn niets anders dan geparste Blade templates naar PHP.

[ Voor 11% gewijzigd door CH4OS op 18-04-2019 16:26 ]

[Compizfox]

Kijk ook eens naar bijv. static engines als Jeckyll e.d.

Die gebruik je voor compleet andere situaties dan waar je PHP zou gebruiken.

---

veltnet schreef op donderdag 18 april 2019 @ 16:04:
[...]
Maar waarom je voor de templates geen PHP zou mogen gebruiken is mij niet duidelijk.

Omdat er specifieke templatetalen voor zijn die daar veel beter op aansluiten. PHP gebruiken als templatetaal is enorm bad practice.

[veltnet]

Compizfox schreef op donderdag 18 april 2019 @ 16:26:
[...]

Omdat er specifieke templatetalen voor zijn die daar veel beter op aansluiten. PHP gebruiken als templatetaal is enorm bad practice.

Vertel me dan waarom het een bad practice is.

[Compizfox]

veltnet schreef op donderdag 18 april 2019 @ 16:35:
[...]


Vertel me dan waarom het een bad practice is.

Omdat:

- Een template engine gebruiken je forceert om logic en presentation te scheiden
- Template engines features zoals template inheritance, caching, output filters, en automatische escaping hebben
- Templatetalen een syntax hebben die veel beter aansluit op templates. Templates in PHP schrijven levert code op die te verbose en lastig te lezen is.
- Templatetalen opzettelijk geen dingen ondersteunen die niet thuishoren in de presentatielaag, die in PHP uiteraard wel kunnen

Op de frontpage van Twig staat ook een zeer goede uitleg van de redenen achter een aparte templatetaal, inclusief voorbeelden.

[ Voor 11% gewijzigd door Compizfox op 18-04-2019 16:45 ]

[veltnet]

Compizfox schreef op donderdag 18 april 2019 @ 16:43:
[...]

Omdat:

- Een template engine gebruiken je forceert om logic en presentation te scheiden
- Template engines features zoals template inheritance, caching, output filters, en automatische escaping hebben
- Templatetalen een syntax hebben die veel beter aansluit op templates. Templates in PHP schrijven levert code op die te verbose en lastig te lezen is.
- Templatetalen opzettelijk geen dingen ondersteunen die niet thuishoren in de presentatielaag, die in PHP uiteraard wel kunnen

Op de frontpage van Twig staat ook een zeer goede uitleg van de redenen achter een aparte templatetaal, inclusief voorbeelden.

Allemaal zaken die met netjes werken, discipline en gezond verstand prima in PHP opgelost kunnen worden zonder dat je weer een templatetaal/library/framework hoeft te includen.

Ik begrijp dus je punt, maar ben het er niet mee eens.

[Josk79]

Prima mogelijk, maar ik zie liever

code:

{{ url }}

dan

code:

<?= htmlspecialchars( $url, ENT_QUOTES ) ?>

...en ik denk dat de gemiddelde designer makkelijker twig o.i.d. leert dan php.

[ Voor 27% gewijzigd door Josk79 op 18-04-2019 17:13 ]

[BernardV]

Josk79 schreef op donderdag 18 april 2019 @ 17:12:
Prima mogelijk, maar ik zie liever

code:

{{ url }}

dan

code:

<?= htmlspecialchars( $url, ENT_QUOTES ) ?>

...en ik denk dat de gemiddelde designer makkelijker twig o.i.d. leert dan php.

Ja, maar die {{ url }} is nu ook niet heilig.
De htmlspecialchars zul je dan in je context moeten zetten of je hebt weer filters en krijg je dingen als:

code:

{{ url|htmlspecialchars }}

//EDIT:
Daarbij moet je een designer helemaal geen twig willen leren, die moet lekker blijven designen
Je hebt dan iemand nodig die het design kan implementeren en die mensen kun je ook nog wel wat bijbrengen qua logica, een designer (uitzonderingen bevestigen de regel) wil het niet weten en gewoon iets moois maken.

[ Voor 24% gewijzigd door BernardV op 18-04-2019 17:21 ]

[RobbyTown]

Dank allemaal voor de reacties.

@bernardV is zal dat als eerste gaan doen dat is het minste werkt om aan te passen

Mocht dat niet de uitkomst bieden dan zal ik is naar Laravel kijken

Voor de gedesinteresseerde hoe mijn code er anno 2007 eruit zag.

map: tpl

Daar staat in
layout.tpl (algehele template indeling)
fp.tpl (frontpage)
Verder de stats pagina is dan stat.tpl en ga zo maar door.
layout.tpl

code:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="nl" lang="nl">
<head>
    <title>{SITE_NAAM} {titel_bijschrift}</title>
    
    <meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />
    <meta http-equiv="content-script-type" content="text/javascript" />
    <meta http-equiv="content-style-type" content="text/css" />
    <meta http-equiv="content-language" content="dutch" />

    <meta http-equiv="pragma" content="no-cache" />
    <meta http-equiv="imagetoolbar" content="no" />
    <meta http-equiv="window-target" content="_top" />
    
    <meta name="author" content="{AUTEUR}" />
    <meta name="copyright" content="Copyright 2007 - {JAAR} {SITE_NAAM}" />
    
    <meta name="description" content="{SITE_NAAM}, een verzameling van films, series, documentaires" />
    <meta name="keywords" content="{SITE_NAAM}, films, series, documentaires, CD, DVD, HD DVD, Blu-ray, DVDs, movie, acteurs, regisseurs, filmregisseur, statistieken, RSS, info, moviemeter, imdb, kijkwijzer, een verzameling van films, series, documentaires" />
    <meta name="subject" content="{SITE_NAAM}, een verzameling van films, series, documentaires" />
    
    <meta name="language" content="nl" />

    <meta name="robots" content="noindex, nofollow" />
    
    <meta name="revisit-after" content="2 days" />
    
    <meta name="verify-v1" content="+XD4mcHCbPY9Wb91yp9ZAhxbJRlGzXkC6pfX4R9dIe0=" />
    
    <link rel="stylesheet" href="{SITE_URL}style.css" type="text/css" media="screen, handheld, projection" />
    <link rel="shortcut icon" type="image/x-icon" href="{SITE_URL}favo.ico" />
    
    <link rel="alternate" type="application/rss+xml" href="http://feeds.feedburner.com/Media-collector" title="{SITE_NAAM} - RSS-feed" />
</head>
<body>

<div id="outer">

    <div id="upbg"></div>

    <div id="inner">


        <div id="header"> </div>
        
        <div id="splash">{HEADER}</div>
        <!--
        <div> &nbsp; </div>
        <div id="med">
            <p><b>Mededeling:</b> Deze website is nog in aanbouw! Wanneer deze mededeling niet meer komt is {SITE_NAAM} klaar.</p>
        </div>      
        <div> &nbsp; </div>
        -->
        <div id="menu">
            <ul>
                <li class="first"><a href="{SITE_URL}">Home</a></li>
                <li><a href="{SITE_URL}db/">Database</a></li>
                <li><a href="{SITE_URL}tv/">Films op TV</a></li>
                <li><a href="{SITE_URL}statistieken/">Statistieken</a></li>
                <li><a href="{SITE_URL}rss/">RSS</a></li>
            </ul>
            
            <div id="date">
                {DATUM_VANDAAG} (Week: {WEEK})
            </div>
        </div>      
        
        <div id="primarycontent">
        
            <!-- primary content start -->
            <div class="post">
            <!-- START BLOCK : tabel -->
            <div class="header">
                <h3>{titel}</h3>
            </div>
            <!-- INCLUDE BLOCK : inhoud -->
            <!-- END BLOCK : tabel -->              
            </div>
            <!-- primary content end -->
    
        </div>
        
        <div id="secondarycontent">

            <!-- secondary content start -->
                
            <!-- START BLOCK : filmspot -->
            <h3>Film Spot</h3>
                <div class="filmspot">
                    <script type="text/javascript" src="http://www.filmtotaal.nl/trackers/filmsoptv/filmsoptv_5.js"></script>
                </div>  
            <!-- END BLOCK : filmspot -->   

            <!-- START BLOCK : powered_filmtotaal -->
            <h3>Powered by</h3>
                <div class="content">
                    <p>De informatie van "Films vandaag op TV" wordt gegenereerd door de Filmtotaal RSS-Feed.</p>
                    <p style="text-align: center;"><a href="http://www.filmtotaal.nl/" onclick="window.open(this.href,'_blank');return false;"><img src="{EXT_URL}filmtotaal.jpg" class="rand" alt="" title="" /></a></p>
                </div>  
            <!-- END BLOCK : powered_filmtotaal --> 
            
            <!-- START BLOCK : rss_abbo -->
            <h3>Abonneren op RSS</h3>           
                <div class="content">               
                    <p><strong><a href="http://feeds.feedburner.com/Media-collector" onclick="window.open(this.href,'_blank');return false;">Abonneer mij nu</a></strong> op de RSS-Feed van {SITE_NAAM}.</p>
                </div>              
            <!-- END BLOCK : rss_abbo -->   

            <!-- START BLOCK : dvd_cover -->
            <h3>Cover</h3>
                <div>
                    <p>{plaatje}</p>
                </div>  
            <!-- END BLOCK : dvd_cover -->

            <!-- START BLOCK : kijkwijzer_advies -->
            <h3>Kijkwijzer Advies</h3>
                <div>
                    <p style="text-align: center;">{kijkwijzer}</p>
                </div>  
            <!-- END BLOCK : kijkwijzer_advies -->

            
            <!-- START BLOCK : zoeken -->
            <h3>Zoeken in DVD Database</h3>
                <div class="content">               
                <form method="post" action="/">
                        <input type="text" name="zoekterm" size="24" />&nbsp;
                        <input class="no-border" type="image" name="post" src="{SITE_URL}images/zoek.gif" />
                    </form>
                </div>              
            <!-- END BLOCK : zoeken --> 
                
            <!-- START BLOCK : reclame -->

            <!-- END BLOCK : reclame -->
                
            <!-- secondary content end -->
            
        </div>
        
        <div id="footer">                   
            &copy; 2007 - {JAAR} {SITE_NAAM} | Alle rechten voorbehouden
        </div>

    </div>

</div>
<script src="http://www.google-analytics.com/urchin.js" type="text/javascript">
</script>
<script type="text/javascript">
_uacct = "UA-1361035-3";
urchinTracker();
</script>
</body>
</html>

fp.tpl

code:

<!-- START BLOCK : fp -->           
<div class="content">
    <img src="{EXT_URL}welkom.png" class="rand floatleft" alt="DVD Logo" title="DVD Logo" />
    <p><strong>{SITE_NAAM}</strong> is een website die informatie verzameld over media. Het zijn niet alleen speelfilms die in de database te vinden zijn maar ook serie's en documentaires.</p>
    <p>Sinds kort zijn er nieuwe media's, namelijk: HD DVD en Blu-ray, deze zullen ook in de database opgenomen worden.</p>
</div>          
<!-- END BLOCK : fp -->
<!-- START BLOCK : laatste-->           
<div class="content">
    <p>Hieronder zijn de laatste 10 toegevoegde items te vinden. Mocht je een overzicht willen zien van alle media die in de database staan, klik dan op "Database".</p>    
    <!-- START BLOCK : laatste_5 -->    
    <p><strong><a href="{SITE_URL}info/{id}/">{titel}</a> ({jaar})</strong> - {beschrijving}</p>
    <!-- END BLOCK : laatste_5 -->
</div>          
<!-- END BLOCK : laatste -->

Dan de frontpage (index.php is de frontpage)

PHP:

<?php

// Kies de template parser
define('SITE', 1);
define('DSP', 0);

$inhoud = 'fp.tpl';

require_once ('includes/include.inc.php');
require_once (SITE_PAD.'includes/header.inc.php');

if(!defined('IN_DVD')){
   die('Hacking attempt');
}

// Titel maken
$tpl->assignglobal("titel_onderwerp", "");
$tpl->assignglobal("titel_bijschrift", "- Media verzamel database");

$tpl->newBlock("tabel");
$tpl->newBlock("filmspot");
$tpl->newBlock("reclame");

$tpl->newBlock("fp");

$tpl->assign("tabel.titel", "Welkom bij ".SITE_DOMEIN_NAAM."");

$tpl->newBlock("tabel");
$tpl->newBlock("laatste");

$tpl->assign("tabel.titel", "Laatste 10 toegevoegde items");

$sDvds = mysql_query("SELECT id, titel, jaar, beschrijving  FROM ".PREFIX."films ORDER BY id DESC LIMIT 10");
while ($aDvds  = mysql_fetch_assoc($sDvds)) 
{   
    $tpl->newBlock("laatste_5");
    $tpl->assign(array("titel"          => $aDvds['titel']                          ,
                        "jaar"          => $aDvds['jaar']                           ,
                        "beschrijving"  => afkorten($aDvds['beschrijving'], 255)    ,
                        "id"            => $aDvds['id']
                    ));
    }


require_once (SITE_PAD.'includes/footer.inc.php');

?>

[Compizfox]

bernardV schreef op donderdag 18 april 2019 @ 17:18:
[...]

Ja, maar die {{ url }} is nu ook niet heilig.
De htmlspecialchars zul je dan in je context moeten zetten of je hebt weer filters en krijg je dingen als:

code:

{{ url|htmlspecialchars }}

Een goede template engine doet dat by default.

[Josk79]

Travelan schreef op donderdag 18 april 2019 @ 15:55:
Hedendaags en PHP, twee woorden die ik niet zo vaak meer naast elkaar zie staan ;-)

Dan moet je misschien eens onder je steen vandaan kruipen ;-)

PHP kan sinds ongeveer versie 5.4 prima meekomen en sinds versie 7 is het gewoon een moderne taal.

EDIT:
@kwaakvaak_v2 bij die eerste zin liet ik me wellicht uit de hoek drijven, maar alinea 2 is gewoon waar, vind je de post waar ik op antwoordde niet ook een tikkeltje onzin?

[ Voor 20% gewijzigd door Josk79 op 18-04-2019 20:03 ]

[kwaakvaak_v2]

Josk79 schreef op donderdag 18 april 2019 @ 19:07:
[...]


Dan moet je misschien eens onder je steen vandaan kruipen ;-)

PHP kan sinds ongeveer versie 5.4 prima meekomen en sinds versie 7 is het gewoon een moderne taal.

Nee joh, oeverloos bashen omdat PHP vanonder een steen is veel leuker. Je hebt namelijk 100% zekerheid dat het een discussie over hoe slecht/goed PHP wel niet is oplevert.

[Helox-in-a-box]

Wellicht is Craft CMS iets voor je? Werkt met Twig templates en is uitgebreider dan WP maar niet gericht op blogs zoals WP. Vindt zelf de wysiwyg editor erg fijn.

[Aragnut]

Zelf sinds kort aan het aanklooien met Tiny But Strong. Een vrij lichtgewicht template engine die goed samenwerkt met database query's. Uitleg op de website is niet het meest duidelijke, maar gelukkig is de logica erachter wel vrij overzichtelijk opgezet.

ik ben verder wel redelijk ongehinderd door enige vorm van ervaring/kennis op websites maken

[mr.paaJ]

Om wat voor website gaat het als Wordpress ‘te traag’ is vanwege veel plugins? Heb je die nodig? Om wat voor plugins gaat het?

Laravel is heerlijk als je zelf wat wil bouwen en je je weg weet in php, en op zich met de goede documentatie ook om als beginner met blade templates wat eenvoudig pagina’s te maken, maar dan heb je vast niet zomaar de functionaliteit die je plugins nu bieden.

Overigens, af en toe een speciale pagina maken kan prima met wordpress: alles goed voorbereiden (custom thema, pagina’s publishen op gespecificeerde tijd etc) en op de juiste momenten van thema wisselen of de pagina weer Is vást ook een plugin voor

[ Voor 25% gewijzigd door mr.paaJ op 18-04-2019 23:37 ]

[AW_Bos]

De meningen zullen behoorlijk verdeeld zijn, maar Smarty is tegenwoordig nog steeds een goede template-parser die zeker niet oud is, en nog steeds updates en ondersteuning krijgt. Ikzelf gebruikt het ook voor mijn projecten.

Als ik het opnieuw zou doen, zou ik templates direct in PHP genereren, of misschien Twig gebruiken, maar met Smarty zelf is ook niks mis. Misschien geeft het een klein beetje meer overhead, maar ik kan daar uitstekend mee leven.

Wordpress is leuk, maar bouw er geen site op waarvan meer dan de helft op eigen geschreven functies leunt, en je gebruik maakt van diverse plugins. De boel wordt dan aanzienlijk trager.

Voor een simpele site die voornamelijk enkel simpele content moet tonen vind ik Wordpress ideaal, maar voor iets afwijkends: zoals een webwinkel, prijsvergelijker, is Wordpress niet het juiste middel.

[ Voor 30% gewijzigd door AW_Bos op 18-04-2019 23:59 ]

[BernardV]

Compizfox schreef op donderdag 18 april 2019 @ 18:51:
[...]

Een goede template engine doet dat by default.

Dat hoop ik niet, als iemand een wysiwyg editor gebruikt in het beheer en de template engine zet alles zelf om naar specialchars zie je dus code ipv italic tekst bijvoorbeeld.

[Josk79]

@bernardV en dat is prima, dan ben je in ieder geval default niet kwetsbaar voor XSS.

Vertrouw je de input? Kun je {{ content|raw }} toepassen. Anders moet je een filter maken die bijv. <strong> wel accepteert, maar <script> niet (wat niet eenvoudig is).

[ Voor 4% gewijzigd door Josk79 op 19-04-2019 15:58 ]

[gbspeel]

veltnet schreef op donderdag 18 april 2019 @ 15:23:
Waarom gebruik je PHP zelf niet als template taal? Waarom zou je uberhaupt een aparte taal/markup nodig moeten hebben voor templates?

Kijk voor de gein eens naar hoe templates werken in CakePHP. Behalve het telkens intypen van <?= of <?php en ?> komt het de leesbaarheid ook echt niet ten goede. Als je dan na een jaar of 3 zo'n template opent, is dat meestal met frisse tegenzin.

[pottink]

Gebruik gewoon een goed framework, dan kom je al een heel eind in "hedendaags" webapplicaties bouwen. Laat je ook niet blind leiden door de reacties over Laravel hier, zoek uit wat jij het leukst vindt werken. Symfony (met Twig) is zeker ook een top framework.

Als je toch reeds wat CMS functionaliteiten wil moet je gewoon wat goed rondkijken en vervolgens al eens uitproberen. Bolt, GravCMS, CraftCMS, Sulu, noem maar op.

[Cartman!]

bernardV schreef op vrijdag 19 april 2019 @ 15:05:
[...]

Dat hoop ik niet, als iemand een wysiwyg editor gebruikt in het beheer en de template engine zet alles zelf om naar specialchars zie je dus code ipv italic tekst bijvoorbeeld.

Misschien moet je eerst wat meer research doen voordat je deze dingen roept, je zaait enkel verwarring zo terwijl dat helemaal niet nodig is.

[BernardV]

Cartman! schreef op dinsdag 23 april 2019 @ 19:07:
[...]

Misschien moet je eerst wat meer research doen voordat je deze dingen roept, je zaait enkel verwarring zo terwijl dat helemaal niet nodig is.

Sorry, zo is het niet bedoeld. Verwarring is het laatste wat je wilt.
Ik bedoelde er alleen mee te zeggen dat een template engine niet voor mij standaard een htmlspecialchars moet uitvoeren. Als ik een image url krijg uit een functie bijvoorbeeld wat een resized image is, dan wil ik graag gewoon {{ url }} kunnen zetten ipv {{ url|raw }}.
Zo zijn er ook genoeg dingen te bedenken waar het wenselijk zou kunnen zijn, als je zelf niet nadenkt over de locatie. Maar het is een beetje als "security by obscurity" als je aanneemt dat de engine het wel voor je regelt. Zet zelf de goede functies/filters neer op de plekken waar je het nodig hebt en laat de engine in de basis gewoon doen wat het moet doen, de content tonen die het aangeleverd krijgt.

[Cartman!]

bernardV schreef op dinsdag 23 april 2019 @ 21:20:
Ik bedoelde er alleen mee te zeggen dat een template engine niet voor mij standaard een htmlspecialchars moet uitvoeren. Als ik een image url krijg uit een functie bijvoorbeeld wat een resized image is, dan wil ik graag gewoon {{ url }} kunnen zetten ipv {{ url|raw }}.

Beter 1 keer code op je scherm dan een mogelijkheid tot het creeren van XSS 1 keer vergeten kan genoeg zijn om voor een ander misbruik van te maken.

Zo zijn er ook genoeg dingen te bedenken waar het wenselijk zou kunnen zijn, als je zelf niet nadenkt over de locatie. Maar het is een beetje als "security by obscurity" als je aanneemt dat de engine het wel voor je regelt.

Als de werking expliciet zo gedocumenteerd is, dan is t geen aanname maar de manier van implementeren.

Zet zelf de goede functies/filters neer op de plekken waar je het nodig hebt en laat de engine in de basis gewoon doen wat het moet doen, de content tonen die het aangeleverd krijgt.

Oneens, escape alles wat je toont tenzij het expliciet niet wenselijk is. De standaard instelling moet veilig zijn en de uitzondering onveilig, niet andersom.

[BernardV]

Cartman! schreef op dinsdag 23 april 2019 @ 21:24:

Oneens, escape alles wat je toont tenzij het expliciet niet wenselijk is. De standaard instelling moet veilig zijn en de uitzondering onveilig, niet andersom.

Dan zijn we het eens dat we het niet eens zijn.

In Twig bijvoorbeeld heb je de autoescape, als jij denkt dat er content niet door de beugel zou kunnen zet je dat tussen de autoescape.

[Cartman!]

bernardV schreef op dinsdag 23 april 2019 @ 21:34:
[...]

Dan zijn we het eens dat we het niet eens zijn.

In Twig bijvoorbeeld heb je de autoescape, als jij denkt dat er content niet door de beugel zou kunnen zet je dat tussen de autoescape.

Standaard kan geen enkele content door de beugel want die informatie komt ergens vandaan; danwel een user van de site, een beheerder (die kunnen ook dingen stuk maken, geloof me) of een derde partij. In principe moet je altijd alles beschouwen als onveilig en dus escapen. Bij elke keer dat je "|raw" gebruikt (Twig specifiek) moet je heel goed nadenken of dat wel echt de bedoeling is. Zoals ik zei kun je t 98 keer goed handmatig escapen maar de 99e keer waar je t vergeet kan t fataal zijn.

[Josk79]

bernardV schreef op dinsdag 23 april 2019 @ 21:20:
[...]
Als ik een image url krijg uit een functie bijvoorbeeld wat een resized image is, dan wil ik graag gewoon {{ url }} kunnen zetten ipv {{ url|raw }}.

Die url behoort te worden ge-escaped, dus {{ url }} is beter dan {{ url|raw }} anders ga je de mist in als er een aanhalingsteken in zit, bijvoorbeeld. In een 'img src=' hoort de url te worden ge-escaped.

[BernardV]

Oh dat je alle content moet beschouwen als onveilig is waar, daar zijn we het ook zeker over eens, dat behoeft geen discussie.
Mijn visie is alleen dat je moet nadenken over je content en al zet je gelijk alles tussen {% autoescape %} prima is, maar als je er standaard vanuit gaat dat alles ge-escaped wordt en je werkt een keer in php zelf of welke taal dan ook, dan kom je er bedrogen uit.
Dus denk na over je content en zorg dat je je filters goed hebt staan waar dan ook en ga er dus niet vanuit dat alles geregeld is.
Maar goed, wij houden er blijkbaar allebei een andere werkwijze op na en ik wil je daar totaal niet op aanvallen, want je werkwijze is gewoon goed.

Josk79 schreef op dinsdag 23 april 2019 @ 21:53:
[...]

Die url behoort te worden ge-escaped, dus {{ url }} is beter dan {{ url|raw }} anders ga je de mist in als er een aanhalingsteken in zit, bijvoorbeeld. In een 'img src=' hoort de url te worden ge-escaped.

Ja, is waar, maar goed.. ik denk (in dit verhaal) misschien ook niet na over alles wat ik standaard al implementeer in zo'n soort functie. Als ik in mijn context bijvoorbeeld $context['image_url'] = resize($image_url,640,480); zou zetten is de url die uit de functie komt al escaped.. dan is het niet relevant dat ik het nogmaals doe, zelfs niet wenselijk.

[Voutloos]

Nee, je moet escapen voor een context.
Als jij een url toont in een html doc, moet je hem escapen om de html valide te houden. Je resize() functie moet zich daar niet mee bemoeien; misschien wil je het resultaat wel in de DB opslaan of verder verwerken of ... etc.

Juist met geintjes als "maar resize() doet het escapen al voor mij" ben je vanzelf een keer de Sjaak als je een keer een functie aanroept die het niet automagisch voor je oplost. A.k.a. 98x denk je er aan dat resize() je helpt en in je 99e stuk code denk je er niet aan dat stringDoFoo() het niet deed.

Zie https://www.php.net/manual/en/security.magicquotes.php en alle ellende die het gebracht heeft.

[ Voor 8% gewijzigd door Voutloos op 23-04-2019 22:08 ]

[BernardV]

@Voutloos Je hebt helemaal gelijk, ik hou nu ook maar op.. ik omschrijf het niet heel duidelijk meer.
Ik heb bijvoorbeeld iets als:
new Twig_SimpleFilter('resize', array($this, 'resize'))
Deze doet wel een escaped url terugsturen, immers is dat gewoon een Twig filter en die sla ik niet op in een DB.

[Cartman!]

bernardV schreef op dinsdag 23 april 2019 @ 21:57:
Mijn visie is alleen dat je moet nadenken over je content en al zet je gelijk alles tussen {% autoescape %} prima is, maar als je er standaard vanuit gaat dat alles ge-escaped wordt en je werkt een keer in php zelf of welke taal dan ook, dan kom je er bedrogen uit.

Dus je schakelt bewust liever de veilige standaard uit omdat je misschien in een andere taal/library die optie niet hebt? Waarom zou je dan uberhaupt nog libraries gebruiken, elke functie werkt overal net even anders.

bernardV schreef op dinsdag 23 april 2019 @ 22:10:
@Voutloos Je hebt helemaal gelijk, ik hou nu ook maar op.. ik omschrijf het niet heel duidelijk meer.
Ik heb bijvoorbeeld iets als:
new Twig_SimpleFilter('resize', array($this, 'resize'))
Deze doet wel een escaped url terugsturen, immers is dat gewoon een Twig filter en die sla ik niet op in een DB.

Waarom zou je dat escapen in die functie als Twig dit keurig voor je afhandelt? Nu introduceer je alleen maar extra code op diverse plekken waar je handmatig alles gaat escapen. Stel dat de methode van escapen veranderd moet worden, ga je dat overal weer langs moeten lopen.

[ Voor 36% gewijzigd door Cartman! op 23-04-2019 22:14 ]

[pottink]

Maar goed, PHP als template taal is 2007, enkel voor héél simpele dingetjes kan ik er nog inkomen. Maar anno 2019 wil je toch performante zaken zoals template caching en makkelijke language gebruiken (die begrijpbaar is voor iedereen) ipv PHP en HTML door elkaar. Dat trekt op niks, tenzij je een gastenboekje maakt voor de kamping om de hoek.

MVC draait helemaal om het scheiden van de View van al de rest. En als je nou zegt dat design patterns onzin zijn dan raad ik je aan om terug naar school te gaan.