Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Skalering af billeder til responsive

27 views
Skip to first unread message

Kurt Hansen

unread,
Nov 29, 2019, 8:31:47 AM11/29/19
to
Jeg har bl.a. læst
https://www.w3schools.com/css/css_rwd_images.asp

Øvelsen går ud på at placere et banner øverst på siden (oven over
menuen) og jeg går ud fra at det er hensigtsmæssigt, at billedet
skalerer responsivt?

Jeg har lavet en hurtig test med et banner på 960*105 pixels og det
virker: http://www.danacord.com/ny/imgtest.html, men de 960 px var
tilfældigt valgt fordi det banner jeg havde ved hånden havde den størrelse.

Skal jeg lave det i 675px som klassen .topnav angiver?
Se: http://www.danacord.com/ny/imgtest2.html

Da jeg startede med HTML for +20 år siden var det god skik at sætte
width og height på billeder OG at lave dem i den størrelse de skulle
vises i, da browsernes skalering ikke gav pæne billeder. Gælder det
stadigvæk?

Uanset hvad, så vil jeg naturligvis gerne have det implementeret i
index.html.

w3schools laver en style der hedder:

img {
max-width: 100%;
height: auto;
}

men så kommer det jo/vel til at gælde alle img'er? Hvis jeg i stedet
skriver:

billede {
max-width: 100%;
height: auto;
}

- og sætter <div class="billede" ...">, så skalerer billedet/banneret
ikke, mens resten gør. Det fatter jeg altså ikke.

Og hvorfor er der en hvid "margin" på 4 pixels under banneret?
--
Venlig hilsen
Kurt Hansen

Kurt Hansen

unread,
Nov 29, 2019, 8:34:43 AM11/29/19
to
Den 29/11/2019 kl. 14.31 skrev Kurt Hansen:

> Uanset hvad, så vil jeg naturligvis gerne have det implementeret i
> index.html.
>
> w3schools laver en style der hedder:
>
>         img {
>             max-width: 100%;
>             height: auto;
>         }
>
> men så kommer det jo/vel til at gælde alle img'er? Hvis jeg i stedet
> skriver:
>
>         billede {
>             max-width: 100%;
>             height: auto;
>         }
>
> - og sætter <div class="billede" ...">, så skalerer billedet/banneret
> ikke, mens resten gør. Det fatter jeg altså ikke.
>
> Og hvorfor er der en hvid "margin" på 4 pixels under banneret?

http://www.danacord.com/ny/index.html

Dennis Munding

unread,
Nov 29, 2019, 10:37:54 AM11/29/19
to
Kurt Hansen wrote:

> Jeg har bl.a. læst
> https://www.w3schools.com/css/css_rwd_images.asp
>
> Øvelsen går ud på at placere et banner øverst på siden (oven over
> menuen) og jeg går ud fra at det er hensigtsmæssigt, at billedet
> skalerer responsivt?
>
> Jeg har lavet en hurtig test med et banner på 960*105 pixels og det
> virker: http://www.danacord.com/ny/imgtest.html, men de 960 px var
> tilfældigt valgt fordi det banner jeg havde ved hånden havde den
> størrelse.
>
> Skal jeg lave det i 675px som klassen .topnav angiver?
> Se: http://www.danacord.com/ny/imgtest2.html


Hvis ikke der bliver større forskel på original kontra nedskaleret
billede, så er der, efter min mening, ingen grund til flere versioner
af billedet.
Mobile enheder kan snildt klare nedskaleringen og typisk er det kun,
hvis de skal gøres større, at billeder bliver forringet.

Man kan dog argumentere for unødig båndbredde, da brugeren jo henter
originalbilledet, men kun får præsenteret en nedskaleret version.


>
> Da jeg startede med HTML for +20 år siden var det god skik at sætte
> width og height på billeder OG at lave dem i den størrelse de skulle
> vises i, da browsernes skalering ikke gav pæne billeder. Gælder det
> stadigvæk?

Hvis billedet skal have fast størrelse, så er det en god idé, men
m.h.t. responsivt design, så gælder det om at holde tungen lige i
munden, da billedet så typisk vil få procentvise mål i forhold til
originalen...

