templates: links worden veranderd?!

[dreamcatch]

Hallo,

Hier een newbie op dit forum

Ik kom hier niet helemaal uit, wat doe IK fout?

Hier een stukje code welke correct lijkt in de gemaakte template
(dit werkt perfect, er zijn al meer dan 100 pagina's maar allen zonder template gemaakt):

Dit komt rechtstreeks uit dreamweaver CS4

<link rel="stylesheet" type="text/css" href="/css/styles.css"/>
<link rel="stylesheet" type="text/css" href="/css/sprytab.css"/>
<script src="../../../scripts/bookmarker.js" type="text/javascript"></script>
<script src="../../../scripts/sprytab.js" type="text/javascript"></script>

en hier nog een stukje

<?php 
include ("../../../header/inc_header.php");
include ("../../../banner/inc_banner.php");
include ("../../../alphabet/inc_alphabet.php"); ?>

zoals al opgemerkt werkt dit alles perfect in "normale" omstandigheden, maar nu komt
het volgende resultaat eruit als ik de template gebruik (welke in de folder Templates staat natuurlijk).

Ik klik op nieuw, maak gebruik van Template en dit is er te zien in de code en daaaaaaar
gaat het helemaal fout.

<link rel="stylesheet" type="text/css" href="/css/styles.css"/>
<link rel="stylesheet" type="text/css" href="/css/sprytab.css"/>
<script src=[B]"file:///G|/scripts/bookmarker.js"[/B] type="text/javascript"></script>
<script src=[B]"file:///G|/scripts/sprytab.js"[/B] type="text/javascript"></script>

en deze:

<?php 
include [B]("file:///G|/header/[/B]inc_header.php");
include [B]("../../../ba[/B]nner/inc_banner.php");
include ("../../../alphabet/inc_alphabet.php"); 
?>

Waarom gebeurd dit? nooit eerder gehad want de settings zijn perfect bij gebruik zonder templates.
Wazig dat het gebeurd en onbegrijpelijk als je in het "resultaat" kijkt van de php links...3 regels en dreamweaver "****s-up"
door er gewoon iets van te brouwen of?? sorry voor mijn taal hier maar dit is buitengewoon onlogisch voor mijn simpele verstand.

En nee de code is niet bewerkbaar voor de nieuw te creëren pagina want de settings zijn door mij zo gemaakt dat
een ander ze niet kan/hoeft te wijzigen.

En dan komt nog de popup bij het opslaan dat volgende bestanden (de java scripts natuurlijk) niet bestaan of niet in de folder?????
DUH...wilt u deze kopiëren ja/nee grin...ik gaf ja en resultaat...noppes natuurlijk...kon ook niet anders....maar hoe kan dit nu ????


Wie o wie kan mij hier mee helpen?

ps, links staan in site setting naar de site root en natuurlijk niet naar documenten.

 

[peter vazed]

En wat gebeurt er als je een nieuwe map aanmaakt voor de nieuwe site?
Dus nieuw en dan template inladen,
dan opslaan in de nieuw aangemaakte map,
dan verder werken.

 

[dreamcatch]

Hallo Peter,

Helaas geen ander resultaat...en weer bij het opslaan van de nieuw gemaakte pagina de pop-up met ...

en deze

hier wordt ik dus niet helemaal blij van..maar ook het probleem met de includes is erg
vreemd.
Enig idee??? is dit een bug of zo of hoe kan dit nu?..zoals al gezegd talloze pagina's gemaakt
en nooit problemen.En in een setting van 3 regels, de includes, 2 verschillende resultaten....

Nu eindelijk na een helder moment van verstandsverbijstering dacht ik..laat ik eens een template maken..
maar dat lijkt dus een slechte idee....en cms is net eigenlijk een beetje te hoog voor deze jongen
want van mysql heb ik (nog) geen kaas gegeten helaas.

grts en toch alvast bedankt voor de snelle reactie.

 

[csshunter]

Hoi dreamcatch,
Ik ben geen Dreamweaveriaan, dus kan ik geen concreet antwoord geven (als ik het al zou weten ), maar mij valt uit het bovenstaande op:

• in de ene link wordt gesproken over G|/scripts/bookmarker.js.
• in de andere over: G:\scripts\bookmarker.js.

Mijn vragen:

• wat doet die pijpline | in die ene link, in plaats van een dubbele punt? Heb jij die er in gezet, zit ie in het template, of heeft DW 'm er spontaan bij gezet? En kan je die bij wijze van test veranderen in een : ?
• waar zit het bestand bookmarker.js echt? in de scripts-map in G, of ergens anders (C-schijf ofzo)? En kloppen de hoofd- en kleine letters in de link? (als het Bookmarker.js zou zijn, zou dat troubles kunnen geven, zo niet lokaal, dan op de server).

Nou ja, meer vragen in plaats van antwoorden!

Succes!
CSShunter

 

[dreamcatch]

Hey cssunter,

ik quote maar even jou vragen/opmerkingen.

• in de ene link wordt gesproken over G|/scripts/bookmarker.js.
• in de andere over: G:\scripts\bookmarker.js.

Mijn vragen:

• wat doet die pijpline | in die ene link, in plaats van een dubbele punt? Heb jij die er in gezet, zit ie in het template, of heeft DW 'm er spontaan bij gezet? En kan je die bij wijze van test veranderen in een : ?

• 
  
  Grin...dat is dus de crunch...dreamweaver doet dat alles...de resultaten zijn allen gegenereerd door dreamweaver...onlogisch niet geheel begrijpelijk en toch doet ie dat zelf.
  
  
  

  [*]waar zit het bestand bookmarker.js echt? in de scripts-map in G, of ergens anders (C-schijf ofzo)? En kloppen de hoofd- en kleine letters in de link? (als het Bookmarker.js zou zijn, zou dat troubles kunnen geven, zo niet lokaal, dan op de server).

even een kleine toelichting dan maar

de site staat lokaal in documenten( dus fungeert als root)
in de root zelf zie je volgende

#index.php (file)
#scripts (dir)
#css (dir)
#info (dir)
#img (dir)
#header (dir)
#footer (dir)
#info/land/provincie (allen directory)

(en vele andere dirs)

Het voorbeeld komt uit een file(page) welke in de folder provincie zal komen te staan.

Ik werk eigenlijk voornamelijk met pure code..dat wil zeggen dat ik bijna geen design mode aan heb staan max een enkele keer de split window optie (half code half design).

Mijn pagina opmaak wordt voor 97% door ccs aangestuurd en de 2% is de missing link voor enkele tabellen lol...

dus de template is gemaakt voor de file welke daar in die folder (provincie) komt te staan vandaar ook de drie stappen terug om zo in de scripts/css folders de benodigde files te vinden).....resultaat zie...mijn 1e posting.
Wat hoofdletter/kleine letters of underscores betreft alles klopt, dus ik snap het ook niet..vandaar dat ik hier terecht ben gekomen.

