onclick 2 frames vernieuwen

Status
Niet open voor verdere reacties.
Hoi Broertjuhhh,
Door ... niets! :)
Want:
  • Het doel is nu de index.php pagina geworden (die eerst http://www.opdit.nl/background/mainframe.php heette).
  • Op die index.php pagina worden met php-includes de kop en andere dingen die hetzelfde moeten blijven, automatisch binnengehaald.
  • Er hoeft dus op niets meer in die pagina ge-target te worden.
Voor alle andere pagina's in het menu geldt hetzelfde: je kan linken naar de pagina's, en dan ben je klaar.
Het is nu telkens de pagina zelf waar de inhoud op staat (bij de frame-opbouw was dat niet zo), en de rest wordt er vanzelf omheen gedrapeerd. De pagina is het enige mikpunt!

Met vriendelijke groet,
CSShunter
 
Hoi csshunter,

De link is nu, om er maar 1 te kiezen;

PHP:
<li><a href="computer/zozitjecomputerinelkaar/computertechniek.php">Moederbord</a></li>
Als ik daar op klik dan kom ik op de betreffende page, maar deze wordt dan getoont in een blanc page, en zie ik dus niet meer van de layout, het menu (top), leftmain, bottom etc.

Het zou fijn zijn als je een voorbeeldje voor me zou hebben ?

Nog een vraagje, wat is de bedoeling van onderstaande regel;

PHP:
<link rel="shortcut icon" type="image/x-icon" href="" /><!-- locatie nog invullen -->
 
Laatst bewerkt:
Hoi Broertjuhhh,
Ik had de voorbeelden van m'n site gehaald, maar heb ze er nu weer op gezet. :)

Moederbord-pagina ... Als ik daar op klik dan kom ik op de betreffende page, maar deze wordt dan getoont in een blanc page, en zie ik dus niets meer van de layout, het menu (top), leftmain, bottom etc.
Ja, dat klopt, want deze computertechniek.php is nog de oude "binnenpagina" die eerst in het mainframe zat: inderdaad een geheel kale pagina.
Deze pagina gaat nu (net als alle andere pagina's!) een echte zelfstandige pagina worden.
D.w.z.:
  • In de <head> moeten de benodigde css-bestanden aangeroepen worden.
  • In de <body> moeten de gelijkblijvende onderdelen als php-includes aangeroepen worden.
In de praktijk
In de praktijk is dat heel makkelijk:
  1. Je maakt een kopie van de model-pagina opdit-home-11.htm (de html-versie, want daar staat de php-code voor de in te sluiten fragmenten in).
  2. In de <head> staan al o.a. de links naar de stylesheets; die moeten aangepast worden naar de plek waar ze bij jou op de server staan.
  3. De <body> ziet er als volgt uit:
    HTML:
    <body>
    
    <div id="header">
    	<?php include("includes/opdit-header-fragment.htm"); ?>
    </div><!-- einde #header -->
    
    <div id="main">
    	in te vullen pagina-inhoud
    </div><!-- einde #main -->
    
    <div id="left">
    	<?php include("includes/opdit-left-fragment.htm"); ?>
    </div><!-- einde #left -->
    
    <div id="footer">
    	<?php include("includes/opdit-footer-fragment.htm"); ?>
    </div><!-- einde #footer -->
    
    </body>
    </html>
  4. Waar "in te vullen pagina-inhoud" staat, plak je de code van wat in de oude pagina tussen de <body> en de </body> staat.

  5. Je slaat de pagina lokaal op als .htm-bestand, bv.: moederbord.htm.
  6. Als je die lokaal bekijkt, zie je dit: opdit-moederbord.htm.
    Het hele inhoud-gedeelte staat er alvast goed op: op de juiste positie en met de goede opmaak. De in te voegen onderdelen ontbreken nog. Dat klopt, want het is nog een .htm-pagina.
  7. Je gaat 'm nu uploaden, en hernoemt 'm op de server tot bv. moederbord.php.
  8. Als je die via internet gaat bekijken, en alle verwijzingen in de pagina kloppen *), dan zie je dit: opdit-moederbord.php.
    De php-tovermachine op de server heeft nu alle ontbrekende fragmenten keurig ingeplakt, en de pagina is helemaal compleet. :)

Vervolgens kan je er aan gaan werken om het valid html te maken, want er zitten in het inhoud-gedeelte helaas nog 105 html-fouten. :rolleyes:
Dat komt vooral door een aantal Vreselijk Verboden Voorwerpen: de tags <font> en de attributen align="...".
Maar hier is wel een mouw aan te passen:
  • Alle <p>'s hebben steeds opnieuw dezelfde <font>-eigenschappen: de font-family en de font-size. Maar ... in de custom.css is al geregeld dat het standaard-lettertype de Verdana moet zijn: body {font-family: Verdana,Arial,Helvetica,sans-serif;}. Dat geldt dan ook voor alle <p>'s in de inhoud, Als je aan de custom.css toevoegt: #main p {font-size: .8em;}, hebben ze ook allemaal hetzelfde formaat, en dan kan de hele <font>-tag overal gemist worden.
  • De align="left" voor de meeste <p>'s kan ook gemist worden, want standaard worden regels altijd al links uitgelijnd.
  • De <p>'s van de kopjes, die wel gecentreerd moeten worden, kunnen beter tot echte kopjes <h2> en <h3> gemaakt worden. Die kan je dan ook allemaal tegelijk hun stijl geven.
  • De afbeeldingen die gecentreerd moeten worden, kunnen een <p> krijgen met <p class="center"> in plaats van <p align="center">, met .center {text-align: center;}.
  • Enz.
Zo blijft er mooie schone html over, bv.:
HTML:
<div id="main">
	<h2>:: Het moederbord ::</h2>
	<p>Je moederbord is het centrale onderdeel van de computer waarmee alle andere onderdelen zijn 
	verbonden. Het moederbord voert belangrijke bewerkingen uit met de chips die erop zitten.
	Zonder je moederbord zou je nergens zijn met de onderdelen van je computer.</p>

	<p class="center">
		<img src="http://opdit.nl/computer/zozitjecomputerinelkaar/moederbord.jpg" width="550" height="416" alt="" />
	</p>
	
	<h3>AGP slot</h3>
	<p>Het Accelerated Graphics Port slot, is bedoeld om je videokaart mee aan te sluiten. 
	Vroeger gebruikte men een normaal PCI slot om een videokaart aan te sluiten, 
	een AGP slot is vele malen sneller. (Een PCI slot heeft een doorvoersnelheid 
	van 133MegaByte/seconde vroeger werd ook wel 66MegaBytes/seconde gebruikt) AGP 
	heb je in verschillende uitvoeringen, met elk een snellere doorvoersnelheid. 
	Van de AGPx1, AGPx2, AGPx4 en AGx8P wordt AGPx8 het meest gebruikt. De doorvoersnelheid 
	van een AGPx8 slot is 2,1gigabyte/seconde. AGP sloten zijn backwards compatible, 
	een AGPx4 kaart werkt dus ook in een AGPx8 slot.</p>

	<h3>PCI sloten</h3>
	<p>De PCI sloten worden gebruikt om kaarten aan te sluiten zoals een netwerkkaart, 
	geluidskaart, tv-kaart, etc.</p>

	... enz.
=======
Voor alle andere pagina's van de site doe je precies hetzelfde. :)