Grunden til højde- og breddeangivelserne er, at man på den måde
fortæller browserne, at de skal afsætte plads til billedet med de
angivne mål, når de indlæser siden.
Derved undgår man, at indholdet "hopper" under indlæsningen.

> Uanset hvad, så vil jeg naturligvis gerne have det implementeret i
> index.html.
>
> w3schools laver en style der hedder:
>
> img {
> max-width: 100%;
> height: auto;
> }
>
> men så kommer det jo/vel til at gælde alle img'er? Hvis jeg i stedet
> skriver:
>
> billede {
> max-width: 100%;
> height: auto;
> }
>
> - og sætter <div class="billede" ...">, så skalerer billedet/banneret
> ikke, mens resten gør. Det fatter jeg altså ikke.


Måske fordi du ikke har sat et punktum foran "billede" i din css -
eller er det blot en fejl, du lavede, da du skrev indlægget?


> Og hvorfor er der en hvid "margin" på 4 pixels under banneret?


Fordi du har sat margin:auto; (auto på alle fire sider) på div.billede
:-)
Hvis du ændrer det til margin:0 auto; (top/bund venstre/højre), så
burde der ikke være noget margin. :-)


--
Med venlig hilsen

Dennis Munding

Jan Hansen

unread,
Nov 29, 2019, 1:47:20 PM11/29/19
to
Hvis det er meningen at billedet skal centreres og vises 675px
bredt hvis der er plads, og ellers skaleres til sidebredde, og
der ikke skal være en hvid streg nedenunder, så udskift

<div class="billede" style="margin:0 auto; max-width:675px">
<img src="/ny/images/banner675.jpg" width="675" height="74">
</div>

med

<img src="/ny/images/banner675.jpg" style="width:675px; max-width:100%; display:table; margin:auto;">

Hvis du har hørt, at avancerede brugere også sætter en højde på
billeder, er det bare et spørgsmål om umiddelbart efter billedet
at lave et javascript, det indsætter billedets aktuelle højde,
hvis der er plads i bredden, og ellers beregner højden der passer
til sidebredden.

Så ved du det, hvis du mener, det er vigtigere end at rette det
mainkatalog, så der kommer noget frem, man kan linke til.
Der er sikkert en hel del, der har skrevet noget i stil med
"Er det den her du ønsker dig til jul bedstemor" efterfulgt af
et link, som skribenten tror er til en CD, men som i virkeligheden
er til kataloget. Bedstemor svarer "nej det er den her" og så
et link mere til kataloget. Efterfølgende forsvinder julehandelen
over på sider, der er til at have med at gøre. Men hvis Danacord
ikke samler på kunder, der er for hjernedøde til at finde ud af
at højreklikke i højre ramme og vælge "denne ramme" -> "vis kun
denne ramme", og så sende det link, der kommer frem på adresselinien,
så er det da sikkert helt som det skal være.



--
mvh Jan.
Help Microsoft stamp out piracy. Give
Linux to a friend today!

Kurt Hansen

unread,
Nov 30, 2019, 12:41:06 AM11/30/19
to
Den 29/11/2019 kl. 19.47 skrev Jan Hansen:
> Hvis det er meningen at billedet skal centreres og vises 675px
> bredt hvis der er plads, og ellers skaleres til sidebredde, og
> der ikke skal være en hvid streg nedenunder, så udskift
>
> <div class="billede" style="margin:0 auto; max-width:675px">
> <img src="/ny/images/banner675.jpg" width="675" height="74">
> </div>
>
> med
>
> <img src="/ny/images/banner675.jpg" style="width:675px; max-width:100%; display:table; margin:auto;">