met vr. gr.

deze onderdaan

ps, die "?" optie heb ik nog niet geprobeerd (kan eigenlijk ook niet want dan moet ik de resultpage (de eigenlijke file) met een tekst editor bewerken want dat is een niet editable gedeelte in dreamweaver) en in de originele template staat alles nog steeds correct vandaar ook mijn gebrek aan kennis om dit nog te begrijpen.

 

[peter vazed]

Heb je de opbouw gedaan zoals je normaal ook doet?

Vindt dit vreemd:
#index.php (file)
#scripts (dir)
#css (dir)
#info (dir)
#img (dir)
#header (dir)
#footer (dir)
#info/land/provincie (allen directory)

#header (dir)
#footer (dir)

als dit allemaal mappen zijn krijg je wel rare verwijzingen in je gebruikte documenten.
zoals: header/inc_header.php
die naar ik aanneem in je index.php moet ingesloten worden.

Overigens:
kun je instellen of je absoluut of relatief wil linken.

want dit is natuurlijk onjuist voor een online site:
file:///G|/header/inc_header.php

 

[csshunter]

Hoi dreamcatch,
Aha! Je verhaal zit logisch & steekhoudend in elkaar, als ik zo vrij mag zijn; dus ik snap het ook niet 1-2-3.
Ik vermoed dat DreamW de pijplijn | gebruikt als interne verwijzing naar de root van z'n project; dan zou dat ook geen probleem mogen vormen.
Maar deze:

de site staat lokaal in documenten( dus fungeert als root)

... wat betekent dat precies?

• Is de root van de G-schijf zelf je Documenten-map?
• of:
• Zit er in de G-schijf eerst een map G:/documenten/ die de root van de site vormt?

Als het laatste het geval is, dan zou dat 't verklaren; dan is G:\scripts\bookmarker.js niet de plek, maar G:\documenten\scripts\bookmarker.js.
Maar als je bv. met het inplakken van file:///G:/scripts/bookmarker.js in de adresregel van Firefox het bestand gewoon te zien krijgt, dan snap ik helemaal niet het popup-venster van DW, dat zegt dat het daar niet staat.

Met vriendelijke groet,
CSShunter