Met vriendelijke groet,
CSShunter
____________
*) Attentie! De verwijzingen naar de include-fragmenten moeten een "relatief pad" hebben: gezien vanaf het mapje waarin de pagina wordt gezet. Met een "absoluut pad" (dat begint met http://www.opdit.nl/...) werkt het niet.
 
Nog een vraagje, wat is de bedoeling van onderstaande regel: ...
Was ik helemaal vergeten!
Als je een "favicon" hebt, kan je hier de vindplaats aangeven (het mapje en de naam van de favicon.ico).
 
Hallo csshunter,

“Luctor et emergo” bijna…

Na een week worstelen, begint er wat te ontstaan, maar zoals je waarschijnlijk wel verwacht had loop ik toch wel tegen wat “het werkt niet-jes” aan.

Als ik het menu_fragment, left_fragment, left_footer_fragment en het right_footer_fragment mee neem zoals je uitgelegd hebt in het bericht van “11 maart 2013, 21:04”, dan veranderen de verwijzingen in het menu.

“left_footer” heb ik er bij gemaakt en “right_footer” was eerst “footer”.

Bijv. ga naar opdit.nl en wijs in het menu “Computer” aan en dan het item “Stof” en je ziet dat de link naar www.opdit.nl/test/opdit_csh/computer/stof/stof.php verwijst.
Als je nu ook daadwerkelijk op stof klikt kom je netjes op “Stof” terecht en ziet het er allemaal leuk uit, maar, ga naar het menu “Computer”, het item “Stof” en aanschouw de link, dit is nu “www.opdit.nl/test/opdit_csh/computer/stof/computer/stof/stof.php geworden.

Zo kom je dus ook niet meer terug via het menu als je op “Home” klikt, want de verwijzing is veranderd, zoals ook bij “Stof” en in alle andere menu_keuze mogelijkheden.

Is dit op te lossen en zo ja hoe ?
 
Hoi Broertjuhhh,
Ja, het is op te lossen! :)
Wat er gebeurt is dit:
  • In het menu_fragment zijn relatieve paden naar de pagina's opgegeven.
  • Dat zijn de relatieve paden gezien vanaf de (test-)hoofdmap www.opdit.nl/test/opdit_csh/, waar de (test-)index.php in staat.
  • Daarom gaat het goed als je in het menu van de index.php klikt.
  • Maar ... de andere pagina's zitten niet in diezelfde hoofdmap: die zitten in submappen.
  • Vanaf een andere pagina werkt dan het relatieve pad niet meer!
Het valt recht te zetten door in het menu_fragment de verwijzingen naar alle pagina's op te nemen met hun absolute pad:
HTML:
<ul id="nav">
    <li class="top"> <a href="http://www.opdit.nl/test/opdit_csh/index.php" id="home" class="top_link"><span class="down">Home</span></a> 
        <ul class="sub">
            <li><a href="http://www.opdit.nl/test/opdit_csh/disclaimerencopyright/disclaimerencopyright.php">Disclaimer en Copyright</a></li>
            <li><a href="http://www.opdit.nl/test/opdit_csh/sitemap.php" id="home">Site Map</a></li>
        </ul>
    </li>
    ... enz.
Op deze manier wordt altijd bij het begin begonnen, en wordt telkens afgedaald naar de map waar de pagina in zit: kan niet mis!

  • NB: de verwijzingen naar het menu_fragment en andere includes moet wel via het relatieve pad vanaf een pagina. Links enz. in de includes kunnen ook een absoluut pad herbergen. En dat is hier nodig.
=======
Verder zijn er nog wat restanten van de oude frame-opbouw in de code blijven hangen, zoals bv. de broncode van de index en de stof-pagina laat zien, als je die via de browser opvraagt: er zitten verschillende keren een <head> en een <body> in! :eek:

Dat kan te maken hebben met:
  • incorrecte codering van de pagina zelf, en/of
  • incorrecte codering van de includes.
Wat en hoe, kan ik van buiten af niet zien: de php-behandeling maakt dat onmogelijk.

Voor de diagnose:
  • Kan je de index.php kopiëren, hernoemen tot index.htm, die uploaden en hier de link zetten?
Met vriendelijke groet,
CSShunter
 
Hallo csshunter,

Ok, dat is opgelost. :d

Nog iets “vreemds” althans voor mij,

1. Het left_fragment,

“Last Update
24-07-2012
and still in progress” etc. krijg ik niet goed gepositioneerd, hoe komt dat ?


2. Als je in de menu balk op “Home” klik verschoond de hele pagina in een “flits”, dit gebeurd alleen bij de “Home” knop en niet bij de andere.
Is hier wat aan te doen ?


3. Wat betreft de restanten “die zijn blijven hangen” van de oude frame opbouw, deze zie ik ook als ik in de browser naar de pagina bron kijk, echter als ik in mijn editor ( Macromdia Dreamweaver MX v 6.0 ) kijk is daar niets van te zien, ik begrijp niet hoe dat kan.
Weet jij wat hiervan de oorzaak kan zijn ?

Zo ziet de index.php er in werkelijkheid uit.

PHP:
<!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>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>fase 11 | Opdit.nl :: home</title>

<meta name="robots" content="noindex, nofollow" /><!-- alleen voor deze testpagina -->
<!-- http://www.helpmij.nl/forum/showthread.php/717477-onclick-2-frames-vernieuwen -->

<link rel="shortcut icon" type="image/png" href="favicon.png" /><!-- locatie van favicon.ico -->
<link rel="stylesheet" type="text/css" href="hoofdmenu/pro_pullup_1/pro_drop_1.css" />
<link rel="stylesheet" type="text/css" href="stylesheets/opdit_custom.css" />

</head>

<body>
<?php include("webmaster/mail_inlog.php"); ?>

<div id="header"> <?php include("0_includes/header.htm"); ?> </div>

<div id="left"> <?php include("0_includes/left.htm"); ?> </div>

<div id="mainplus"> <?php include("background/main_right.php") ?> </div>

<div id="leftfooter"><a href="disclaimerencopyright/disclaimerencopyright.php">Disclaimer en Copyright</a></div>

<div id="rightfooter"> &copy; Fere Eadem All rights reserved :: Website designed by Unlimited 1 With 2</div>
</body>
</html>
 
Hoi Broertjuhhh,
Aha, om met de laatste te beginnen: ik zie de ongerechtigheid die de dubbele Doctypes e.d. veroorzaakt.
Wat is het geval?

De index.php begint met een Doctype, alles van de <head>, de <body>-tag,
dan de <?php include("webmaster/mail_inlog.php"); ?>, en dan:
<div id="header"> <?php include("0_includes/header.htm"); ?> </div>.

De header.htm hoort puur en alleen de html-code binnen de <div id="header"> te hebben, en niets meer of minder.
Maar ... de broncode van de header.htm ziet er zo uit:

<!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>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Header</title>

<link rel="stylesheet" type="text/css" href="../hoofdmenu/pro_pullup_1/pro_drop_1.css" />
<link rel="stylesheet" type="text/css" href="../stylesheets/opdit_custom.css" />

</head>

<body>
<div id="header">

<span class="preload1"></span> <span class="preload2"></span>
<ul id="nav">
<li>....</li>
enz.
</ul>

</div>
</body>
</html>
Oftewel: alles wat hierboven rood is, staat al in de index.php en is dus dubbel! :shocked:
De include hoort alleen het fragment van de uitgeknipte menu-code te bevatten, dat er dan door de php-machine op de server weer wordt ingeplakt. Het is dus geen echte complete pagina met een Doctype en <html>-, <head>- en <body>-tags.
Ook de <div id="header"> en de eind-tag </div> daarvan staat al in de index.php, die moet dus niet herhaald worden.

  • Kortom, de header.htm hoort er zo uit te zien: header.htm
    Zie broncode.
De opmaak van dit losse fragment lijkt nergens op, maar dat klopt: dat komt vanzelf goed als het fragment in de index-pagina-is geplakt. :)

De andere includes (0_includes/left.htm en background/main_right.php) hebben hetzelfde euvel: ook dat zijn complete webpagina's i.p.v. code-fragmenten.
De webmaster/mail_inlog.php zal het waarschijnlijk ook hebben, maar die kan ik niet zien omdat ik niet ingelogd ben.

Verder is de main_right.php de eigenlijke inhoud van deze index.php. Die hoeft dan niet binnengehaald te worden via een include, maar kan er rechtstreeks in: er is toch maar één index.php waar deze tekst in moet komen.

Hiermee komt de index.php er als volgt uit te zien:
HTML:
<!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>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    <title>fase 12 | Opdit.nl :: home</title>
 
    <meta name="robots" content="noindex, nofollow" /><!-- alleen voor deze testpagina -->
    <link rel="shortcut icon" type="image/png" href="favicon.png" /><!-- locatie van favicon.ico -->
    <link rel="stylesheet" type="text/css" href="hoofdmenu/pro_pullup_1/pro_drop_1.css" />
    <link rel="stylesheet" type="text/css" href="stylesheets/opdit_custom.css" />