Fantastisk, men jeg er mildt sagt rystet. Jeg har i flere år være klar
over at jeg er sakket håbløst bagud og det illustrerer din korrektion
med al uønsket tydelighed. Jeg kan jo godt læse, bogstav for bogstav,
hvad du skriver, men jeg forstår det ikke rent teknisk :-(

> Så ved du det, hvis du mener, det er vigtigere end at rette det
> mainkatalog, så der kommer noget frem, man kan linke til.

Øhhh, jamen det er jo ikke den gamle frame-side jeg arbejder på: det er
en ny, responsive side widthout dikkedares, så hver side får sin egen
unikke adresse, som der kan linkes til.

Se min legeplads her:
http://www.danacord.com/ny/index.html

Kim Ludvigsen

unread,
Nov 30, 2019, 1:26:16 AM11/30/19
to
Den 30.11.2019 kl. 12.41 skrev Kurt Hansen:

> Se min legeplads her:
> http://www.danacord.com/ny/index.html

Overvej at gøre menulinjen lidt mindre i højden, den er forholdsvis høj
på en lille skærm. Det er den linje, hvor du tidligere ændrede afstanden
mellem menupunkterne:
padding: 14px 16px;
Det første tal angiver afstand i højden, prøv fx med 0px
Lidt længere nede finder du linjen:
font-size: 17px;
Prøv at ændre til:
font-size: 1em;

em skalerer bedre end px. Vil du have større eller mindre skrift bruges
punktum som decimaltegn, fx 1.1em eller 0.9em. Reelt set vil det være en
god ide at bruge em næste alle steder, hvor du ellers bruger px - fx
også til padding. Bruger du udviklerværktøjerne i Firefox kan du nemt
prøve dig frem med forskellige værdier, til du finder en passende.

Noget endnu vigtigere: Det ser ud som om, du vil bruge pladenummeret som
filnavn. Brug i stedet kunstner og titel, det vil give meget bedre
ranking hos Google. Altså i stedet for (indsat mellemrum, så du ikke får
indekseret ikke-eksisterende sider):
http://www.danacord .com/ny/frmsets/records/854-r.html
så brug:
http://www.danacord .com/ny/elisabeth-klein-new-nordic-piano-music.html

Hvis brugere kan risikere at søge på pladenummeret på Google, så medtag
det på en ekstra linje i den beskrivende tekst:
... beskrivelse ...
Catalogue number: DACOCD 854

--
Mvh. Kim Ludvigsen

Kurt Hansen

unread,
Nov 30, 2019, 2:34:32 AM11/30/19
to
Den 30/11/2019 kl. 07.26 skrev Kim Ludvigsen:
> Den 30.11.2019 kl. 12.41 skrev Kurt Hansen:
>
>> Se min legeplads her:
>> http://www.danacord.com/ny/index.html
>
> Overvej at gøre menulinjen lidt mindre i højden, den er forholdsvis høj
> på en lille skærm. Det er den linje, hvor du tidligere ændrede afstanden
> mellem menupunkterne:
> padding: 14px 16px;
> Det første tal angiver afstand i højden, prøv fx med 0px

Det har jeg faktisk gjort, men fandt 5px passende.

> Lidt længere nede finder du linjen:
> font-size: 17px;
> Prøv at ændre til:
> font-size: 1em;

Jeg har p.t. remmet den linje ud og skriftstørrelsen bliver vel så
"standard"?

> Noget endnu vigtigere: Det ser ud som om, du vil bruge pladenummeret som
> filnavn. Brug i stedet kunstner og titel, det vil give meget bedre
> ranking hos Google. Altså i stedet for (indsat mellemrum, så du ikke får
> indekseret ikke-eksisterende sider):
> http://www.danacord .com/ny/frmsets/records/854-r.html
> så brug:
> http://www.danacord .com/ny/elisabeth-klein-new-nordic-piano-music.html
>
> Hvis brugere kan risikere at søge på pladenummeret på Google, så medtag
> det på en ekstra linje i den beskrivende tekst:
> ... beskrivelse ...
> Catalogue number: DACOCD 854

Hvis ikke du havde nævnt dette, ville jeg bare have taget hovedet under
armen og brugt varenummeret som filnavn. Det du skriver er da til at
forstå og det vil jeg naturligvis gøre. Mange tak for tippet :-)

Jan Hansen

unread,
Nov 30, 2019, 6:47:48 AM11/30/19
to
Kurt Hansen skrev:

> > Så ved du det, hvis du mener, det er vigtigere end at rette det
> > mainkatalog, så der kommer noget frem, man kan linke til.
>
> Øhhh, jamen det er jo ikke den gamle frame-side jeg arbejder på: det er
> en ny, responsive side widthout dikkedares, så hver side får sin egen
> unikke adresse, som der kan linkes til.