PS: voor alle zekerheid: hoe staat het met de "algemene randvoorwaarden"? Harde schijf niet bijna vol, niet vreselijk gedefragmenteerd, nog onlangs gecheckt op registry-fouten e.d.? Als dat allemaal in orde in, lig ik eruit...

 

[dreamcatch]

Hallo Peter,

Heb je de opbouw gedaan zoals je normaal ook doet?

Vindt dit vreemd:
#index.php (file)
#scripts (dir)
#css (dir)
#info (dir)
#img (dir)
#header (dir)
#footer (dir)
#info/land/provincie (allen directory)

#header (dir)
#footer (dir)

als dit allemaal mappen zijn krijg je wel rare verwijzingen in je gebruikte documenten.
zoals: header/inc_header.php
die naar ik aanneem in je index.php moet ingesloten worden.

Op het gevaar af dat het ondanks mijn simpele uitleg toch uitwat te complex kan worden
het zit zo:

1: index.php in de root (simpel en normaal)
2. allemaal folders met bijbehorende namen zoals o.a. de header.
In deze folder staan meerder files..namelijk 12 stuks incl. de inc_header.php
De andere elf zijn zogeheten topics welke verwijzen naar andere in daarbij
behorende files.
Voorbeeldje:

Eén van die 11 links in de header is Editorials, deze link brengt je naar de hoofdpagina Editorials,
je komt dan op een pagina waarin één en ander wordt uitgelegd ,
en op die pagina (editorials dus) staan links naar de bewuste editorials, simpeler kan niet
( de editorials staan allen netjes bij elkaar in een map genaamd editorials).

Zo zijn er dus o.a. 11 links die in de header gelinkt staan in eigen folder volgens een nette structuur..
deze verwijzen op elk dus weer naar bijbehorende pagina's in bijbehorende folders.
Het werkt zoals gezegd perfect. Elke file (bestaande uit een header/banner/content en footer)
hebben dus minimaal drie includes en het werkt buitengewoon overzichtelijk en is/was geheel probleemloos.

Wanneer ik voor al die tig files even de header/banner of footer wil aanpassen doe ik dat
in de bewuste file en met bv 3 min. werk zijn ALLE files in 1 keer aan te passen.
Je zult dit heel erg bekend in de oren komen als je gebruik maakt van css files voor styling

Ik heb dit nu al een geruime tijd en tot op heden loopt het a) snel b) overzichtelijk en c) is het
makkelijk en goed te onderhouden zonder een chaos van verzamelde code in elke pagina.
Ik hoef alleen maar de eigenlijke tekst/foto's of wat dan ook te plaatsten als daadwerkelijk content
en hoef me door deze opzet niet druk te maken over het wel en wee van hoe ziet het eruit en past het wel etc...
want met behulp van de css files ( welke uit bijna 1500 regels code bestaat ugh) is ook de styling geregeld.

Nu back to topic..de templates....het ziet er naar uit dat dit te complex is voor een simpele template
gemaakt met dreamweaver want daar komt dreamweaver om de hoek met links die niet kloppen
en/of naar document verwijzing doen ipv site verwijzingen wat overigens met de eigenhandig gemaakte
masks wel goed functioneert.

Conclussie, of ik heb een stomme verkeerde setting ergens in de preferences staan (weet helaas niet
waar te zoeken meer) of dreamweaver, en daar lijkt het heel erg op, is aan het klooien want hoe te verklaren dat in
(zie voorbeeld van de includes) 3 lijnen dreamweaver er meteen de 1e van "vernageld" en het de andere 2 laat staan zoals ze behoren te zijn.
btw de inc_footer gaat dus ook fout gelijk aan de eerste include.

Sorry voor deze lange "simpele" uitleg maar ben een beetje erg druk en wor gek van dit vervelende
voorval veroorzaakt door dreamwaver.

Btw de site draait nu al een een half jaar op deze wijze, een template maken is erg simpel in dreamwaver
maar gebruiken en er op vertrouwen is dus een 2e zoals je al ziet uit dit voorval.

Overigens:
kun je instellen of je absoluut of relatief wil linken.

je bedoeld in het site management gedeelte? Site defenities/advanced en dan local info?:
radio button document of site root...deze staat dus al jaren op site root.

Hardware is ok, geen defrag of registry probs eneen link online met file:///G|/header/inc_header.php is natuurlijk wel eruggggg fout maar wel door dw veroorzaakt.

Suggesties, oplossingen?...ik sta overal voor open...

O ja, nog een goed weekend/pasen

greetings

 

[peter vazed]

Inderdaad complex, evenwel door je structuur toch beheersbaar en te overzien.