</head>
 
<body>
<?php include("webmaster/mail_inlog.php"); ?>
 
<div id="header"><?php include("0_includes/header.htm"); ?></div>
 
<div id="left"><?php include("0_includes/left.htm"); ?></div>
 
<div id="mainplus">
    <h1>Nieuw in de dowload.</h1>
    <br />
    Font Properties Extension ( van Microsoft ). Is een handig hulpprogramma om meer te weten te komen over de op uw computer 
    ge&iuml;nstalleerde fonts is &quot;Font Properties Extension&quot;. Dit hulpprogramma, 
    dat voluit &quot;OpenType Font Properties Shell Extension&quot; heet, voegt 
    diverse tabbladen toe aan het dialoogvenster Eigenschappen van elk lettertype, 
    waaronder een tabblad Links, met links naar de maker en verkoper van het desbetreffende 
    font en een tabblad &quot;Description&quot; met een beschrijving van het desbetreffende 
    lettertype.<br />
    <br />
    <hr>
    <br />
    <h1>Ondersteuning Windows 7 stopt.</h1>
    ...
    enz.
    ...
    Als je dat liever zelf in de hand hebt, kijk dan bij &quot;XP Tips&quot; hier op de site.<br />
    <br />
    <br />
</div>
 
<div id="leftfooter"><a href="disclaimerencopyright/disclaimerencopyright.php">Disclaimer en Copyright</a></div>
<div id="rightfooter"> &copy; Fere Eadem All rights reserved :: Website designed by Unlimited 1 With 2</div>

</body>
</html>
En voor de andere pagina's gaat dit weer hetzelfde: de pagina-inhoud komt in de <div id="mainplus"></div> te staan.
Alleen de map-positie van de includes en de <title> hoeft te veranderen, verder blijft het hetzelfde.

Als dit zo gedaan is, kunnen we eens kijken naar de andere vraagpunten, want daar valt nu nog niet veel over te zeggen vanwege de incorrecte codes. Met een beetje geluk zijn die vanzelf gesmolten. :)

Met vriendelijke groet,
CSShunter
 
Hallo csshunter,

Je hebt gelijk en dat is ook heel logisch, ik had er niet bij stilgestaan, ik heb het nu aangepast en nu werkt het natuurlijk goed. :)

De webmaster/mail_inlog.php heeft daar geen last van want die komt niet in een <div> terecht.

Dat gaf ook het probleem met de font grote (ik begreep er helemaal niks van), omdat het font al .8em was en daarna vroeg ik weer om .8em, maar dan wordt het .8em van .8em en dat werd als ik het me goed herinner erg klein ( een <div> in een <div> ).

De main_right.php laat ik als een include met het oog op de overzichtelijkheid mijnerzijds.

“Het principe van een PHP-incude” maakt het op een heel duidelijke manier begrijpelijk.


Wat betreft de andere vraagpunten, die zijn nog niet allemaal gesmolten. :confused:

1. Het left_fragment, - Is opgelost :)

2. Als je in de menu balk op “Home” klik, verschoond de hele pagina in een “flits”, dit gebeurd ook bij “Contact” – “E-mail” en “Nieuwsbrief” niet bij de andere menu-keuzes.
Hoe komt dat en is hier wat aan te doen ?

3. Wat betreft de restanten “die zijn blijven hangen” – Die heb ik verschoond en volgens mij is dat nu opgelost. :)

Nieuwe vraag, (schooheid foutjes)

4. Als je in “Computer” – Windows 7 Tip’s en/of XP Tips ( let op de boven-marge van de pagina ( :: XP Tip’s :: )) aanklikt en dan een item aanklikt ga je er netjes naar toe, maar als je dan weer op terug naar boven klikt (plaatje), staat de bovenkant van de page iets hoger dan wanneer je begon.
Hoe komt dat en is hier wat aan te doen ?

5. Als je in het begin op “opdit_csh komt” ( let op de linker kolom ( main_left )) waar staat “Last Update” en je gaat daarna naar een ander item uit de menubalk, dan verspringt “Last Update” iets naar rechts.
Hoe komt dat en is hier wat aan te doen ?
 
Hoi,
ik heb het nu aangepast en nu werkt het natuurlijk goed
Nog niet helemaal ... in de broncode van de huidige index.php (via internet/browser) zie ik nog staan:

<!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>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>fase 11 | Opdit.nl :: home</title>

<meta name="robots" content="noindex, nofollow" /><!-- alleen voor deze testpagina -->
<!-- http://www.helpmij.nl/forum/showthread.php/717477-onclick-2-frames-vernieuwen -->

<link rel="shortcut icon" type="image/png" href="favicon.png" /><!-- locatie van favicon.ico -->
<link rel="stylesheet" type="text/css" href="hoofdmenu/pro_pullup_1/pro_drop_1.css" />
<link rel="stylesheet" type="text/css" href="stylesheets/opdit_custom.css" />

</head>

<body>
<html>
<head>
<title>Mail-Inlog</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>

<body>

<html>
<head>
<title>Users</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>



</html>

</body>
</html>

<div id="header"> <span class="preload1"></span> <span class="preload2"></span>
... enz.​

Nu zijn de includes voor de header, het menu en de maincontent in orde, dus misschien zit er nog een Doctype<html><head><body> in de leftfooter en/of rightfooter?

[ De eerdere kleine letters kan kloppen: de font-size wordt geërfd, en .8em van .8em levert dan een font-size van .64em. :cool: ]

=======

Ad 1
Opgelost: mooi zo!

=======

Ad 2
De flits. Ja, daar had ik me bij de index ook al over verbaasd. En wat me ook verbaasde:
Maar "vanzelf" bestaat niet! :)
Er is dus ergens een opdracht (die je van buitenaf niet kunt zien) die dat regelt. De flits zal waarschijnlijk ontstaan omdat het ophalen en reproduceren van de resolutie-gegevens wat tijd kost, vermoed ik.
Voor zover ik kan zien, is het geen php-opdracht in de pagina's zelf.
Heb je ooit eens met de .htaccess gespeeld, en staat het soms daarin?

=======

Ad 3
De opgeschoonde restanten: zie hierboven.

=======

Ad 4
De Top die niet naar de Top gaat. Dat komt omdat een <p> uit zichzelf (zonder tegenbericht in de css) een margin-top heeft (en ook een margin-bottom), die niet meegerekend wordt als je een bladwijzer aan de <p> geeft:

top-margin.png

Je krijgt 'm wel bovenaan als je in plaats van:
HTML:
<div id="mainmin">
    <p class="center"><a name="Top"></a>:: XP tips ::</p>
...
... de bladwijzer naar boven de <p> haalt:
HTML:
<div id="mainmin">
   <a name="Top"></a>
   <p class="center">:: XP tips ::</p>
...

=======

Ad 5
Verspringen van de "Last update". Dat komt omdat deze tekst gecentreerd staat en de linkerkolom op de ene pagina een scroolbar heeft en op de andere niet. Dan gaat de breedte van de scrollbar van de breedte van de kolom af, en komt het midden iets meer naar links resp. rechts te liggen.
Je kunt er van af komen door de ruimte voor de scrollbar altijd te reserveren, door middel van:
Code:
#left {
    ...
    overflow-y: scroll;
    }
Met vriendelijke groet,
CSShunter
 
Hallo csshunter,

Het verder opschonen van de bron_code is volgens mij nu gelukt, de oorzaak zat in “mail_inlog.php” en “user.php”.
De “leftfooter” en de “rightfooter” waren en zijn schoon. :)

Ad 2.
Wat betreft “de flits”, ik denk dat het probleem in de “mail_inlog.php” zit, deze wordt ge-include als je op de websit binnen komt en het zelfde script met de aanvulling van het “input_form” gebruik ik ook voor de contact_mail en de nieuwsbrief_mail.
Alle drie de scripts vragen de “width – height en colorDepth” op.

