pichia

Men det är det inte. Egentligen är det rätt så enkelt och flexibelt samt löser de flesta frågeställningar du har haft ovan (hantering av nyckelord och script på sidbasis) på ett mycket enklare sätt.

Jag inser inte riktigt vad skillnaden är. Kanske vissa webbläsare väntar med att visa sidan tills allt innehåll är nerladdat, medan andra visar innehållet allteftersom det hämtas. Eventuellt kan du testa att att gzip-a din sida och därmed få den att laddas ner som en enda klum som sedan packas upp av webbläsaren lokalt. Eventuellt kan detta jämna ut olikheten. Du behöver bara 2 extra rader php i din mall:

<?php
	ob_start('ob_gzhandler');
	//mallinnehåll
	ob_end_flush();
	?>

Hej Klarabara,

Jag tänkte återkoppla till startfrågan om hur man lämpligen kan organisera sin kod.

Med includes och utan databaser (för CMS-ändamål) så brukar jag göra som följande:
Jag delar upp varje sida i 2 filer:

- en parameterfil som heter som det är tänkt i url-en (tex index.php)
- en innehållsfil som innehåller det sidspecifika innehållet

Parameterfilen inkluderar en mall som i sin tur inkluderar innehållsfilen som har ett namn kopplat till parameterfilen (här index_content.php). se bifogad bild.

Fördelarna är att man slipper url-er med parametrar (typ index.php?page=minsida - jovisst, just det går att trolla bort med MOD_REWRITE-meckande i htaccess, men det är inte så busenkelt) och man kan sätta precis så många parametrar man vill per sida som mallen skall ta hänsyn till, som just tex titel, metataggar, vilka css/javascript-filer som skall laddas, mm. Innehållet på sidan kan vara ren html eller php-baserad dynamisk innehåll. Man kan ha flera mallar. Det är i parameterfilen som man bestämmer vilken mall som skall hämtas.

(I exemplet har jag struntat helt i css och javascript, men där gör man "som vanligt" i mallen, eller just styr det på sidbasis med en parameter i parameterfilen)

Vill ha...
Varför är den gamla 24" iMac från 2007 inte trött än?

Lilla Camino blir alltjämt mera sällsynt...

Har ni flera sidor på siten är det lättare för användarna att hitta tillbaka till en viss sida via historiken om sidorna har olika och relevanta titlar.

Menyn bryter i två rader i Firefox 3.6, vilket är synd och antagligen inte meningen.

Du har fått med alt-attributer till galleri-länkarna (<a>). Det attributet är reserverat till bilder (<img>) för att kort beskriva bilden för den som inte ser. Det är nog det enda valideringsfelet jag såg, men som finns på alla sidor med galleri.

Jag har ganska lätt att acceptera avsaknaden av priser eftersom jag inser att fotojobb kan vara så olika, även om det gäller bröllopsfotografering. En bild på dig själv skulle redan i sig skapa en form av kontakt och skulle hjälpa till att minska tröskeln för en potentiell kund att ringa upp.

För min del fungerar siten alldelles utmärkt och övertygar. Vilka fantastiska bilder (stor skärm är bra för full effekt). Definitivt utöver vad han på ekonomiavdelningen skulle kunna åstadkomma (även det är en eufemism). Jag ser inte riktigt behovet av tummisar i det här sammanhanget, eftersom man inte är här för att leta efter specifika bilder (skulle du publicera bilder för påseende för en kund, är det då helt givet med tummisöversikt), men bara låta sig överaskas och få en känsla för vad du går för. Jag tycker siten gör det rakt och enkelt utan krussiduller som stjäl uppmärksamheten från bilderna.

Skall definitivt spara i bokmärkerna inför nästa fotosession för våra produkter på jobbet...

Enklast är om du ar en fel-logg någonstans. Jag antar att inställningarna (från One?) är sådana att fel inte printas ut på skärmen. Oftast hamnar de i istället i en loggfil. Var den finns på ett One-konto har jag dock ingen aning om. Men i den skall man kunna se om det är ett MySQL-fel eller ett php-fel.

Använder indexhibit en databas (typ MySQL)? Hur funkar din användare mot den, har den fulla rättigheter mot den?

Jösses, vilken obegriplig fråga. Du får nog hiva upp lite kod eller länka till en testsida så att man förstår vad du vill göra.

För att "position absolute" skall fungera måste den omslutande noden ha "position relative" satt.

Jag tackar för all input.

Jo, det är ju den rakaste vägen för att veta säkert.
Det är bara till att säkra sin nuvarande version innan den mosas av en uppdatering. Sen skall man vara säker att det går att rulla tillbaka till den äldre version. Ibland är det inte bara själva programmet som ändras i en uppdatering utan även stödfiler i biblioteket. Fast det känns intuitivt att Skype borde vara tämligen klient-agnostisk (det skall gå att logga in och hitta alla sina kontakter oberoende av version och plattform) och då borde det vara rätt tacksam att switcha mellan versioner. Men, men...

Hittills har ingen kommit hit för att lyrisk sjunga sin kärleksång till Skype 5, så jag tror jag trallar vidare med 2.8 så länge den fungerar och fyller sin funktion.

Hej!

Idag tyckte min Skype 2.8 (har det någonsin funnits en version 3 eller 4?) att jag borde uppdatera till 5.0.någonting.
Av kommentarerna kring betaversionen i höstas, lät det som att den uppdateringen inte nödvändigtvis kunde anses vara ett uppköp. Hur är det nu? Finns det anledning att uppdatera? Mitt behov av multipartvideosamtal är tämligen begränsat (närmare försumbar). Finns det någon annan killer-funktionalitet som gör att man vill överge det enkla och effektiva gränssnittet i 2.8-versionen?

Med tanke på att det är inte mycket mer än en plastbit och ett par standardkablar, så är nog förtjänsten i alla fall väl tilltagen.

Det låter som en väldig dålig lösning ur säkerhetaspekten att inte ha ett lösenord till ett adminkonto på datorn.
Det finns en inställning för autoinloggning om man absolut inte vill mata in ett lösenord varje gång man startar datorn. Smidigt, men nackdelen med detta är att man exponerar sina filer för vem som helst som råkar, tillbörligt eller otillbörligt, hamna framför datorn.
Annars är det just samma lösenord som krävs i terminalen som vid inloggning till adminkontot

Jag skulle kunna tänka mig något i stil (ej testat dock):

$("#updateContactDetails input[type="submit"], #updatenameDetails input[type="submit"]").hide();
$("#updateContactDetails input, #updatenameDetails input").change(function(){
	$(this).siblings("input[type="submit"]").unhide();
});

När något av fälten i respektive id ändras, så poppar den aktuella "Spara" knappen upp.