Maar vermits je nu met een template wenst te werken, kun je dan niet die template maken, en dan de delen welke je wenst te benutten handmatig verdelen en in je bestaande opzet opnemen?

Wat is het verschil met de huidige opzet,
en de nieuwe template?

Vermits het geheel probleemloos heeft gewerkt zal toch de fout in de nieuwe template gezocht moeten worden, en kennelijk kan DW er op de een of andere manier niet mee overweg.

Mogelijk dat de door csshunter geopperde root verwijzingen er debet aan zijn.

 

[dreamcatch]

De reden van dit alles en dit kleine "dilemma" is dat er sinds enige tijd met meerdere mensen aan de site wordt gewerkt en dat het af en toe fout gaat met de lay-out.

Eén div meer of minder maakt veel uit en om dat de "gui" gebruikers(editors) uit te leggen is niet fijn daar het ook nog in een andere taal moet en ik er een beetje moe van wordt.
De site groeit gestaag en het moet (in mijn optiek) overzichtelijk blijven en doormiddel van een voorop vastgestelde structuur ia dat te doen.

Wanneer ik een head gedeelte aanpassing wil aanbrengen in de meta is het ondoenlijk langzamerhand. (teveel files, teveel kansen op een fout).
Even een kleine toelichting, wanneer ik over een /de inc_header praat is dat niet direct de head van de php of html maar de header welke je online ziet?!

picture als voorbeeld:

Ik heb (waarschijnlijk) het probleem gevonden/opgelost.....ik heb nu alles naar een NAS verplaatst (lokaal) en werk rechtstreeks hier op
en nu lijkt DW het wel te begrijpen .
Ik ben nog aan het testen maar het ziet er goed uit. Wat was het probleem nu??..geen idee maar als dit de oplossing is..fine i deal with it.

Nu alleen nog een andere vraag tot slot.

Wanneer IK (lokaal) Templates maak en er komt een pagina uit wanneer ik volgende doe:
Nieuw, met template maken en dan de output een, als het ware lege mask is, is dat voldoende om deze te verdelen over mijn editors of moeten zij
ook de template in hun main(root) folder hebben.
Toelichting, zij zitten niet lokaal hier maar op 2 andere plaatsen verdeeld. Ik weet dat DW een folder genaamd _notes in de folders plaatst om zo
bij te houden wat er wordt geupdate/vernieuwd maar wat als de mask..gegenereerd met de template nu geen _notes folder plaatst kan DW het
dan toch aanpassen gezien deze door de site folders "craweld" ?

ps, ben toch blij met de NAS oplossing pheww...

 

[csshunter]

Hoera dat de NAS 't lijkt te doen! Dat is toch eens een prettige Paasei na al die koude zweetdruppeltjes. :thumb:
(hoe/waarom is hokus pokus voor mij)

- Vanochtend was ik nog even bezig wat fout-eliminatie-opties op te pennen + een beginnetje van een evt. mogelijke workaround. Was nog niet af toen ik de voordeur achter me dicht trok. Maar nu ben ik weer terug, - en ga "met de kennis van nu" kijken of ik nog iets als vervolg op je dilemma's kan vinden.

Over je slotvraag:
Het lijkt me dat dit erg samenhangt met de beheer-structuur van de site (o.a. taakverdeling tussen jou en de editors), en met de vraag of/hoe twee of meer "parallele Dreamweavers" naar dezelfde site kunnen uploaden en tegelijkertijd onderling gesynchroniseerd kunnen blijven.

• Als de editors alleen de content hoeven in te vullen in het "template-mask", en het resultaat aan jou terugsturen (zodat jij het kan uploaden), dan kan een editor in principe met Kladblok of een willekeurige html-editor volstaan (zolang maar van de "niet-editable" code wordt afgebleven! ). Als ze er echt niet bij mogen komen, en ze ook DW hebben, dan lijkt me nodig dat het template in de geschikte map van hun DW staat.
• Als de editors zelfstandig mogen uploaden, zal het beleid strenger moeten zijn om geen moemakende fouten (in de niet-editable codes) op de site te krijgen, en zal het template bij hen zeker in de gepaste DW-map moeten zitten, denk ik.

Omdat je spreekt over "hun main(root) folder", neem ik aan dat de editors elk een eigen lokale DW hebben, en niet alles via een vpn-tunnel of andere intranet-voorziening op dezelfde centrale DW uitkomt. Klopt dat?