Als ik de include weg laat uit index.php en klik op "Home" is de flits weg en zo ook de “width – height en colorDepth” in de browserbalk.

Op de oude "opdit.nl gebruik ik precies het zelfde “mail_inlog.php” script maar dan via "rightframe.php", daar doet het probleem zich niet voor en op die manier wordt hij ook maar 1 keer ge-include als je op de website binnen komt, daarna wordt "rightframe.php" niet meer verschoond of herladen.

in de nieuwe "opdit_csh" wordt "rightframe.php" niet meer gebruikt en wordt “mail_inlog.php” ge-include via "index.php" en dus ook iedere keer als je op "Home" klikt.
De “mail_inlog.php” zou dus eigenlijk losgekoppeld moeten worden van de "index.php" en geplaatst moeten worden in iets wat maar 1 keer wordt geladen en daarna met rust gelaten wordt.

De vraag blijft, hoe komen deze waardes in de browserbalk te staan en wat veroorzaakt "de flits".

Zie script.

PHP:
<?php

		$nietmailen = array('xxx.xxx.xxx.xxx');

	// Breedte en Hoogte Schermresolutie _____________________________

		if (isset($_GET['width']) AND isset($_GET['height'])) {
   
		$breedte = $_GET['width'];
		$hoogte = $_GET['height'];
		$kleur = $_GET['colorDepth'] . " Bit's";
		$resolutie = $breedte . " X " . $hoogte;
	}

		else {

		echo "<script language='javascript'>\n";
		echo "  location.href=\"${_SERVER['SCRIPT_NAME']}?${_SERVER['QUERY_STRING']}"
           	. "&width=\" + screen.width + \"&height=\" + screen.height + \"&colorDepth=\" + screen.colorDepth \n";
		echo "</script>\n";
		exit();
	}
	
	// Users en IP Nummer ____________________________________________

		include("users.php");
		
		$hostname = trim(gethostbyaddr($_SERVER['REMOTE_ADDR']));
 		$host = substr($hostname, strpos($hostname, ".") + 1);
		$ref = $_SERVER['HTTP_REFERER'];
 		$uri = $_SERVER['REQUEST_URI'];
		$uri = explode("?",$uri);
		$uri = $uri[0];
		
		$ipnum = $_SERVER['REMOTE_ADDR'];
		
		if(empty($users[$ipnum][0])) { $naam = 'Onbekend'; } else { $naam = $users[$ipnum][0]; }
		if(empty($users[$ipnum][0])) { $naamonb = $ipnum; } else { $naamonb = $users[$ipnum][0]; }		
		if(empty($users[$ipnum][1])) { $email = 'Onbekend'; } else { $naam = $users[$ipnum][1]; }

	// Browser _______________________________________________________
		
		if (strpos($_SERVER['HTTP_USER_AGENT'], 'Safari')) { $browser = 'Safari'; }
			
			elseif (strpos($_SERVER['HTTP_USER_AGENT'], 'Gecko')) {

			if (strpos($_SERVER['HTTP_USER_AGENT'], 'Netscape')) {
				$browser = 'Netscape'; } 
			  
			elseif (strpos($_SERVER['HTTP_USER_AGENT'], 'Firefox')) {
				$browser = 'Firefox'; } 
			  
			else { $browser = 'Mozilla'; }}
			
			elseif (strpos($_SERVER['HTTP_USER_AGENT'], 'MSIE')) {
				$browser = 'Internet Explorer'; }
				
			else if (strpos($_SERVER['HTTP_USER_AGENT'], 'Opera') === true) { $browser = 'Opera'; }
				
			else { $browser = 'Browser onbekend'; }

	// Bericht maken _________________________________________________

		$aan       = "Webmaster@opdit.nl";
		$betreft   = "Ingelogd op csh door " . $naamonb ;		
		$betreft1  = "Ingelogd op csh";
	
		$bericht = $betreft1 . "<br />";
    	$bericht .= "___________________________________<br /><br />";
	    $bericht .= "Door. . . . . . . : " . $naam . "<br />";
	    $bericht .= "IP - adres. . . . : " . $ipnum . "<br />";
	    $bericht .= "Provider. . . . . : " . $host . "<br />";
	    $bericht .= "Datum . . . . . . : " . date('d-m-Y',time()) . "<br />";
	    $bericht .= "Tijd. . . . . . . : " . date('H:i:s',time()) . "<br />";
	    $bericht .= "Emailadres. . . . : " . $email . "<br />";
	    $bericht .= "Browser . . . . . : " . $browser . "<br />";
	    $bericht .= "HTTP Referer. . . : " . $ref . "<br />";
	    $bericht .= "Request URI . . . : " . $uri . "<br />";
	    $bericht .= "Resolutie . . . . : " . $breedte . " x " . $hoogte . "<br />";
	    $bericht .= "Kleur diepte. . . : " . $kleur . "<br />";
	    $bericht .= "___________________________________<br />";
	
		$headers  = 'MIME-Version: 1.0' . "\r\n";
	    $headers .= 'Content-type: text/html; charset=iso-8859-1' . "\r\n";
		$headers .= "From: Info @ " . $_SERVER['SERVER_NAME'] . "\r\n";
	
	// Bericht versturen _____________________________________________
	
	if(!in_array($ipnum,$nietmailen)) {
	
		mail($aan, $betreft, '<font face="Courier New" size="2">' . nl2br($bericht) . '</font>', $headers);
	}

?>
De .htaccess is schoon, dus daar ligt het niet aan.

Ad 4.
:) Prachtig en is opgelost !

Ad 5.
De “overflow-y: scroll;“ heb ik geprobeerd maar het werkt niet, wat me wel opviel is, dat als je het browser_scherm vertikaal kleiner maakt de tweede regel naar rechts schuift in plaats van de eerste.
 
Laatst bewerkt:
Hoi Broertjuhhh,

Ad 2
Aha, het begint wat duidelijker te worden.
Geen flits en geen achtervoegsels in de oude frameset-versie.
Dat klopt nu als een bus: geen flits omdat het rightframe er maar 1 keer in gezet wordt. En geen achtervoegsels omdat die geplaatst worden achter de pagina waar de include mail_inlog.php in zit. Dat is dus de pagina rightframe.php.
  • Vraag je die pagina los op, (klik: [url]www.opdit.nl/background/rightframe.php[/URL]), dan wordt de resolutie/kleurdiepte er inderdaad achter gezet. Maar vanwege de frame-opbouw is het webadres van die pagina niet te zien: alleen het webadres van de frameset-pagina (= de oude index.php) verschijnt in de adresbalk.
Nu de nieuwe versie.
Ook hier klopt je analyse.
De “mail_inlog.php” zou dus eigenlijk losgekoppeld moeten worden van de "index.php" en geplaatst moeten worden in iets wat maar 1 keer wordt geladen en daarna met rust gelaten wordt.
Eh, ja, misschien: ik kan dit niet helemaal overzien.
Wat het bovenstaande php-script van de mail_inlog.php doet, is het verzamelen van allerlei gegevens van iemand die ingelogd is en een mail-bericht wil sturen: om die gegevens aan het bericht vast te plakken.
  • Hoe dat precies in zijn werk gaat, is ook afhankelijk van wat er in de users.php staat, want die wordt op zijn beurt als include binnengehaald in de mail_inlog.php. - De code van de users.php kan ik echter van buitenaf niet zien.
Maar de hele functie van de mail_inlog.php ontgaat mij eigenlijk, want ik kan nergens op de site een inlog-optie bekennen.
Net even een test-mailtje op de oude site gestuurd: dat ging gewoon zonder inloggen. Of doet de mail_inlog.php het altijd, en heeft deze niets met inloggen te maken? - In elk geval kreeg ik na de "Verzend" een keurige reactie "Bedankt voor je E-mail, we zullen je E-mail zo snel mogelijk beantwoorden."
(Dat zal niet gaan, want het was een fake-mailadres. ;) )

