Van div html template naar php: hoe?

[Elkana]

Goedenavond allen!
Vandaag ben ik begonnen met het maken van een basis van mijn portfolio. Nu werk ik voornamelijk met WordPress. Ik heb in het verleden wel veel met html gewerkt maar nog nooit met php. En nu komt dus mijn vraag.

Ik heb op http://ontwerp.elkana.nl een template staan die is opgebouwd op div-tags en in html. Nu wil ik graag op de portfolio-pagina een pagina includen, namelijk http://www.elkana.nl/portfolio maar hiervoor moet de pagina waar ik 'm in wil, een php-bestand zijn. Want met i-frames wil ik liever niet werken, ondanks dat ik het nu tijdelijk wel even heb gedaan. Volgens vele sites is het namelijk "ruk/slecht/kl*te" om met i-frames te werken.

Weet iemand hoe ik mijn template/pagina's kan omzetten naar php? Heb wel gelezen dat je ze gewoon kan renamen van html naar php maar dit is volgens mij niet de oplossing.
Ook moet ik -als ik bijvoorbeeld een wijziging aanbreng in de 'header'- dit bij elke pagina aanpassen. Nou is dit voor mij niet zo'n heel groot probleem maar het lijkt me wat overbodig.

Zou iemand eens zijn of haar oog op mijn geknutsel willen leggen?
(Vast wel, dit is -ja, ik blijf het herhalen- zo'n behulpzaam forum!)
Alvast bedankt!

 

[csshunter]

Hoi Elkana,
Mocht je de grondbeginselen nog niet kennen, dan:

• staat een voorbeeld van het php-princiep hier,
• wat toelichting erbij staat hier,
• en een uitgebreide tutorial voor een php-site staat hier.

[[[ In jouw geval kan het voor de portfolio-pagina heel eenvoudig, denk ik: je zou even ... ]]]

Herstel!
Ik heb nog even wat beter zitten koekeloeren naar je site, en het is toch niet zo heel eenvoudig. :shocked:

• Je ingesloten portfolio is niet 1 pagina, maar een hele batterij pagina's / subpagina's (die met php opgeroepen worden).
• Bij de portfolio-pagina's zit een eigen stylesheet (template) en eigen scripts.

Je bent er dus niet door simpel alles wat in de body van een portfolio-pagina zit los te knippen en als php-include te presenteren in je gewone pagina.
- In een iframe wordt alles van de pagina die je door dit kijkvenstertje ziet, automatisch meegenomen. Maar met een php-include moeten de "omgevingsfactoren" (css, scripts) geïntegreerd worden in je normale pagina waarin de php-include wordt opgeroepen: anders ziet die er niet uit, of heeft die geen functionaliteit. Dat integreren zou wel eens knap lastig kunnen worden...

Herstel!
Intussen wat op de site van Plogger (van je portfolio-gallery-machine) rondgescharreld, en ... daar zeggen ze dat het integreren een scharrelei van Columbus moet zijn:

• "Plogger is designed to make this as simple as possible with a total of three lines of PHP needed to get it to work properly."
• Integrating a Plogger Gallery

Heb je dit al eens geprobeerd (op een proefpagina, voordat het eitje breekt)?

Hopelijk kom je hier een stapje verder mee.
Met vriendelijke groet,
CSShunter

 

[Elkana]

Haha, wat kun jij gaaf en interessant reageren zeg En ook met heel veel nuttige info, super!

Heb dat van Plogger zelf nog niet geprobeerd. Mede omdat men ook hier zegt dat het bestand waar je het wilt integreren ook php moet zijn. En dat is m'n website (nog) niet.

Wat vind jij van een i-frame gebruiken? Ik heb het namelijk nu wel in een i-frame en het ziet er eigenlijk best goed uit zo.

 

[csshunter]

Hoi Elkana,

... niet geprobeerd. Mede omdat men ook hier zegt dat het bestand waar je het wilt integreren ook php moet zijn. En dat is m'n website (nog) niet.

Ik mag niet ja-maren. - Ja, maar:

• Een webpagina die (nog) geen php-pagina is, wordt dit door alléén de uitgang .htm te veranderen in .php. Dat is simpel.
• Verder hoeft er niets in de pagina te veranderen om 'm op zich tot een php-pagina te maken.
• Het .php zegt alleen tegen de server: als er php-code in de pagina staat, moet je die eerst uitvoeren, en dan pas de pagina sturen naar de bezoeker.
• De oude code blijft dus ook in de vorm van een .php pagina werken.

Vervolgens kan je een deel van de inhoud van de pagina vervangen door regeltjes php-code (de regeltjes die in de Plogger-gebruiksaanwijzing staan).

• Als een pagina géén php-regels erin heeft staan, kan het gewoon een htm-pagina blijven > niet de hele site hoeft aangepast te worden, alleen de portfolio-pagina (voor zover ik kan overzien). De collection- en de album-pagina's zijn al php; misschien moeten daarin wat verwijzingen aangepast worden, maar als je nieuwe (eerst nog) lege collection- en album-pagina's invoegt volgens de Plogger-handleiding, hoeft dat waarschijnlijk niet eens.

(rest van m'n reactie volgt nog)
CSShunter

 

[Elkana]

Hoi Elkana,

Ik mag niet ja-maren. - Ja, maar:

• Een webpagina die (nog) geen php-pagina is, wordt dit door alléén de uitgang .htm te veranderen in .php. Dat is simpel.
• Verder hoeft er niets in de pagina te veranderen om 'm op zich tot een php-pagina te maken.
• Het .php zegt alleen tegen de server: als er php-code in de pagina staat, moet je die eerst uitvoeren, en dan pas de pagina sturen naar de bezoeker.
• De oude code blijft dus ook in de vorm van een .php pagina werken.

Van mij mag je ja-maren hoor. Had twee jaar geleden een leraar die -als je ' ja maar' zei- zei dat wij nog in de 'ja-maar-fase' zaten en daar overheen moesten komen
Ah kijk! Dat is de info die ik moest weten. Wist niet zeker of er nog wat aan het bestand veranderd moest worden. Heb alle extensies inmiddels veranderd naar php. Toch allemaal maar gedaan, dat staat wat netter en het zijn maar 5 pagina's.

Vervolgens kan je een deel van de inhoud van de pagina vervangen door regeltjes php-code (de regeltjes die in de Plogger-gebruiksaanwijzing staan).

• Als een pagina géén php-regels erin heeft staan, kan het gewoon een htm-pagina blijven > niet de hele site hoeft aangepast te worden, alleen de portfolio-pagina (voor zover ik kan overzien). De collection- en de album-pagina's zijn al php; misschien moeten daarin wat verwijzingen aangepast worden, maar als je nieuwe (eerst nog) lege collection- en album-pagina's invoegt volgens de Plogger-handleiding, hoeft dat waarschijnlijk niet eens.

Dit zal ik nog even overwegen. Inmiddels heb ik het ook gewijzigd in een <object> code in plaats van een i-frame. Tevens heb ik alle pagina's door de Validator gehaald van W3C gehaald en alle pagina's zijn valid! Joechei, voor het eerst!
Maarrrrr.... Nog 1 pagina niet. En dat is de contact.php Hier heb ik een script voor gebruikt dat een mailform naar mij kan mailen. Verder allemaal prima, tot ik bij de code voor het formulier aankom. Dan krijg ik in de validator 36 fouten. En dat zit 'm puur in de volgende code:

<form method="post" action="distribution/phorm.php">
<input type="hidden" name="PHORM_CONFIG" value="quickconfig.php">
Naam: <br /> <input type="text" name="name" size=50 maxlength=50><br /><br />
E-mailadres:<br /> <input type="text" name="email" size=50 maxlength=50><br /><br />
Bericht:<br /> <textarea rows="5" cols="38" name="bericht"></textarea><br /><br />
<input type="submit" value=" Verstuur ">
</form>

(rest van m'n reactie volgt nog)
CSShunter

Ik wacht het netjes af

 

[That Guy]

Je gebruikt xHTML, dan moet je je tags allemaal afsluiten, ook 'open' tags. Daarnaast moet je eens even al je attribuut-waardes tussen quotes zetten. Dus niet

<input type="text" name="name" size=50 maxlength=50>

maar

<input type="text" name="name" size="50" maxlength="50" />

Daarnaast moetten de text / input elementen toch wel in een container staan, bijvoorbeeld:

<div>
   <!--- hier <form> t/m </form> -->
</div>

dan is ie valide :thumb:

 

[csshunter]

Hoi Elkana,
Daar is toch mooi het gras voor m'n voeten weggemaaid!
Ik was intussen bezig hetzelfde met meer woorden in een reactie te vlechten (en tussendoor werd ik even afgeleid).

Die gaan 36 Errors we eens bij hun lurven pakken.

Error 1 (line 40, column 65)
... document type does not allow element "input" here ...
Een <input> moet ingebakken zitten in een <div>, een <p> of een ander soort element dat een tekstblok aangeeft. We pakken een <div>, want die heeft geen invloed op de regelafstanden, margins, enz. van het huidige formulier:

<div>
   <input type="hidden" name="PHORM_CONFIG" value="quickconfig.php">
   ...
en sluiten die na de laatste input-regel weer netjes af:
   ...
   <input type="submit" value=" Verstuur ">
</div>

• Het resultaat staat hier: nu zijn er opeens nog maar 21 Errors (zie validator-link op de testpagina).

Error 1 is nu (Line 41, Column 68)
... end tag for "input" omitted ...
In xhtml moet een alle elementen afgesloten worden. Net als een <img> geen </img> heeft, heeft ook een <input> geen </input>: "Start tag: required, End tag: forbidden" zegt de html-specificatie. - In deze gevallen wordt de afsluiting van een tag bereikt door een / op het eind te zetten. Het wordt: <img src="..." ... /> en <input type="..." ... />. Dus hier:

<div>
   <input type="hidden" name="PHORM_CONFIG" value="quickconfig.php" />
   Naam: <br /><input type="text" name="name" size=50 maxlength=50 /><br /><br />
   E-mailadres:<br /><input type="text" name="email" size=50 maxlength=50 /><br /><br />
   Bericht:<br /><textarea rows="5" cols="38" name="bericht"></textarea><br /><br />
   <input type="submit" value=" Verstuur " />
</div>

• Resultaat hier: nu zijn er nog maar 10 Errors!

Error 1 is nu (Line 42, Column 51)
... an attribute value specification must be an attribute value literal ...
En size=50 staat rood gedrukt. Dit betekent dat je een waarde van een "attribuut" (eigenschap, hier de eigenschap "size") niet zomaar achter het = teken mag zetten, maar er altijd aanhalingstekens omheen moet zetten. Dus size="50". Dat doen we meteen even voor alle attributen die er zo in staan (dus ook de maxlength's):

<div>
   <input type="hidden" name="PHORM_CONFIG" value="quickconfig.php" />
   Naam: <br /><input type="text" name="name" size="50" maxlength="50" /><br /><br />
   E-mailadres:<br /><input type="text" name="email" size="50" maxlength="50" /><br /><br />
   Bericht:<br /><textarea rows="5" cols="38" name="bericht"></textarea><br /><br />
   <input type="submit" value=" Verstuur " />
</div>

• Resultaat hier, en kijk nu eens:

​

Conclusie:
Het blijkt dat de html-validator bij een gevonden fout ook vaak andere fouten signaleert, die als ijs voor de zon verdwijnen als de eerste fout is hersteld.
In de praktijk slinkt het aantal fouten bij correctiewerk dan ook vaak sneller dan je denkt, en hoef je je niet te verdiepen in een aantal in het begin gesignaleerde dingen waarvan je geen idee hebt wat er nu fout aan is. Er was ook niets fout aan, maar het was alleen fout in de context van een echte fout ergens anders!

Zie zie je maar weer, soms valt het leven mee.
Met vriendelijke groet,
CSShunter

 

[Elkana]

Sorry dat ik nu pas reageer! Druk met werken enzo...

Hey Vegras en csshunter, bedankt voor jullie reactie! Super dat jullie het zo uitgebreid uit hebben gelegd! Snap nog niet altijd alles van die validator-uitleg Daarom, fijn dat jullie hebben geholpen!

Wat vinden jullie trouwens van de oplossing van mijn portfolio-pagina? Het venster in een 'object' code? Is dat wat netheid betreft een oplossing?

 

[csshunter]

Hoi Elkana,
Ja, die <object> oplossing is nog zo gek niet.

• Waarom niet, staat bv. hier.

Alleen ... nu doet je portfolio-pagina het niet in Internet Explorer (i.i.g. niet in IE7, rest niet getest).
Maar gelukkig hebben knappe koppen daar ook iets op gevonden:

• Je zou er een classid="..." attribuut bij moeten zetten, plus nog aanvullende cpodes om het zowel in IE als in de rest te laten werken: zoals hier aangegeven.
• NB: de code op de voorbeeldpagina http://intranation.com/test-cases/object-vs-iframe, waar ook naar verwezen wordt, blijkt niet te werken in Firefox 3 en Firefox 3.5 (maar die waren er nog niet toen die artikelen geschreven werden).

Al met al lijkt me de object-methode een zooi extra werk, en ik vraag me af wat daar in jouw geval het voordeel van is. Ik zou het maar gewoon op een <iframe> houden, als de php-methode (nog) niet lukt.

Met vriendelijke groet,
CSShunter

PS-1
Je geeft het <object> een width="950px" en een height="800px". Maar breedtes en hoogtes die rechtstreeks in de html staan, mogen géén eenheid (px) er in hebben staan. Dus alleen width="950" en height="800" (net zoals bij een img). Dat komt omdat html bij deze scherm-maten alleen maar pixels kent. Voor css ligt dat anders: dan zijn er in een aantal gevallen ook andere maten (em, pt, %, enz.) mogelijk.

PS-2
Op je startpagina ontwerp.elkana.nl gaan de 4 links onderaan (onder "Trots op onder andere") nog nergens naar toe. Maar die wist je waarschijnlijk al.

 

[Remi1995]

Ik denk dat u dit bedoelt:

<?php include("map/bestand.html"); ?>

 

[Elkana]

Hoi csshunter,
Heb het hele gebeuren nu in een iframe staan. Hierdoor krijg ik echter wel 7 errors. Het integreren zoals ze op de pagina van plogger zeggen krijg ik niet voor elkaar. Snap niet hoe het zou moeten.

P.s. De 'px' heb ik weggehaald. De fototootjes onderaan op de startpagina wil ik eigenlijk linken naar de desbetreffende foto in mij portfolio maar dat lukt niet omdat het via een iframe gaat...

 

[csshunter]

Hoi Elkana,
Die 7 errors komen allemaal door het gebruik van het iframe, in combinatie met het DOCtype XHTML-strict dat je gebruikt. Dat staat het gebruik van iframes niet toe, en dan komt er dus "invalid" code uit.
Maak er maar eens van:

[FONT="Courier New"][SIZE="2"][COLOR="Navy"]<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">[/COLOR][/SIZE][/FONT]

• Dan gaat het gewoon goed. *)

Hoe je die Plogger-includes zou moeten maken, zou ik ook niet zo weten. De Plogger-gallery pagina's zijn met een eigen "dynamisch CMS" (Content Management System met via php automatisch gegenereerde gallery-pagina's) gemaakt, en daar krijg ik van de buitenkant geen grip op.
Ik heb even geprobeerd de eerste gallery-pagina (als statische pagina, dus gewone html) via een php-include in te voegen.

• Betekent: ik heb de pagina "gestript" (alles wat buiten de <body>...</body>tags staat er af gehaald), en dan als php-include in de portfolio-pagina gemonteerd (ipv het iframe).
• Dan moet je de script- en style-verwijzingen uit de <head> van de gallery-pagina toevoegen aan de <head> van de portfolio-pagina.
• In principe kunnen er dan tegenstrijdige css opdrachten in die ene nieuwe pagina zitten, en in de praktijk klopt dat: er zaten twee dezelfde <div id="wrapper">'s in de code. Dus html en één stylesheet aangepast: de ene #wrapper laten heten, en de andere #wrapper2 genoemd.
• Maar zoals uit een testpagina blijkt, is dat niet het enige .... ook andere styles zijn door het extra stylesheet beïnvloed, en dat zou allemaal van elkaar losgetrokken moeten worden. Want in wezen zijn er twee templates: eentje voor de gewone pagina, en eentje voor de inwendige gallery; en die interfereren als de pieten...
• Ook de (via Plogger) automatisch ingevoegde verwijzingen naar afbeeldingen blijken het goede bronmapje te missen. :shocked:

"Even zelf doen" is er dus jammer genoeg niet bij, door de opzet van het Plogger-systeem. En als je de Plogger-handleiding niet kunt volgen (of als die in jouw geval niet van toepassing is, wie weet), dan lig ik er uit.
Maar misschien leest een Plogger-deskundige dit en kan je goede raad geven.
Hope so!

Groetjes,
CSShunter

*) Het "Tentatively checked" bij bovenstaand validator-resultaat slaat er op, dat hier even kunstmatig het DOCtype is vervangen (de html-validator kan niets aan je pagina veranderen!), en dat het dan goed gaat. Om het echt goed te maken, waarschuwt de validator, moet je ook echt in je pagina het DOCtype veranderen.

 

[Elkana]

Ik heb inmiddels alles zoals het hoort! Het is helemaal super Gewoon iframe gebruiken, zie je verder niks van.

Nou, dan zijn we denk ik klaar. Heel erg bedankt voor je hulp :thumb: en ik kom hier vast nog wel weer!

 

[Lunanoko]

Één kleine opmerking als ik zo vrij mag zijn

Daarnaast moetten de text / input elementen toch wel in een container staan, bijvoorbeeld:

<div>
   <!--- hier <form> t/m </form> -->
</div>

dan is ie valide :thumb:

Dat is niet nodig om hem valide te maken, het is alleen een handigheidje.
Echte html puristen zijn zelfs tegen divs en spans omdat ze geen semantische waarde toevoegen en je hun functionaliteit via een iets moeilijkere weg kan bereiken met 'gewone' html elementen

 

[Elkana]

Okee, thanx! :thumb:

 

[ErikBooy007]

Één kleine opmerking als ik zo vrij mag zijn



Dat is niet nodig om hem valide te maken, het is alleen een handigheidje.
Echte html puristen zijn zelfs tegen divs en spans omdat ze geen semantische waarde toevoegen en je hun functionaliteit via een iets moeilijkere weg kan bereiken met 'gewone' html elementen

Nee, niet waar. Deze elementen moet wél in een container. Eén van deze:

"p", "h1", "h2", "h3", "h4", "h5", "h6", "div", "pre", "address", "fieldset", "ins", "del"

En dat HTML-puristen tegen <div>'s en <span>'s zouden zijn, is ook nieuw voor me

 

[Lunanoko]

Ik doelde dan dus ook op de divs en span, niet op al die andere die je noemt. <p> en <h1> zijn bijvoorbeeld gewone html elementen.

Tuurlijk zijn divs en spans dat ook, maar ze hebben totaal geen semantische waarde en worden alleen gebruikt voor opmaak. Aangezien html juist structuur moet aangeven en CSS de opmaak hoort te verzorgen zijn divs door de echte puristen niet gewenst

Dat neemt niet weg dat vrijwel de hele wereld die dingen gebruikt (puristen zijn ook maar een minderheid) en dat het gewoon hartstikke handig is :thumb:

 

[csshunter]

Hoi Lunanoko,
Het gaat een beetje de kant van offtopic op, maar de eigenlijke vraag is al beantwoord, dus ik mag misschien ook nog wat toevoegen.

• Over "divitis" (het te pas en te onpas invoegen van div's en span's *) kunnen wij en de puristen het gauw eens zijn: die pandemie moet bestreden worden!

Maar als ik een kop, een menu, een inhoud en een footer heb (die allemaal meerdere elementen in zich hebben), hoe moet ik die dan volgens de puristen groeperen als ik geen div mag maken?
Want behalve het dienen als handvat voor de vormgeving hebben die toch ook een structurele component?

"The DIV and SPAN elements, in conjunction with the id and class attributes, offer a generic mechanism for adding structure to documents. These elements define content to be inline (SPAN) or block-level (DIV) but impose no other presentational idioms on the content. Thus, authors may use these elements in conjunction with style sheets, the lang attribute, etc., to tailor HTML to their own needs and tastes."

html-specification: Grouping elements: the DIV and SPAN elements

Ik ben trouwens benieuwd hoe zo'n puristische site er uit ziet! Toch geen platte tekst?

Met vriendelijke groet,
CSShunter

*) onnodig = terwijl bv. ook een element als <h1> of <p> of <ul> heel goed zelf een class of ID kan krijgen (met al dan niet een vervolg voor de kind-elementen).

 

[Lunanoko]

Zoals ik al zei: met wat extra moeite lukt het allemaal nog wel Een wat drukkere site zal het inderdaad snel een warboel worden, maar ik kan me voorstellen dat als je bijvoorbeeld normaal een image, 5 paragrafen en een genummerde lijst in een div stopt, dat je al die elementen ook een class geeft, en ze aan de hand van die class positioneert.

Nogmaals: ik ben zelf niet zo'n purist, en ik ben er blij om want het is hartstikke veel extra moeite om het zo te doen. Één van mijn docenten is er wél een, en van haar heb ik het ook gehoord Ik kan je dus geen dus geen link geven ofzo naar een puristen forum Best jammer overigens, nu ik er (door dit topic) over na begin te denken wil ik ook wel eens weten wat voor sites een purist nou maakt Waarschijnlijk zul je inderdaad geen designbureaukwaliteit vinden tussen die van hun