Ja det er da muligt nok, men butikken er vel ikke lukket imens du kreerer
ny side. Det kan da ikke være et problem at lave de to gange søg og erstat
i maincat.html og maincat-n.html

Søg efter:
href="records/
Erstat med:
href="/frmsets/records/

Søg efter:
.html" target="_self"
Erstat med:
-r.html" target="_top"

Hvis du kan afse 10 minutter til den operation, har du opnået at øge
omsætningen med 87% i den periode, der går imens du laver ny side.
Det er da muligt, der mangler sådan en frmset fil til enkelte af CDerne,
men jeg er ret sikker på, at et af dine professionelle hjemmesideprogrammer
har en professionel linkchecker indbygget.

Jan Hansen

unread,
Nov 30, 2019, 8:54:13 AM11/30/19
to
Kim Ludvigsen skrev:

> Overvej at gøre menulinjen lidt mindre i højden, den er forholdsvis høj
> på en lille skærm. Det er den linje, hvor du tidligere ændrede afstanden
> mellem menupunkterne:
> padding: 14px 16px;
> Det første tal angiver afstand i højden, prøv fx med 0px
> Lidt længere nede finder du linjen:
> font-size: 17px;
> Prøv at ændre til:
> font-size: 1em;

Det er jo til at pakke ind i
@media only screen and (max-height: [lille skærm]) { ... }

> Noget endnu vigtigere: Det ser ud som om, du vil bruge pladenummeret som
> filnavn. Brug i stedet kunstner og titel, det vil give meget bedre
> ranking hos Google. Altså i stedet for (indsat mellemrum, så du ikke får
> indekseret ikke-eksisterende sider):
> http://www.danacord .com/ny/frmsets/records/854-r.html
> så brug:
> http://www.danacord .com/ny/elisabeth-klein-new-nordic-piano-music.html

eller

http://www.danacord .com/ny/DACOCD-854-elisabeth-klein-new-nordic-piano-music.html

så kan ErrorDocument 404 ud fra nummeret finde den gamle fil og vise frem,
der er jo ikke de store udsigter til det hele bliver lavet om indenfor en
overskuelig årrække.

Kurt Hansen

unread,
Nov 30, 2019, 9:07:14 AM11/30/19
to
Puuuuha, Jan. Dét var pinligt. Først forstod jeg ikke helt dit ærinde,
men ved nærmere gennemsyn kunne jeg godt se din pointe.

Oh well. Så må jeg bare konstatere, at sådan har det været i hele sidens
levealder, som er +20 år ;-)

Tak for indsparket. Jeg kigger på det i aften.

Kurt Hansen

unread,
Nov 30, 2019, 9:09:45 AM11/30/19
to
Skal der absolut være alle de bindestreger? Smukt er det jo ikke, når
brugeren gemmer et link som bogmærke og jo heller ikke på fanebladet i
browseren.

Jan Hansen

unread,
Nov 30, 2019, 9:39:45 AM11/30/19
to
Kurt Hansen skrev:

> Skal der absolut være alle de bindestreger?

Sådan skal det åbenbart stå, hvis man vil i top hos google. Men jeg har
ikke noget, jeg skal have solgt på nettet, så det er ikke noget, jeg
har nogen forstand på.

> Smukt er det jo ikke, når brugeren gemmer et link som bogmærke og jo
> heller ikke på fanebladet i browseren.

Bogmærkerne bliver vel normalt opkalt efter sidens titel, og ikke efter
filnavnet, med mindre der mangler et <title> tag i den fil, de laver
bogmærke til.

Kim Ludvigsen

unread,
Nov 30, 2019, 10:18:28 AM11/30/19
to
Den 30.11.2019 kl. 20.53 skrev Jan Hansen:
> Kim Ludvigsen skrev:

>> http://www.danacord .com/ny/elisabeth-klein-new-nordic-piano-music.html
> eller
> http://www.danacord .com/ny/DACOCD-854-elisabeth-klein-new-nordic-piano-music.html