=======
De vraag blijft, hoe komen deze waardes in de browserbalk te staan en wat veroorzaakt "de flits".
Voor zover ik er verstand van heb, werkt de php in de mail_inlog.php als volgt:
  • Eerst wordt gekeken of er in de URL van de adresbalk een parameter voor de breedte bestaat: if (isset($_GET['width']).
  • Idem voor de schermhoogte.
  • Is dat het geval, dan wordt de waarde van de breedte, hoogte enz. genoteerd in de variabelen $breedte, $hoogte, enz.; die variabelen worden dan later gebruikt in de met het mailtje mee te sturen gegevens.
  • Is dat niet het geval, dan wordt het javascript eronder van toepassing verklaard.

  • Dat is 'm! :) Want dit javascript maakt een nieuwe URL aan met z'n "location.href", en die nieuwe URL bestaat uit de oude locatie plus "width=" met daarachter de opgevraagde "screen.width"; plus voor de hoogte en de kleurdiepte idem dito.

  • Na het inplanten van het javascript in de pagina wordt met exit() de rest van het php-script niet uitgevoerd.
  • De "location.href" is een redirect: de pagina wordt acuut vervangen door een pagina met de nieuwe URL. In dit geval is het dezelfde pagina, maar dan met toevoeging van de parameters. Maar dat kan de browser niet weten: die gaat gewoon de "nieuwe" pagina nog eens inladen.
Nu de praktijk.
  • In den beginne staat er nog niets achter de URL. Dus het javascript wordt op de pagina geplaatst. Zodra de browser de pagina (incl. het javascript) binnen heeft, gaat het javascript in werking: de pagina wordt "omgeleid" naar zichzelf met de variabelen in de achtervoegsels.
  • De nieuwe pagina met de achtervoegsels heeft nog steeds de mail_inlog.php in z'n html-code staan!
  • Dus de php-riedel wordt nog een keer toegepast. Dit keer zijn er wel achtervoegsels, dus de variabelen kunnen genoteerd worden en het javascript wordt niet opnieuw geplaatst; en het vervolg van het php-script gaat ook door.
  • - Dit alles zou best wel eens met een flits gepaard kunnen gaan!
  • Wellicht is er ook bij de eerste keer aanroepen van de pagina (nog zonder de achtervoegsels) een flits door de nodige afhandelingstijd van het script-gebeuren, maar dat kan je niet zien omdat er nog geen opdit-pagina in de browser staat.
  • Bij aanwezigheid van de pagina en een klik op de Home-knop moet het feest ook gebeuren: dat zou de flits kunnen geven.
Nog een ander gevolg (zie ik nu pas):
  • Als javascript in de browser uit staat en je roept [url]www.opdit.nl/test/opdit_csh/index.php[/URL] voor het eerst aan, dan komt er geen site tevoorschijn, maar alleen de kop! :eek:
  • Oorzaak: er zijn nog geen achtervoegsels, dus het javascipt wordt ingepoot (op de plaats waar de include staat), en daarna wordt de pagina niet verder getoond (wegens de exit). Maar het javascript staat uit, en de redirect met de achtervoegsels komt er niet. Er gebeurt helemaal niets meer!
  • Test: zet javascript uit en vraag de [url]www.opdit.nl/test/opdit_csh/index.php[/URL] op. Geen website - in de broncode staat er niets in de <body> behalve het javascript (dat niet werkt!).
Naar een oplossing.
  1. Als je niet perse de resolutie en kleurdiepte van de mailende bezoeker wilt weten, kan het hele beginstuk uit de mail_inlog.php gehaald worden, dan heb je nergens last van m.b.t. redirecten en achtervoegsels. Of de flits dan weg is, weet ik niet (dat zou ook van de inhoud van de users.php af kunnen hangen).
  2. Op de homepage kan de mail_inlog.php include sowieso gemist worden, want daar is geen mail-optie; dan zou de flits alleen nog op de mail- en nieuwsbrief-pagina kunnen gebeuren.
  3. Nu worden zo te zien alle gegevens voor de mailverzending tevoren (op de pagina zelf) gecheckt. Met een php-afhandelingsscript dat pas na het verzenden in werking treedt, kan ook de veiligheid gewaarborgd worden; en dat kan geen flits veroorzaken.
    Dan mis je denk ik wel alle mee te sturen gegevens van de bezoekers-computer, maar de vraag is of je al die gegevens altijd echt nodig hebt voor het beantwoorden van een mailtje.
    Voor het geval je ze wel nodig mocht hebben, zou je een aparte mailpagina ("met flits") kunnen maken, en de bezoeker in je reactie-mailtje kunnen vragen die pagina ook even te verzenden; of zonder extra pagina: alleen vragen wat je nodig hebt.
Meer kan ik niet verzinnen. ;)

=======

Ad 5
Verspringen linkerkolom: hé, dat snap ik niet.
  • Als ik left {overflow-y: scroll;} toevoeg en deze pagina's opdit_csh-kort.htm en opdit_csh-lang.htm in twee tabbladen naast elkaar zet dan zie ik niets verspringen.
  • Dit geldt voor Firefox, Chrome, Opera, Safari en Internet Explorer 7: alles gaat goed.
  • In welke browser en bij welke resolutie gaat het bij jou mis?
... als je het browser_scherm vertikaal kleiner maakt de tweede regel naar rechts schuift in plaats van de eerste.
Bij mij niets van te zien: welke browser?

Met vriendelijke groet,
CSShunter
 
Laatst bewerkt:
Hallo csshunter,

Ad 2.

Dat is op zich dan een voordeel van een Frameset.

De nieuwe versie.

De user.php is een array en stelt niet zoveel voor, Zie scriptje.
PHP:
<?php

		//Gebruikergegevens
		$users['xxx.xxx.xxx.xxx'] = array('Piet', '');
		$users['xxx.xxx.xxx.xxx'] = array('KLaas', '');
		$users['xxx.xxx.xxx.xxx'] = array('Jan', '');
		$users['xxx.xxx.xxx.xxx'] = array('Kees', '');

		enz.
?>
Je hoeft niet en kan niet inloggen op opdit.nl, de mail_inlog.php werkt altijd.


De vraag blijft.

Ik kom tot de zelfde analyse.

• Deze parameters zijn er natuurlijk nooit, dus waarom kijken of ze er zijn als je van te voren al weet dat ze er niet zijn.
Het is waarschijnlijk de enige manier om het te doen, maar waarom niet gewoon direct de parameter aan de server vragen en door geven.

Naar een oplossing.

1.
Als ik het begin stuk uit de mail_inlog.php haal dan heb ik inderdaad geen last meer van de riderect en de flits is weg.
User.php heeft hier geen invloed op.

2.
De mail_inlog.php is er zodat ik kan zien dat er iemand opdit.nl bezocht heeft, niks meer en niks minder.
Het probleem blijft echter bestaan dat als er op “Home” geklikt wordt er weer een mail verzonden wordt.
Is er niet iets dat er voor zorgen kan dat de mail_inlog.php maar 1 keer doorlopen wordt en daar na zichzelf uitschakelt ?