• Als dat klopt, zouden er idd synchronisatie-problemen kunnen ontstaan...
  

  wat als de mask..gegenereerd met de template nu geen _notes folder plaatst

  ... dan kan "jouw DW" niet zien wat er op een externe DW veranderd is, en kan je waarschijnlijk (na een seintje van de editor) alleen handmatig een bepaalde file uploaden.
  [edit]Tenminste: ik vermoed dat DW alleen lokaal z'n crawl-slagen maakt, en niet op de server gaat kijken wat er wel/niet veranderd is.[/edit]
• Als een externe editor een nieuwe pagina maakt, zal die ook niet automatisch in je sitemap-overzicht e.d. kunnen komen te staan.
• Maar ken je de web content manager "ADOBE CONTRIBUTE CS4"? Daarmee (zeggen ze) kan je gedeeltes van het werk uitbesteden die online doorgevoerd kunnen worden, terwijl je hele (centrale) systeem intact blijft. Daarmee zouden alle template- en synchro-problemen als sneeuw voor de zon moeten verdwijnen. Misschien is dat het onderzoeken / de investering waard?

Wordt vervolgd!
CSShunter

PS: Ik heb geen aandelen Adobe Contribute.

 

[dreamcatch]

Om te beginnen, erg bedankt voor het meedenken

Ben er nog niet uit, maar dat zal wel aan mijn opzet liggen. Ik kwam er namelijk achter dat
wanneer je een include doet zoals ik dat al tijden doe, dit niet safe is met DW en
een template opzetje.
Het helpt namelijk niet echt als DW zich niet aan eigen regels lijkt te houden.
Ik bedoel daar mee het volgende...een voorbeeld van hoe onze pagina's zijn opgemaakt
in code wel te verstaan.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<!-- InstanceBegin template="/Templates/voorbeeld01.dwt" codeOutsideHTMLIsLocked="false" -->
<head>
<meta name=".....heleboel diverse meta's" >
<link href=" enkele css sheets">
<script scr="enkele java scripts"></script>
<title>voorbeeld</title>
</head>
<body>
<?php 
include ("../../../header/inc_header.php");
include ("../../../banner/inc_banner.php");
include ("../../../alphabet/inc_alphabet.php"); ?>
<!-- InstanceBeginEditable name="content voorbeeld01" -->

bla bla de eigenlijke content hier

<!-- InstanceEndEditable -->
<?php  ("../../../footer/inc_footer.php");  ?>
<!-- InstanceEnd -->
</body></html>

Eigenlijk gewoon standaard zou je denken..ok misschien niet geheel met de includes
maar dan nog.
Als ik het goed begrijp (BEGREEP) kun je alleen tussen het "InstanceBeginEditable" en "InstanceEndEditable"
content invoeren...of ????

Zolang men in het code venster werkt gaat het volgens plan, maar in design mode gaat(kan) het radicaal fout (gaan).
Je delete 1 klik de includes alsof er geen "ban" van dreamweaver op staat. :shocked:
Daar sta ik dan met mijn goede voornemens.

Waar doe ik dit nu fout..of waar zie ik iets niet, interpreteer ik iets totall anders dan bedoeld? Of is dit te complex voor DW
cq nog niet ge-implementeerd /aan gedacht?! Of ben ik nu echt helemaal dom bezig?

Help......

ps, Ik kom later nog absoluut terug op jouw input van 4 april 2010 23:28 CSSHunter.

 

[csshunter]

Hoi dromenvanger,
Ha, m'n groene lampje doet het weer: hele avond tot nu toe verstoken van internet wegens storing in een datacentrum van telfort. Een mensch kan toch niet zonder?

Ik begin even met wat ik al had - daarna schakel ik over naar het heden.

Ja (=reactie op jou dd. 4 april 2010 18:24), aan de mapopbouw en sitestructuur zelf zal het zo te horen niet liggen: een prachtig modulair php-systeem. Zo heb ik er zelf ook eentje draaien: heerlijk helder, en als ie eenmaal is opgezet hoef je je nergens meer om te bekommeren. - Het enige principiële verschil: ik doe het recht voor z'n raap met Kladblok, bij jou zit er het DW-template tussen, en de rest van de DW-machine.

Conclusie:
1. of ik heb een stomme verkeerde setting ergens in de preferences staan
(weet helaas niet waar te zoeken meer),
2. of dreamweaver, en daar lijkt het heel erg op, is aan het klooien (...)

Inderdaad, deze conclusie lijkt me onontkoombaar als je Operating System verder geen problemen heeft (enige gaatje dat ik nog zie: eventuele interferentie met een ander programma, bv. een beveiligingsprogramma dat DW van zijn rechten ontdaan heeft om zich te bemoeien met files in G; dan kan DW die files ook niet vinden; maar dan zouden andere operaties van DW vermoedelijk ook mislukken, wat niet het geval is).