Jeg har på fornemmelsen, at jo længere url'en er, jo mindre vægt får
hvert enkelt ord.

Kurt:
Er det et internt varenummer, I bruger, eller bruger I pladeselskabets
pladenumre? Hvis det er et internt varenummer, er der ingen grund til at
vise det til kunderne, hverken i url eller i beskrivelse.

Bruger man i det hele taget pladenumre til noget i vore dage - ud over
måske, når man bestiller fra en producent? Når jeg tjekker albums hos
Wikipedia og andre steder, nævnes pladenummeret kun yderst sjældent.

Bindestregerne i url'en er fordi Google for en del år siden fortalte, at
de vægter ordene højere, når man bruger bindestreger, end hvis man
bruger understreg, som ellers er kønnere. Jeg ved ikke, om Google har
ændret på det sidenhen.

> så kan ErrorDocument 404 ud fra nummeret finde den gamle fil og vise frem,
> der er jo ikke de store udsigter til det hele bliver lavet om indenfor en
> overskuelig årrække.

Der skal helt klart være en form for viderestilling fra de gamle url'er
til de nye - godt at du tænkte på at få det nævnt! Og de gamle url'er
skal rapportere til Google, at url'en er ændret permanent med en 301-kode.

--
Mvh. Kim Ludvigsen

Kurt Hansen

unread,
Dec 1, 2019, 1:46:56 AM12/1/19
to
Den 30/11/2019 kl. 16.18 skrev Kim Ludvigsen:
> Den 30.11.2019 kl. 20.53 skrev Jan Hansen:
>> Kim Ludvigsen skrev:
>
>>> http://www.danacord .com/ny/elisabeth-klein-new-nordic-piano-music.html
>> eller
>> http://www.danacord
>> .com/ny/DACOCD-854-elisabeth-klein-new-nordic-piano-music.html
>
> Jeg har på fornemmelsen, at jo længere url'en er, jo mindre vægt får
> hvert enkelt ord.

Fornemmelsen?

> Er det et internt varenummer, I bruger, eller bruger I pladeselskabets
> pladenumre? Hvis det er et internt varenummer, er der ingen grund til at
> vise det til kunderne, hverken i url eller i beskrivelse.

Det er pladeselskabets varenummer; det som er trykt på udgivelsen.

Jamen det er helt sikkert en erhvervsskade at tænke så meget på
varenummeret. Du har sikkert ret i at kunderne ikke tænker mange
sekunder over det.

> Bindestregerne i url'en er fordi Google for en del år siden fortalte, at
> de vægter ordene højere, når man bruger bindestreger, end hvis man
> bruger understreg, som ellers er kønnere. Jeg ved ikke, om Google har
> ændret på det sidenhen.

Det må man kunne læse om og det gør jeg da også gerne, men har ikke
fantasi til at finde nogle relevante nøgleord.

>> så kan ErrorDocument 404 ud fra nummeret finde den gamle fil og vise
>> frem,
>> der er jo ikke de store udsigter til det hele bliver lavet om indenfor en
>> overskuelig årrække.
>
> Der skal helt klart være en form for viderestilling fra de gamle url'er
> til de nye - godt at du tænkte på at få det nævnt! Og de gamle url'er
> skal rapportere til Google, at url'en er ændret permanent med en 301-kode.