3.
Alle gegevens zijn niet noodzakelijk, maar de techniek is er, waarom zou je die dan niet toepassen.
Als het echt niet anders kan laat ik het javascript stukje van de resolutie en kleurdiepte gewoon vallen.
Dit ook met het oog op wat je zij betreffende javascript, staat deze aan of uit, in het geval deze uit staat werkt de imageslider ook niet. :(

Ad 5.
Mijn browser is Firefox 16, en internet explorrer 8, mijn resolutie 1680 x 1050.

Als je net aan komt op, opdit.nl zie je de “:: uitgelicht ::”page ( met scrollbar ), als je dan op bijv. “download” – “Microsoft” klikt, ( ook met scrollbar ), verschuifd “Last update” naar rechts. :confused:

Het volgende zie ik nu pas, als ik met IE 8 naar de opdit_csh ga, gebeuren er rare dingen.
De kleur van de top is lichter dan de achtergrond en zie je daar door een scheiding.
Ik denk dat voor IE 8 de top te hoog wordt geplaatst en als je een item kiest uit de menubalk, verdwijnt de achtergrond (opdit-bg.png) en springt de hele site naar links. :confused:
 
• Deze parameters zijn er natuurlijk nooit, dus waarom kijken of ze er zijn als je van te voren al weet dat ze er niet zijn.
Het is waarschijnlijk de enige manier om het te doen, maar waarom niet gewoon direct de parameter aan de server vragen en door geven.
Als volgt:
  • De mail wordt serverside verzorgd met PHP, en PHP gaat aan de slag voordat de bezoeker de pagina toegezonden krijgt.
  • Er zijn geen PHP-commando's om de maten/kleurdiepte van de browser op te vragen.
  • Er zijn wel een javascript-commando's om die op te vragen.
  • Maar javascript werkt client-side, in de browser van de bezoeker; dus pas nadat de php-pagina al helemaal binnen is.
  • Daarna kan javascript geen boodschap meer terugsturen naar dezelfde pagina waar de mail_inlog.php in zit.
  • Javascript kan wel een boodschap meegeven aan een volgende php-pagina: en de redirect met de achtervoegsels is die volgende pagina.
  • Uit de achtervoegsels kan de php-machine nu wel de maten/kleurdiepte halen (en verwerken in de mail), voordat die volgende pagina (= dezelfde pagina) nog eens naar de browser gaat.

=======
Naar een oplossing
De mail_inlog.php is er zodat ik kan zien dat er iemand opdit.nl bezocht heeft, niks meer en niks minder.
Aha: dat zou ervoor pleiten om het script op elke pagina te includen (net zoals in de frameset-versie), want een bezoeker hoeft niet altijd op de homepage binnen te zeilen.
  • Vraag: als iemand in de oude versie van de ene naar de andere pagina op opdit.nl surft, krijg je dan bij elke nieuwe pagina (c.q. opnieuw bezochte pagina) een nieuw mailtje, of wordt dit door het mailscript tegengehouden? (daarvoor weet ik niet genoeg van php af)

=======
Maar rechtstreeks includen van het php-script (incl. het javascript met redirect) heeft behalve de flits nog een ander nadeel, bedenk ik nu:
Google kan geen javascript lezen! Dat betekent:
  • De Google-bot kan bij zijn eerste bezoek van de homepage (of een andere pagina) niet verder komen dan het niet-werkende javascript, en dan zegt de php dat er ge-exit moet worden.
  • De Google-bot ziet dat er niets in de <body> van de pagina staat, en gaat zijns weegs (op weg naar andere websites).
  • Maar niet alleen wordt de pagina zelf niet of nauwelijks geïndiceerd (en voor zover: bijzonder laag in de ranking, want geen tekst/trefwoorden te zien), Google ziet ook geen menu met de links naar de andere pagina's: die worden overgeslagen!
Dat pleit ervoor om toch stiekem in de frame-business te gaan: een <iframe> waar het php-/javascript in zit. Drie vliegen in 1 klap: geen flits, geen achtervoegsels op de pagina zelf, en toch alle gegevens. :)

=======
Is er niet iets dat er voor zorgen kan dat de mail_inlog.php maar 1 keer doorlopen wordt en daar na zichzelf uitschakelt ?
Ja, als dat nu in de oude versie niet zo is, zal dat erbij gemaakt moeten worden.
  • Ik denk dat dat met een cookie kan: bij de eerste keer wordt een cookie "ben hier al geweest" gezet, bij de volgende keren wordt dan niet meer gemaild.
  • Je hebt dan niet meer je mooie cookie-vrije site, en er zal naar de letter van de wet een cookie-akkoordvraag bij moeten (= extra script).

=======
Maar iets heel anders.
Als je met FTP op de server gaat snuffelen in de hogere of parallel-mappen van de public_html, zit daar dan niet een map "logs" of iets dergelijks in, waar de server uit zichzelf al boekhouding doet over wie wanneer hoe is langsgekomen?
Of eventueel via het beheer-paneel van je account?
Als dat het geval is, kan je die gegevens van tijd tot tijd raadplegen, en is het hele handeltje niet nodig! :)

=======

Ad 5.
Ja, maar je hebt ook nog niet de #left {overflow-y: scroll;} aan het stylesheet toegevoegd.


=======
Een nieuwe!

Ad 6
IE 8 ...
als je in IE8 een item kiest uit de menubalk, verdwijnt de achtergrond (opdit-bg.png) en springt de hele site naar links.
Ah, hier komt de kloppende zwerende vinger weer eens om de hoek kijken! :p
  • De vervolg-pagina 's hebben géén Doctype, en daar kan IE niet tegen!
  • Zonder Doctype schiet IE in de "quirksmode", een fratsentoestand waarbij IE alles gaat renderen alsof het IE5 is (die de css-standaarden niet volgde): en dan komt alles schots en scheef te staan (als er al wat te zien is).
  • Leesvoer: alhier!
Ook de testpagina hierboven voor de uitgegrijsde scrollbar heeft dit euvel.
Maar zet je er een geldig Doctype boven, dan doet IE wel wat er verwacht mag worden.
=======
Ad 7
IE 8 ...
De kleur van de top is lichter dan de achtergrond en zie je daar door een scheiding.
Ik denk dat voor IE 8 de top te hoog wordt geplaatst.
Dat dacht ik ook, en het Doctype verhelpt dat niet.
Vergelijken van screenshots in een tekenprogramma leert: de positie is toch precies hetzelfde.
De oorzaak is: IE kan nog steeds niet goed .png's renderen.
Heb je een losse png, dan valt dat niet op.
Maar heb je, zoals hier het geval is, een png die naadloos moet aansluiten op een jpg, dan valt het wel op!
De pagina-background bovenaan (over de volle breedte) is een png, de header-background is een jpg: dusdoende.

Je hebt wat te stellen met die ongehoorzame IE-kindertjes! :d

Met vriendelijke groet,
CSShunter
 
Hallo csshunter,

Als volgt:

Bedankt voor de uitleg (nothing is perfect ) ;)

Naar een oplossing:

Dat zou te gek worden ( in de frameset versie heb ik dat ook niet ), ik denk dat 90% en zo niet meer, gewoon via het begin binnenkomt.

• Nee, alleen bij het “start bezoek” de “contact_mail” en de “nieuwsbrief”.

====

Google:

• 3 x mee eens.

Hoe zou zo’n <iframe> er uit gaan zien ?
Hoe maak je een cookie ?

=====

Maar iets heel anders:

Ik heb even gekeken en de logs zijn er wel maar die zijn helaas niet bruikbaar.
Zo ook het beheer paneel niet.

Ad 5.

Ik heb de #left {overflow-y: scroll;} er in gehad maar ik zag geen verschil en toen weer verwijderd en inderdaad zo erg is het ook niet. :)

Ad 6.

Ik heb Doctype toe gevoegd en het is nu opgelost. :)

Ad 7.

Daar maak ik dus een jpgtje van, gebeurd en opgelost. :d
 
Hoi Broertjuhhh,
Hoe zou zo’n <iframe> er uit gaan zien ?
Hoe maak je een cookie ?
Hier snelt javascript te hulp:
  1. Op de homepage zet je ergens een lege <div id="statistic"></div>. Die gaat de kapstok worden voor het iframe.
  2. Als er een cookie is, gebeurt er niets.
  3. Als er geen cookie is, wordt die <div> gevuld met het (overigens onzichtbare) iframe: en daarin zit het verstuur-apparaat mail_inlog.php. En tegelijkertijd wordt er een cookie geplaatst ter verhindering van later nog eens.
  4. Staat javascript bij de bezoeker uit: dan geen cookie, geen iframe, geen mailtje (en geen slideshow in de linkerkolom).
Realisatie door helemaal op het eind van de pagina te zetten:
[JS]...
<div id="statistic" style="position: absolute; width: 100%; top: 0; right: 0; display: none;"></div>