Ad 1: Settings
Daar heb ik dus geen kaas van gegeten. Als er hier niet binnenkort een Dreamweaver-goeroe langskomt met een verhelderend idee, zou je het eens kunnen proberen op het Dreamweaver-forum van Adobe zelf: http://forums.adobe.com/community/dreamweaver.

Ad 2: Dreamweaver in de fout
Hier zie ik twee opties:

• 2.1 DW-fout opsporen en herstellen.
• 2.2 Fout laten zitten, en een workaround uitvinden.

Ad 2.1: DW-fout opsporen/herstellen
Om zo veel mogelijk te elimineren, gooi ik nog maar wat balletjes op:

• DW heeft een kritische grens van omvang van de site bereikt, en kan het niet meer behappen.
• Er is niets mis met DW zelf, maar 1 of meer bestanden zijn per ongeluk corrupt geraakt.
  Heb dat vroeger wel eens meegemaakt met FrontPage: aan de code is helemaal niets te zien, maar toch is het bestand kennelijk beschadigd. Opnieuw maken met exact dezelfde code bracht uitkomst.
  • zoiets is misschien met het template a/d hand. Heb je nog ergens een oude versie van het template, en dat geprobeerd?
  • het zou ook een willekeurig ander DW-systeembestand kunnen zijn. Eens geGoogeld op "corrupt file in dreamweaver" > daar kwam o.a. deze uit:

  Dreamweaver creates a cache file called WinFileCache-********.dat or MacFileCache-********.dat inside your personal Dreamweaver configuration folder (the asterisks represent a series of letters and numbers that might differ from computer to computer). This occasionally gets corrupted causing instability, unpredictable error messages, and even crashes.
  http://forums.adobe.com/thread/494811

• Dreamweaver kan niet goed omgaan met ingebakken php's - daar kom ik zo nog op terug bij de workaround.
• Er is iets grondig mis met DW > dat zou betekenen: herinstallatie proberen. Maar ik weet niet of dan misschien het middel erger is dan de kwaal. - Als je erachter kan komen dat alle settings en gemaakte spullen goed bewaard blijven (of als je daar een backup van kunt maken die ook weer gegarandeerd [!] probleemloos terug te zetten is), zou dat wellicht te overwegen zijn.

=====
Tot zover wat ik al had.

Ad 2.2
De workaround komt later, eerst even het hoofdprobleem (wat ik ervan begrijp, dan) omschrijven.

Er zijn twee hoofdproblemen!

1. Er is een beheers-probleem
   = hoe hou je DW zo in de touwen dat deze doet wat je wilt (incl. handhaving niet-editable partjes, en incl. de goede verwijzingen), en
2. Er is een beheer -probleem
   = hoe kunnen editors elders een deel van het beheer van de site overnemen zonder schade te kunnen berokkenen?

Zolang DW (bij jou en/of de editors) niet tot tevredenheid werkt (1), kan ook (2) niet opgelost worden: dan kan het niet direct en ook niet met dat Web Management System van Adobe.

• Nu is volgens mij DW wel een webbouw en site-beheersysteem (voor één webmaster/beheerder op één locatie), maar geen (online) "echt CMS" waar verschillende mensen (op verschillende locaties) toegang toe kunnen krijgen. Vroeger of later zal je dus ook altijd met probleem 2 te maken krijgen, denk ik.

Over naar DW zelf, en je site-systeem.
Je tekeningetje en je opbouw-code zijn me volstrekt duidelijk! Ik signaleer:

• De pagina's zelf zijn (althans in de DW-versie) heel klein.
• Er worden twee invoeg-operaties uitgevoerd (a: lokaal) en (b: op de server), voordat een pagina, compleet in elkaar geschoefd (c), de server verlaat op weg naar de toeschouwer.
• (a.1) Bij het openen van een nieuwe of te bewerken pagina wordt het romp-bestandje door DW opgehaald, en daar het Dreamweaver-template aan vastgeknoopt: nog steeds lokaal.
• (a.2) Bij het saven van de gemaakte pagina wordt deze weer teruggebracht tot z'n romp-deel.
• (a.3) Bij het uploaden door DW wordt opnieuw de combinatie aangemaakt, en deze wordt (per pagina!) integraal naar de server geupload.
• (a.4) Op de site-server staat dus telkens de pagina + z'n ingevoegde DW-template; op de server is geen .dwt-bestand te vinden dat aldaar iets moet doen, want dat zit er al in.
• (b) Op de site-server moet nog wel iets anders gebeuren: de php-modules (die wel op de server staan) moeten ook nog in de pagina geintegreerd worden.
• (c) Het uiteindelijk te downloaden pagina-pakketje heeft dus 2 typen ingevoegde onderdelen.