Suk :-(. Jeg har hele tiden været klar over at jeg er sakket bagud, men
får gang på gang et chok. Hver time overvejer jeg at give op, selv om
det - i princippet - er et simpelt projekt jeg har gang i.

Kim Ludvigsen

unread,
Dec 1, 2019, 2:05:23 AM12/1/19
to
Den 01.12.2019 kl. 13.46 skrev Kurt Hansen:
> Den 30/11/2019 kl. 16.18 skrev Kim Ludvigsen:

>> Jeg har på fornemmelsen, at jo længere url'en er, jo mindre vægt får
>> hvert enkelt ord.
>
> Fornemmelsen?

Ja, det er ikke noget, jeg ved. Det fungerer sådan for de
hjælpeartikler, vi laver på Mozillas supportsider, og det lyder
fornuftigt at lave den vægtning for at undgå misbrug med meget lange
url'er med mange søgeord, så mon ikke Google har indført noget lignende.

> Jamen det er helt sikkert en erhvervsskade at tænke så meget på
> varenummeret. Du har sikkert ret i at kunderne ikke tænker mange
> sekunder over det.

Jeg er selv gammel pladeshop-mand, så jeg har lidt af den samme skade
(indtil i går). Jeg var derfor lidt overrasket over at slå en håndfuld
plader op på Wikipedia, og den eneste jeg fandt pladenumre for var Abbey
Road. Jeg vil anbefale, at du ikke bruger pladenummeret på siderne. Men
det kunne måske være en god ide at medtage andre ting, som kunderne
kunne finde på at søge efter, i beskrivelsen af pladerne, fx genre.

>> Bindestregerne i url'en er fordi Google for en del år siden fortalte,
>> at de vægter ordene højere, når man bruger bindestreger, end hvis man
>> bruger understreg, som ellers er kønnere. Jeg ved ikke, om Google har
>> ændret på det sidenhen.
>
> Det må man kunne læse om og det gør jeg da også gerne, men har ikke
> fantasi til at finde nogle relevante nøgleord.

Hvis du laver url'en, som jeg anbefalede, så har du de mest relevante
nøgleord i url'erne.

>> Der skal helt klart være en form for viderestilling fra de gamle
>> url'er til de nye
>
> Suk :-(. Jeg har hele tiden været klar over at jeg er sakket bagud, men
> får gang på gang et chok. Hver time overvejer jeg at give op, selv om
> det - i princippet - er et simpelt projekt jeg har gang i.

Man kan lave den viderestilling på mange måder. Hvis det kun var nogle
få url's, kunne man lave den i filen .htaccess, men når det er mange
sider, er det nok bedre at lave den i en scriptfil, som kaldes, når en
side ikke findes. Det er faktisk en smart løsning, Jan foreslog, jeg har
aldrig tænkt på, at en 404-fil kunne bruges på den måde.

--
Mvh. Kim Ludvigsen

Jan Hansen

unread,
Dec 1, 2019, 6:58:54 AM12/1/19
to
Kim Ludvigsen skrev:

> Man kan lave den viderestilling på mange måder. Hvis det kun var nogle
> få url's, kunne man lave den i filen .htaccess, men når det er mange
> sider, er det nok bedre at lave den i en scriptfil, som kaldes, når en
> side ikke findes. Det er faktisk en smart løsning, Jan foreslog, jeg har
> aldrig tænkt på, at en 404-fil kunne bruges på den måde.

Det jeg mente var, at man kunne sætte det til at vise de gamle sider,
hvis ikke der er en ny udgave endnu. Samtidig kan man så skrive en hel
masse sludder til google, og alligevel beholde nogle logiske filnavne.
Jeg har "moderniseret" nogle af siderne, for eksempel
http://www.sniper-pistol.com/DACOCD-381-Bønnerup-spiller-i-Sorø-Klosterkirke
Hvis en cd ikke findes i mappen med nye, vises den gamle side i stedet for:
http://www.sniper-pistol.com/DACOCD-303-Horowitz-i-Københavnstrup
Det er kun numrene efter DACOCD- der bliver brugt til at finde filnavnet,
men jeg kan ikke finde ud af at fjerne DACOCD- uden der går kludder i det,
hvis en cd hedder noget med "opus 719". Men det er da til at flytte hen
i slutningen af linien, hvis det giver mere bonus hos google,
http://www.sniper-pistol.com/Alexander-Brailowsky-underholder-i-Berlin-DACOCD-336-39

Det er lavet med en linie i .htaccess med
ErrorDocument 404 /fejl.php

og så en fejl.php, der kan ses her http://www.sniper-pistol.com/fejl.php?viskode

Kim Ludvigsen

unread,
Dec 1, 2019, 8:05:26 AM12/1/19
to
Den 01.12.2019 kl. 18.58 skrev Jan Hansen:
> Kim Ludvigsen skrev:
>
>> Man kan lave den viderestilling på mange måder. Hvis det kun var nogle
>> få url's, kunne man lave den i filen .htaccess, men når det er mange
>> sider, er det nok bedre at lave den i en scriptfil, som kaldes, når en
>> side ikke findes. Det er faktisk en smart løsning, Jan foreslog, jeg har
>> aldrig tænkt på, at en 404-fil kunne bruges på den måde.

> Det jeg mente var, at man kunne sætte det til at vise de gamle sider,
> hvis ikke der er en ny udgave endnu.

Men hvis der ikke er lavet en ny side endnu, er der vel ikke et link til
den? Problemet er vel mere den anden vj, hvis nogen forsøger at hente
den gamle side, de skal så i stedet viderestilles til den nye side med
en 301-kode til Google.

Bortset fra det, så får alt dette mig blot til at tænke på (igen igen),
at det ville være meget nemmere for Kurt at lave en database og så smide
det hele ind i den. Og så bruge php-filer i stedet for flade html-filer.

Som vi tidligere har været inde på, så må det være muligt at kopiere det
meste af indholdet fra shop-databasen.

--
Mvh. Kim Ludvigsen

Jan Hansen

unread,
Dec 1, 2019, 8:59:10 AM12/1/19
to
Kim Ludvigsen skrev:

> Men hvis der ikke er lavet en ny side endnu, er der vel ikke et link til
> den? Problemet er vel mere den anden vj, hvis nogen forsøger at hente
> den gamle side, de skal så i stedet viderestilles til den nye side med
> en 301-kode til Google.

Det er rigtig nok, hvis den gamle side er slettet havner man alligvel dér,
og så er det til at viderestille til den nye side.
Men ved at anvende den fil er det til med det samme at lave nogle links,
der giver succes hos google, uden de behøver have andet end et nummer til
fælles med de virkelige filnavne. Scriptet kan så efterfølgende undersøge,
om der findes en ny udgave, er den ikke lavet endnu, vises den gamle side
i stedet for. Den bliver så automatisk udskiftet med en ny, når først der
er kommet en fil med samme nummer i den nye mappe.

> Bortset fra det, så får alt dette mig blot til at tænke på (igen igen),
> at det ville være meget nemmere for Kurt at lave en database og så smide
> det hele ind i den. Og så bruge php-filer i stedet for flade html-filer.
>
> Som vi tidligere har været inde på, så må det være muligt at kopiere det
> meste af indholdet fra shop-databasen.

Hvis ikke nummeret fra det virkelige filnavn skal indgå i linkene, kunne
det da nok være en fordel med en tabel, hvor man ud fra det på adresselinien
kan slå op, hvad filen hedder i virkeligheden. De fleste springer vel over
hvor gærdet er lavest og udelader æøå og lignende i filnavne.
Ved du, om det er derfor, det er moderne med de bindestreger i stedet for
mellemrum i adresserne? Der er jo ikke noget til hinder for at lave et link:
www.sniper-pistol.com/DACOCD-382 Bønnerup spiller i Jægersborg

Kim Ludvigsen

unread,
Dec 1, 2019, 9:18:18 AM12/1/19
to
Den 01.12.2019 kl. 20.59 skrev Jan Hansen:

> Hvis ikke nummeret fra det virkelige filnavn skal indgå i linkene, kunne
> det da nok være en fordel med en tabel, hvor man ud fra det på adresselinien
> kan slå op, hvad filen hedder i virkeligheden. De fleste springer vel over
> hvor gærdet er lavest og udelader æøå og lignende i filnavne.

Jeg benytter altid ae, oe og aa i stedet for æ, ø og å i filnavne og url'er.

> Ved du, om det er derfor, det er moderne med de bindestreger i stedet for
> mellemrum i adresserne? Der er jo ikke noget til hinder for at lave et link:
> www.sniper-pistol.com/DACOCD-382 Bønnerup spiller i Jægersborg

I gamle dage brugte man bindestreger og ae, oe og aa, fordi det kunne
give problemer med speciel-tegn og mellemrum i filnavne og url'er på
bestemte styresystemer, webservere og browsere. Jeg ved ikke, om det
stadig kan give problemer, men personligt fortsætter jeg med det for en
sikkerheds skyld.

--
Mvh. Kim Ludvigsen
0 new messages