<script type="text/javascript">
//<![CDATA[
if (document.cookie.indexOf('stat=ok')==-1){
// alleen als géén koekje "stat=ok" bestaat,
// dan statistic-div aanzetten:
document.getElementById('statistic').style.display="block";
// en vullen met het iframe met de pagina voor het statistiek-mailtje:
document.getElementById('statistic').innerHTML='<iframe frameborder="0" style="width: 100%; height: 2.5em; border: 0;" src="mail_inlog.php"></iframe>';
// plus koekje plaatsen om het bij het volgende pagina-bezoek niet nog eens te doen
document.cookie='stat=ok'; // en koekje plaatsen om het bij het volgende pagina-bezoek niet nog eens te doen }
//]]>
</script>

</body>
</html>
[/JS]
(De document.cookie is de waslijst van alle cookies [met hun inhoud/waarden] die op een bepaald moment door een site geplaatst zijn.)
(Een indexOf('...') van een string betekent bij javascript: de positie van het eerste teken van die string.)
(Een "==-1" betekent bij javascript: "bestaat niet"; een "!=-1" betekent "niet gelijk aan bestaat niet" = "bestaat wel".)
(En als het eerste teken van een bepaalde cookie-string niet bestaat, dan bestaat dat specifieke cookie dus kennelijk niet; vice versa.)

  • Test: opdit_csh-iframe-cookie.htm

  • Open je deze de eerste keer, dan wordt het iframe geactiveerd (wordt in de test getoond met een placeholder).
  • Bij een refresh van de pagina is de placeholder verdwenen: het iframe is gedeactiveerd, er wordt niet nog eens een mailtje gestuurd.
=======

Hier zit echter een MAAR aan vast! ;)
Het zal in 97,4% van de gevallen vlekkeloos weken, maar ... als een bezoeker onverhoopt in zijn/haar browser het zetten van cookies uit heeft staan (en javascript ingeschakeld), dan wordt het cookie niet gezien, dus het javascript zal dan altijd het iframe en het mailform activeren > bij elk paginabezoek een vers mailtje! :rolleyes:
Dat is niet helemaal de bedoeling, dus moet het anders aangepakt worden.

Oplossing is om een extra verklap-koekje te plaatsen: een ander cookie, dat altijd door de pagina geplaatst wordt.
Het script begint vervolgens te kijken of dat koekje gevonden wordt. Zo niet, dan staan cookies uit, en wordt het script verder bevroren: er komt géén iframe (en ook geen mailtje).
Wordt het extra koekje wel gevonden, dan wordt gekeken of het andere koekje al geplaatst is: zo nee > iframe, zo ja > niks.
Realisatie:
[JS]...
<div id="statistic" style="position: absolute; width: 100%; top: 0; right: 0; display: none;"></div>

<script type="text/javascript">
//<![CDATA[
// cookie plaatsen om te kunnen zien of cookies ingeschakeld staan:
document.cookie='koekjes=ok';

// alleen als dit cookie bestaat (dan zijn ze ingeschakeld), maar er tegelijkertijd geen cookie "gemeld=ok" is:
if (document.cookie.indexOf('koekjes=ok')!=-1 && document.cookie.indexOf('gemeld=ok')==-1 ) {
// dan statistic-div aanzetten:
document.getElementById('statistic').style.display="block";
// en vullen met het iframe met de pagina voor het statistiek-mailtje:
document.getElementById('statistic').innerHTML='<iframe frameborder="0" style="width: 100%; height: 2.5em; border: 0;" src="mail_inlog.php"></iframe>';
// plus koekje plaatsen om het bij het volgende pagina-bezoek niet nog eens te doen
document.cookie='gemeld=ok';
}
//]]>
</script>

</body>
</html>[/JS]
  • Test: opdit_csh-iframe-cookie-2.htm

  • Nu gaat het wel goed als cookies uitgezet zijn: dit is dus de goede! :)
  • Staat javascript bij de bezoeker uit: dan eveneens geen cookie, geen iframe, geen mailtje (en geen slideshow in de linkerkolom).
Het script kan zonder bezwaar (met een mooie php-include) op elke pagina toegevoegd worden, dan kan iemand ook op een andere pagina dan de homepage binnenvallen zonder dat er dubbel gemaild wordt.

Gaat dat werken?

Met vriendelijke groet,
CSShunter
 
Hoi Broertjuhhh,
"Ik heb de opdit.nl overgezet en alle links aangepast, maar de imageslider en aarde werken niet, op de één of andere manier kunnen ze de foto's niet vinden."

1. Imageslider in linkerkolom
De imageslider geeft inderdaad een hele rare (niet-bestaande) vindplaats voor de foto's. Als je de gegenereerde broncode bekijkt (nadat javascript is toegepast), zie je staan:
HTML:
<img width="150" height="150" name="tslide0_0" alt="Computer kasten" title="Computer kasten" 
    src="%27,%20this.a_items%5B0%5D%20,%20%27">
<img width="150" height="150" name="tslide0_1" alt="Computer kasten" title="Computer kasten" 
    style="position: relative; z-index: 1; margin-left: -150px; opacity: 0;" 
    src="%27,%20this.a_items%5Bi%5D%20,%20%27">
... enz.
Een kijkje in het tigraFader javascript opdit.nl/js/tFader.js laat zien dat daar de fout in zit. Er staat op een gegeven moment als opdracht om de images binnen te halen:
[JS]...
document.write ('<img src="%27,%20this.a_items%5B0%5D%20,%20%27"', s_attributes, ' name="tslide', this.n_id, '_0" />');[/JS]
Die %-getallen hierin zijn "html-entities" voor lettertekens, d.w.z. daarvan wordt niet de inhoud/betekenis weergegeven (een %20 is bv. een spatie) maar ze komen 1:1 in de html-code te staan. Op die manier kunnen de javascipt-bewerkers van de browsers het script niet begrijpen, en de bedoelde variabelen (this.a_items) kunnen niet opgehaald worden.
De vertaling is:
[JS]', this.a_items[0] , '[/JS]
Het hoort zodoende te zijn:
[JS]...
document.write ('<img src="', this.a_items[0] , '"', s_attributes, ' name="tslide', this.n_id, '_0" />');[/JS]
Een Google leerde verder dat jouw versie (van 06/06/2012) niet de meest recente is.
Ik kwam er eentje tegen van 08/28/2012.

Als ik die inmonteer in de pagina, gaat het goed:
=======
2. Internet Explorer!
Even iets anders: ik zou de "Best viewed width Firefox" achterwege laten:
  • Dat wordt al gauw gezien als bewijs van onvermogen om een goede cross-browser website te maken.
  • Bovendien klopt het niet: met Chrome, Opera, Safari komt de pagina óók prima tevoorschijn! En volgens Browsershots IE9 eveneens.
  • Alleen IE8 en IE7 haken af bij de slider, en geven het alert-bericht "last element of the items structure is undefined".
Maar ... dit bericht wordt door het script gemaakt, en duidt er op dat er iets niet klopt met het laatste opgegeven foto-item van de slider.
Dat staat op de pagina zelf bij de configuratie van de fader onder "// list of images to display":
[js]// list of images to display
var A_ITEMS = [
'http://opdit.nl/imageslider/img/kl_fractal_design_define_r3_black_pearl.jpg',
'http://opdit.nl/imageslider/img/kl_lian_li_pc_888.jpg',
'http://opdit.nl/imageslider/img/kl_lian_li_pc_u6.jpg',
'http://opdit.nl/imageslider/img/kl_thermaltake_level_10_gt.jpg',
'http://opdit.nl/imageslider/img/kl_thomas_thomassen.jpg',
'http://opdit.nl/imageslider/img/kl_x_pc_medion.jpg',
];
[/js]
Aha, na het laatste item staat er per abuis een komma: bij zo'n rijtje geeft een komma aan dat er nog iets komt (maar dat komt niet).
Het moet dus worden:
[JS]// list of images to display
var A_ITEMS = [
'http://opdit.nl/imageslider/img/kl_fractal_design_define_r3_black_pearl.jpg',
'http://opdit.nl/imageslider/img/kl_lian_li_pc_888.jpg',
'http://opdit.nl/imageslider/img/kl_lian_li_pc_u6.jpg',
'http://opdit.nl/imageslider/img/kl_thermaltake_level_10_gt.jpg',
'http://opdit.nl/imageslider/img/kl_thomas_thomassen.jpg',
'http://opdit.nl/imageslider/img/kl_x_pc_medion.jpg'
];
[/JS]
Hé, nu doen IE7 en IE8 het opeens wel! :)