Conclusie: er zijn twee soorten "includes", en misschien is het dat, wat DW dwars zit - maar waarom DW het dan jaren bij jou goed heeft gedaan, snap ik dan net zo goed als een boon. Misschien zo'n geheimzinnige kritische grens? *) - Of (nog steeds...) eventueel iets in de settings.

Maar ... waarom zou je het DW-template eigenlijk gebruiken?
Is handig/nodig als je met DW werkt, en het is voorwaarde voor de non-editable delen (als die werken). [nu lees ik toch plotseling: de niet-edele delen, terwijl ze toch wel veel adeldom hebben. ]

Maar in principe zou wat het DW-template er in stopt, er ook door een php-bestand in gezet kunnen worden. En eigenlijk heb je er zo te merken toch al bijna een complete echte php-site van gemaakt.

• Nadeel 1:
  waarschijnlijk werkt DW niet zo snel/handig meer.
• Nadeel 2:
  iedereen die bij de pagina kan, kan ook bij de php-aanroepen.
• Voordeel 1:
  wat er op de server aan bestanden staat, kan veel kleiner in omvang zijn. Php timmert de pagina's immers "on command" in elkaar, terwijl het DW-template is opgenomen in elke pagina (daarom moet DW bij een gewijzigd template volgens mij ook de alle sitepagina's die dat gebruiken doorcrawlen en weer opnieuw gaan uploaden; klopt dat?).
• Voordeel 2:
  bij een wijziging in het "php-template" hoeft alleen deze php-module geupload te worden, en alles draait acuut op de nieuwe manier (geen crawl of andere zwembewegingen + aanzienlijke uploads meer nodig).

Op deze manier krijg je een simpele pagina die er vergelijkbaar uit ziet met de opbouw die ik hanteer (zonder DW):

<?php header("Content-type: text/html; charset=utf-8"); ?>
<?php include("../toebehoren/fragment01-headstart.php"); ?><!-- doctype enzo -->
<title>Agenda van ...</title>
<meta name="description" content="...">
<meta name="keywords" content="...">

<?php include("../toebehoren/fragment02-headend.php"); ?><!-- alle meta's, stylesheets enz. -->

<body class="agenda">

<?php include("../toebehoren/fragment03-kopwerk.php"); ?><!-- header met logo, topmenu, breadcrumbs enz. -->

<h1>Agenda</h1>
<h2>Bijeenkomsten en vergaderingen</h2>

<!-- hier begint de content -->
	<h3>10 april a.s.: Manifestatie-comité</h3>
	<p>Doornemen draaiboek en checklist. Plaats: bekend. Tijd: 14:00u.</p>

	<h3>15 april a.s.: Grote Manifestatie</h3>
	<p>Hier gebeurt het! Plaats: ... Tijd: ... Vervoer: ...</p>

	(... enz.)
<!-- hier eindigt de content -->

<?php include("../toebehoren/fragment04-endcontent.php"); ?><!-- footer, div-afsluitingen enz. -->
<?php include("../menus/submenu-rechterkolom.htm"); ?>
<?php include("../toebehoren/fragment05-menu.php"); ?><!-- incl. einde body en einde html -->

Dit was dus mijn workaround!
Als je dit niet heelhuids kunt maken/uploaden met DW, wordt het misschien tijd om zachtjes afscheid van Dreamweaver te nemen.

Resterend probleem: buitengaatse editors die de content vullen, kunnen nu door een vergissing de hele pagina verknallen.
Daar zat ik ook mee: ook in mijn geval moet de content door iemand anders gemaakt en zelfstandig geupload kunnen worden. Die moet dan van mijn mooie php'tjes afblijven, en de beste garantie is: er niet bij kunnen komen.

Tot mij plots een ei van Columbus gewerd:
Het php-gebruik nog één stap verder doorvoeren!
En wel als volgt:

• Het stuk <!-- hier begint de content --> ..... <!-- hier eindigt de content --> knippen we er uit, en wordt óók een include. :love:
• Die wordt dan: <?php include("../content/agenda.htm"); ?>
• De editor kan alleen in die map komen, en daarin naar hartelust de agenda.htm aanpassen zonder de rest te kunnen beschadigen.
• In feite werkt de editor dan niet op de pagina zelf, maar alleen op een "afgeschermd/editable" deel ervan.
• Door de php: niemand die het ziet!
• In het allerergste geval wordt de content-html compleet verhaspeld, maar dan kan de bezoeker nog altijd bij de navigatie om naar de homepage en de rest van de site te komen.
• Voor het aanpassen is alleen een eenvoudige html-editor nodig (of: Kladblok).
• Voor het uploaden is alleen een Filezilla'tje nodig.

... maar ik heb een simpele site zonder automatische cross-links e.a. snufjes; dus geen idee of dit (zonder complete ombouw) ook bij een qua functionaliteit gecompliceerder site kan werken; en hoe gecompliceerd jouw site is, weet ik niet.

Tenslotte als ultieme "workaround": met de hele site en al overstappen op een compleet nieuw CMS...

Dat was 'm! Ik hoop dat er iets bruikbaars tussen zit.

Met vriendelijke groet,
CSShunter

*) Komt meer voor: kwam er achter dat Internet Explorer 6 ook zoiets raars heeft; zie "The IE long page bug". En MS-Word wil ook wel eens heel knoeierig doen bij grote documenten. Allemaal zonder waarschuwing vooraf! :shocked:

 

[dreamcatch]

"Vroeger" was ik wel regelmatig op fora te vinden en probeerde ook middels meedenken en aandragen van mogelijke oplossingen
anderen te helpen zo een antwoord te vinden op kleine dilemma's. En nu bemerk ik bij mezelf dat ik dit, wanneer anderen met
gelijksoortige ideeën en oplossingen aankomen dragen, erg waardeer maar dat terzijde

Een workaround..eawww...ik moet erkennen hier ook aan gedacht te hebben maarrrrr daar ligt het probleem misschien ook wel.
Mijn gebrek aan kennis van php/MySql en CMS is misschien deels wel de main issue van dit "dilemma".
De angst om aan een CMS te beginnen (waar niet geheel aan te ontkomen is) is mischien wel onterecht maar weerhoud mij er
toch nog steeds van om er aan te beginnen.

#Het "cache" probleem is ook hier bekend en deels een issue dat is zeker maar toch.
#De interference van apps welke DW zouden kunnen dwarsbomen..mja..niet ondenkbaar maar dan zou het vaker moeten gebeuren toch?
#Om de content geheel te scheiden van de rest is zeker ook een oplossing (had hier dit weekend ook al aan gedacht)!
#Structureel de opzet aan te passen is ietwat ..vooralsnog .. te vergaand ..tijdgebrek..argh..

De oplossing een CMS op te zetten...als ik eerlijk ben...zou niet ondenkbaar zijn maar ik laat het idee nog even liggen.
Dat de uitwerking hiervan grotendeels positief zou/zal zijn mag/kan ik niet ontkennen.

De site waaraan ik werk (en welke al online is vanaf okt. 2008) is langzamerhand van een hobby site uitgegroeid naar een
toch ietwat professioneler volume.
De voorbeelden en getallen welke ik aangaf zijn uiteraard alleen ter illustratie gebruikt maar deels juist. In mijn optiek
zijn deze niet geheel relevant maar toch, meer dan 800+ (terug gebracht van 1500 tot dit) pagina's en meer dan 10GB aan pics
maken het ietwat..complexer..om zomaar even om te zetten, de laatste 3 maand is de site geheel in een nieuw jasje gestoken
en zeer zeker nog geheel niet af. Enkele links zijn nog te doen en grafisch moet het (in mijn optiek) nog beter en bijgeschaafd
worden. Daarbij komen nu dus ook de template probs..welke eigenlijk alles een iets handen moeten vereenvoudigen.

Backt to topic, de 2 externe editors zijn echte "gui" users dus daar ligt een beetje het probleem (ook)...ga hen vertellen om
in een editor te werken met code en dan ook de grafische opmaak hierin te doen is ietwat teveel voor hen. Dus ik moet hier
op een of andere manier een oplossing voor vinden.

Ik denk dat het nog verder opsplitsen van de gehele content, en deze, gelijk aan de andere includes, tot één te rijgen in een "mainfile" al
zal bijdragen tot a) voorkomen van errors (indien ze dan ontstaan is het of de server of mijn eigen enkelzijdig werkende hersencel)
b)nog overzichtelijker maakt.
Bij repetitive errors is het dan makkelijker om te herleiden waar een mogelijk ontstaan probleem zou kunnen liggen.

Ik pak even een halve liter koffie en ga bomen met mijn eigen ik over het opsplitsen van content.

Alvast weer heel erg bedankt .

 

[dreamcatch]

NAS is voor mij de enige voorlopige oplossing maar het werkt in ieder geval,
bedankt voor de reacties Peter en csshunter.