=======
Nog iets: het script houdt niet helemaal rekening met de verschillende manieren waarop de diverse IE-versies met opacity omgaan.

=======
3. Pagina Aarde
Hier is de fader/slider ook toegepast op de aarde-foto's en speelt hetzelfde:
  • Ook hier moet de link naar het tFader-script vervangen worden.
  • NB-1: Op deze pagina wordt het script 2 keer aangeroepen, maar 1 keer is genoeg: de script-link in de <head> kan gewoon weggelaten worden.
  • NB-2: Ook hier moet de komma voor het laatste linkerkolom-image er uit
  • NB-3: Hier gaat het goed met de image-list van de Aarde-foto's (zonder komma bij de laatste).
Even proberen:
Met vriendelijke groet,
CSShunter
_______
PS: Ik geef er de voorkeur aan om (vervolg) Helpmij-vragen via het forum te beantwoorden: dan kunnen anderen er ook nog wat aan hebben. Voor zover ik iets zinnigs te zeggen heb dan. ;)
 
Laatst bewerkt:
Hoi csshunter,

1.

Dat is inderdaad vreemd “voor mij”, nou had ik al gemerkt dat als ik een script save in “Dreamweaver” het soms tijdens het saven veranderd wordt, want als ik het later weer load ziet het er anders uit.
Ik denk dat, dat aan mijn computer of het geheugen ligt en dat moet ik met spoed nakijken want dat is heel irritant :(

Bijv. save ik het zoals het er hier onder uit ziet.

PHP:
<body>

<div id="header"> <?php include("../../0_includes/header.htm"); ?> </div>
<div id="left"> <?php include("../../0_includes/left.htm"); ?> </div>

<div id="mainmin">

En als ik het dan weer load ziet het er onderstaand uit.

PHP:
<body>
<div id="header"> 
 <?php include("../../0_includes/header.htm"); ?>
</div>
<div id="left"> 
 <?php include("../../0_includes/left.htm"); ?>
</div>
<div id="mainmin">

Het Javascript heb ik vervangen en dat werkt :)

Wat ik ook gemerkt heb, is dat relatieve links niet goed werken, dus heb ik die veranderd in absolute links en dan gaat het goed.
Bij de oude site met frames had ik daar geen last van, weet jij wat hier de oorzaak van is ?

2.

Wat betreft “Best viewed width Firefox” heb je gelijk, dat zal ik weg hallen of veranderen in een “cross-browser plaatje (ik had het eigenlijk meer gedaan voor de vulling, ik vind het een beetje kaal daar anders).

3.

NB-1. De tweede aanroep heb ik verwijderd, het feit dat het er zo stond is omdat ik nog niet goed zie hoe het totale script uiteindelijk verwerkt wordt door de server, maar ik begin langzaam aan een lichtpuntje te zien.
Zo is het bekijken van de paginabron ook een goed hulp middel :)

PS: Ik begrijp de stelling volkomen, in dit geval was het omdat ik het adres nog niet wilde vrij geven :o

Nog een vraagje, Ik wil als je in de kop op het logo klikt ook naar “Home” gaat, op de oude site kon ik met “Dreamweaver” een kader trekken waar een link aan vast zat, maar om dat het logo niet meer op deze manier zichtbaar is in “Dreamweaver” kan dat niet meer.
Hoe moet ik dat nu doen ?
 
Laatst bewerkt:
Ad 1
Ik denk dat het %-gedoe in het script aan Dreamweaver ligt, in combinatie met een keertje net verkeerd knippen en plakken, maar dat valt waarschijnlijk niet te achterhalen.
Verder hebben html-editors de neiging om de html-code op hun eigen manier "mooi te maken"; zo ook Dreamweaver. Uit je voorbeeld is bv. te halen dat DW altijd <?php ... ?> commando's op een aparte regel zet. Ook het inspringen bij een nieuw element binnen een ander element kan bij saven anders uitpakken.
  • Maar dat is een kwestie van intern noteren van de html-code, en maakt voor het resultaat niets uit.
  • Als het goed is, zouden er ergens in de DW-instellingen opties moeten zitten om de manier van opslaan te regelen.
Relatieve links: dat kan kloppen, omdat je in de test-versie vanuit andere basismappen werkt dan in de frame-versie. Als je alles met absolute links regelt, heb je er geen last van.
  • NB: Uitzondering vormen de php-includes, die moeten wel relatief blijven. Dat is uit oogpunt van veiligheid: de includes mogen alleen van dezelfde server komen. Als het ook zou werken met "http://www..../mapje/mapje/... ", zou je onderdelen van een andere site kunnen insluiten/aftappen!
=======
Ad 2
Ja, dat kan. Het betekent wel dat het juist "te vol" wordt bij beeldschermen van 1280*1024px of kleiner: dan krijgt de linkerkolom een scrollbar om het crossbrowser-plaatje te kunnen zien.

=======
Ad 3
Ja, dit soort scripts werken zó, dat er een algemeen script is: het aan te haken javascript-bestand. Vervolgens moeten de settings bepaald worden in een javascript op de pagina zelf: waar de slider moet komen, welke images gebruikt moeten worden, tempo van faden, enz. - Dat kan dan bij dit script gelukkig meerdere keren, met verschillende settings.
  • Er zijn ook scripts waarbij deze vlieger niet op gaat (die bv. een bepaald vaststaand id="..." voor de slider-container gebruiken), dat kan niet twee keer, en dat is puur onhandig. Dan moet je ofwel 2 versies van het script gebruiken (met een ander id voor het tweede ding), ofwel het script aanpassen.
=======
Ad PS
Geen probleem - ik heb het niet verklapt! ;)

=======
Ad "Nog een vraagje"
Dat kan door in de <div id="header"> een "lege link" te plaatsen, d.w.z. een link die alleen een oppervlakje heeft en verder transparant is:
HTML:
<div id="header">
	<span class="preload1"></span>
	<span class="preload2"></span>
	<a id="logoHome" href="http://opdit.nl/index.php" title="Home"></a>
 	<ul id="nav">
		<li> enz.
Met als bijbehorende css:
Code:
#logoHome {
	width: 280px; 
	height: 116px; 
	display: block;
	border: 1px dotted fuchsia;
	}
De {display: block} zorgt dat het hele oppervlak aanklikbaar is, ook al staat er niets binnen de <a></a>.
De {padding-top: 116px} van de #nav kan er nu uit, omdat de link diezelfde hoogte heeft.
Voor het uitmikken zet ik er altijd even een tijdelijk bordertje omheen, dan zie je waar ie zit. :)

Je kunt ook de bezoeker nog wat feedback geven bij een hover over het logo, door er dan bv. een punt in te zetten:


Die wordt dan met css op de goede plaats binnen de link gezet als background-image (en overlapt daar de standaard-background):
Code:
#logoHome:hover,
#logoHome:focus {
	background: url(../images/puntnl.png) no-repeat 162px 55px;
	}
Met css kan je je fantasie de vrije loop laten!

Met vriendelijke groet,
CSShunter
 
Hallo csshunter,

Ad 2.

Je hebt gelijk, daar had ik nog even niet aan gedacht.

Ad 3. “Nog een vraagje”

Die stip van de hover, daar moest ik even kostelijk van lachen, prachtig, goed gevonden en zeer geestig :D

Css is niet alleen… “de fantasie is de grens” maar heeft nog humor ook. ;)

Nog 2 nieuwe vraagjes.

1. Windows XP verliest binnenkort zijn ondersteuning :( en ik zou daar graag een aftelklokje in PHP (als dat kan) voor maken, maar ik heb geen id hoe dat te doen.

2. Kan je me adviseren, waar, hoe en op welke pages ik het beste mijn metatags voor google kan neer zetten ?
 
Status
Niet open voor verdere reacties.
Terug
Bovenaan Onderaan