lastModified : extra nulletje voor dag 1 t/m 9 en extra nulletje voor maand 1 t/m 9

Status
Niet open voor verdere reacties.
J

janyep

Gebruiker
Lid geworden
7 mei 2008
Berichten
261
Hallo,
weet helemaal niets van javascript, dus ondanks een hoop gepriegel lukt het niet
Laatst bijgewerkt: 10-5-2012

te wijzigen in:

Laatst bijgewerkt: 10-05-2012

Code: 
					<!-- bron: http://doctype.com/write-javascript-page-last-updated-works-all-browsers -->
					<script language="Javascript" type="text/javascript">
					var lastModificationDate = new Date(document.lastModified);
					var a = (lastModificationDate.getYear() ); if (a<200) {a=(a+1900);}
					document.write('<b>Laatst bijgewerkt: ' + lastModificationDate.getDate() + '-' + (lastModificationDate.getMonth()+1) +'-' + a + '</b>'); </script>

Uiteraard hoop ik 1 mei ook weer te geven met een nulletje: 01-05-2012

Zou iemand mij verder kunnen helpen?

met vr. groet, janyep

ps. maandnamen laat ik in cijfers, mei = 05
 
Kijk eens hier (gevonden door te googelen op 'javascript' 'date' 'leading' en 'zero').
 
Hij doet het !

maar ik kan haast niet geloven dat het echt klopt.

Klopt deze schrijfwijze echt?

Ik begrijp dat dit heet "JavaScript slice() Method"
maar verder is het abacadabra: de wagen rijdt met mij in plaats van ik met de wagen :d

Code: 
					<script language="Javascript" type="text/javascript">
					var lastModificationDate = new Date(document.lastModified);
					var a = (lastModificationDate.getYear() ); if (a<200) {a=(a+1900);}
					document.write('<b>Laatst bijgewerkt: ' + [B][COLOR="#FF0000"]('0' + lastModificationDate.getDate()).slice(-2)[/COLOR][/B] + '-' + [B][COLOR="#FF0000"]('0' + (lastModificationDate.getMonth()+1)).slice(-2)[/COLOR][/B] +'-' + a + '</b>'); 
					</script>
 
<time datetime> ?

Hallo Supersnail,

mag ik nog even?

In HTML5 kon ik het zo kwijt:
HTML: 
Laatst bijgewerkt: <time datetime=2016-01-31>31-01-2016</time>

Weet u misschien waar ik de <time datetime> nu zou kunnen zetten?
Alleen: als dat kan, de 31-01-2016 gaat nu automatischmet dat javascript, en de datetime zou dan toch handmatig moeten gebeuren. Of niet?

Of moet ik hiervoor naar het HTML-forum?
 
Laatst bewerkt:
Last modified ... of niet?

Hoi janyep,
Mag ik ook even? ;) Eerst m'n vragen-reactie, daarna de Algemene Beschouwingen.

Javascript
Ik begrijp dat dit heet "JavaScript slice() Method". Klopt deze schrijfwijze echt?
Klik om te vergroten...
Ja, in principe wel (in de html-code mag de language="javascript" er niet bij, dat is invalid html; en de getYear() is afgekeurd javascript, dat moet getFullYear() zijn).
Hoe de kar rijdt:
  • Het systeem van datum opvragen en weergeven staat hier uitgelegd.
  • Bij het gevonden aantal maanden wordt er eerst altijd een 0 vóór gezet, eigenlijk staat er: variabele maand = "0" + (waarde gevonden maand).
  • Samen is dat een string geworden, dus het is geen getal meer.
  • Als de gevonden maand was: 5, dan komt er dus 05 te staan.
  • Als de gevonden maand was: 11, dan komt er óók de voorloop-nul bij, en wordt het 011.
  • De truc met de slice()-functie (zie hier) is, dat er vervolgens maar 2 lettertekens van de string getoond worden, en vanwege de negatieve waarde van het opgegeven aantal tekens wordt van achteraf gerekend.
  • Dus 05 heeft maar twee lettertekens, en dat blijft zo.
  • Maar 011 heeft 3 lettertekens, en het mogen alleen de 2 laatste zijn, dus dat wordt: 11. - Q.E.D. :)
  • In feite de omgekeerde truc van "als gevonden maand kleiner is dan 10, zet er dan een 0 voor" (dat kan ook met javascript).

<time datetime="..">..</time>
Het html5-element <time> wordt momenteel niet ondersteund door de browser-engines Trident (=Internet Explorers en afgeleide browsers), Gecko (= Firefox e.a.) en Webkit (= Chrome en Safari). Alleen Presto v/a 2.8.146 doet het (= Opera v/a versie 11.5): zegt Wikipedia, zie hier. Maar Opera 11.5 doet het bij mij niet (Try It Yourself). Dat klopt dan met wat w3schools zegt over time/datetime: geen enkele browser-support.
  • Dus die html5-zou ik niet gebruiken, want hoe het ook zit met de laatste versie van Opera: de rest doet het niet.
  • Ook begrijp ik dat het hier uitsluitend om een notatie-aangelegenheid gaat, dus hier zou alsnog een script in gezet moeten worden om de lastModified-datum er in te krijgen.

Algemene Beschouwingen
  • Als javascript uit staat, werkt het niet. Dan zou je een server-side alternatief (met php) moeten gebruiken.
  • Als jullie nieuwe site een php-site wordt, wat erg aan te raden is (om de eenvoud er in te houden en makkelijk gelijkblijvende delen te includen), dan loopt ook spaak als javascript aan staat.
Bij een php-site timmert de php-machine op de server namelijk de pagina pas in elkaar vlak voor het downloaden door de bezoeker, en is de aanmaak-datum ("laatste update") die het javascript fabriekt ... altijd de datum waarop de bezoeker de pagina bekijkt!
Daar heb je dan weinig aan! :rolleyes:
Vergelijk:

Een php-pagina kan wel met php van een constante update-datum en -tijd voorzien worden.

Maar wat zegt een automatische update-datum eigenlijk (niet)?
  • Een nieuwe update-datum kan bv. veroorzaakt zijn door een correctie van een niet-essentieel tikfoutje of een veranderde pagina-naam in een link. Dan zegt de update-datum niets over de eigenlijke laatste update van de inhoud.
  • Een nieuwe update-datum kan bv. veroorzaakt zijn door een technische wijziging, zoals het aanroepen van een ander include-bestand voor het menu. Ook dan zegt de update-datum niets enz.
  • Een pagina kan 3 jaar geleden voor het laatst een update gehad hebben, en intussen zwaar verouderd zijn (bv. omdat openingstijden of bedragen veranderd zijn).
  • Een andere pagina kan ook 3 jaar geleden voor het laatst een update hebben gehad, maar nog steeds actualiteitswaarde hebben omdat de inhoud nog steeds correct is. Bij het zien van "Laatste update: 3 jaar geleden" zal de bezoeker al gauw geneigd zijn te denken: "Mmm, dat zal wel verouderd zijn...". Maar niets is minder waar!
Kortom, zo'n auto-updatedatum zegt eigenlijk niets.
Waar een bezoeker veel meer aan heeft, is een vermelding: "Laatste gegevens-controle van deze pagina: ... (datum)".
Daar zit bv. de link-controle bij inbegrepen.
  • Maar dit moet er wel steeds met de hand in gezet worden! ;)
Hoewel: een kleine en eervolle moeite, als je een hele info-intensieve pagina doorgevlooid hebt of alles nog klopt.

En tenslotte:
Als je een losse update-pagina hebt waarin de belangrijke updates chronologisch worden vermeld *), kan de bezoeker gauw achterhalen of hij/zij een pagina opnieuw moet gaan bekijken omdat wellicht zijn/haar printje niet meer klopt. :)
Eventueel kan bij de "Laatste controle"-vermelding dan naar de betreffende bladwijzer in het update-overzicht worden verwezen.

Met vriendelijke groet,
CSShunter
__________
*) Ik zou niet zoals nu de hele waslijst aan updates meteen op de homepage zetten. Daar kan volstaan worden met bv. de laatste drie als Nieuwsbericht, met een "Lees meer..." link naar de speciale update-pagina.
Zo kom je weer wat dichter bij een ideale lichtgewicht website (ook qua informatie-dichtheid per pagina). :cool:
 
Hoy csshunter,

Helemaal overtuigd: <time datetime> is dus knap zinloos, niet doen dus. Prima :thumb:

Helemaal overtuigd: losse update-pagina staat op het to-do-lijstje

PHP
heb dat al eens overwogen, maar heb ook eens gelezen dat het de vindbaarheid voor de zoekmachines zou bemoeilijken ( ? )
http://www.veit.nl/143733-php-en-zoekmachine
Klopt dat "algemeen beschouwd?" of zijn dat bakerpraatjes?

Weer hartelijk dank zover!
vriendelijke groet, janyep


persoonlijke reminders:
http://forums.polurnet.com/index.php?showtopic=623
http://web.archive.org/web/20101015192814/http://developerscorner.nl/csshunter/menu-page.php :shocked:
 
PHP ... zou de vindbaarheid voor de zoekmachines bemoeilijken ( ? )
Klik om te vergroten...

Dat is maar gedeeltelijk waar, en voor de rest flauwekul.
Tik in Google bv. in (met aanhalingstekens): "terug naar Knutselpagina fase 6 van de Tutorial" Wiel
Dat is een op internet unieke trefzin met een los trefwoord, die maar op 2 webpagina's in de hele wereld voorkomt.

Het zijn qua inhoud twee volstrekt identieke pagina's:
  • de ene is een html-versie met alle html-code er in,
  • de andere is een php-pagina, waarbij o.a. het kolommetje met het trefwoord Wiel er met een php-include in geplakt wordt op de server.

En wat is het Google-resultaat?
Google vindt ze gewoon alle twee, en behandelt ze gelijkwaardig. :)

=======
"php-parameters"
Wat wel een rol speelt, zijn de php-parameters waar ze in je geciteerd forum-topic de hele tijd over aan het bakkeleien zijn.
Dan heeft een URL van een pagina bv. de vorm:
Code: 
www.site.nl/forum/showthread.php[COLOR="#B22222"]?p=4503411[/COLOR]
De parameter is hier het gedeelte achter het vraagteken, dat speciale opdrachten aan de server geeft.
Met name een aantal CMS'sen hebben er een handje van om zo hun pagina's te definiëren (ipv bv. showthread4503411.php)
De laatste is een echte eigen pagina, die met de parameter niet.
Nu kan je van alles en nog wat in een parameter stoppen:
  • bij de ene site zal bv. de parameter ...?p=512 betekenen: "ga naar pagina 512",
  • bij een andere site kan de parameter ...?p=512 betekenen: "zet op de opgeroepen pagina dat de klant artikel 512 in het winkelwagentje heeft gedaan".
Google kan met geen mogelijkheid bevroeden wat zo'n parameter betekent, en of dat aanleiding moet zijn zo'n pagina apart te indexeren als deze in een link op een andere pagina is opgenomen.

Geen php-parameters!
Maar als je die parameters niet gebruikt, heb je daar geen last van. :)
En er zijn goede redenen om ze niet of alleen met uiterste omzichtigheid te gebruiken. Uit de webrichtlijnen.nl (telkens met uitleg):

Conclusie:
Als je alleen php gebruikt voor php-includes (meer heb je in principe niet nodig voor een snelle php-site) en misschien voor nog een paar dingetjes binnen een pagina, maar de URL's gewoon intact laat, is er niets aan de hand, en indexeert Google dat het een lieve lust is.

Met vriendelijke groet,
CSShunter
__________
PS: eventueel leesvoer: Mini-tutorial: de opzet van een php-site ;)
 
Hoi csshunter

parse PHP code in your .html file without changing the file extension to .php
Klik om te vergroten...
= http://forums.polurnet.com/index.php?showtopic=623
omdat ooit is overwogen de bestaande domein te verbouwen en om dan toch de URL's te behouden.

Nu er een nieuwe domein komt, moet dat niet meer perse.

ben nog niet zover, maar welke heeft t.z.t. de voorkeur:

website.html met daarin php
of
website.php

Met vriendelijke groet,
janyep
 
@ Supersnail:
Ah, Google kan dus beter met parameters omgaan dan ik dacht; ik volg de Google-ontwikkelingen niet zo: liep wat achter.
Het Google-verhaal gaat vooral over het aanpassen (URL-rewriten) van zulke dynamische URL's in pseudo-statische URL, wat soms problemen bij de indexering kan opleveren.
Maar m'n conclusie blijft daarmee toch overeind? Als je géén parameters / dynamische URL's gebruikt, dan gaat het toch gewoon altijd goed?
- En ook de geciteerde webrichtlijnen lijken me nog steeds hun waarde te hebben.

@janyeb:
Als je de pagina's de .htm of .html extensie geeft, terwijl ze php-includes bevatten, moet een extra opdracht gegeven worden aan de server om .html / .htm pagina's te behandelen alsof het .php pagina's zijn (dwz eerst langs de php-machinerie te laten gaan).
Anders worden de includes genegeerd, en komen er wat kale pagina's. ;)

Als je de pagina's een .php-extensie geeft, hoeft dat niet.
Het bezwaar dat niet-php pagina's dan wat langzamer zijn, lijkt met niet zo van toepassing. Die uitsluitend-html pagina's zullen er niet zijn: op elke pagina zal wel een include staan die met php opgehaald moet worden.
Dus ik zou voor .php gaan. *)

Met vriendelijke groet,
CSShunter
_________
*) De include-fragmenten zelf kunnen wel de .htm uitgang krijgen (of een willekeurige zelfgekozen uitgang bv. menu.fragment, footer.fragment enz.; zolang de verwijzing maar klopt) - tenminste als de includes in html geschreven zijn en zelf niet ook php-includes bevatten.
Het bezwaar van php-vertraging is dan weggenomen.
 
csshunter zei:
Maar m'n conclusie blijft daarmee toch overeind? Als je géén parameters / dynamische URL's gebruikt, dan gaat het toch gewoon altijd goed?
- En ook de geciteerde webrichtlijnen lijken me nog steeds hun waarde te hebben.
Klik om te vergroten...

Klopt, als je geen parameters/dynamische URL's gebruikt gaat het altijd goed. Ik meen me alleen te herinneren dat er een webrichtlijn is die zegt dat je dynamische URL's moet herschrijven in pseudo-statische URL (hoewel ik die richtlijn nu even niet kan vinden).
 
Deze? (staat niet inde richtlijnen zelf, maar in de Aan-de-Slag's):

Welke consequenties dat heeft voor Google, kan ik niet overzien.
De boys en girls van de webrichtlijnen zijn terdege ingevoerd in de materie, en gaan er prat op dat ze erg zoekmachine-vriendelijk zijn, dus ik verwacht niet dat ze hun volgers met dit advies het bos in sturen.
Ook mijn intuïtie zegt dat het wel meevalt, maar in de wereld der techniek werkt m'n intuïtie niet altijd. ;)
 
Mooi, csshunter : weer een stapje verder!

Hartelijk dank, janyep
 
Status
Niet open voor verdere reacties.
                    Steun ons                    

Nieuwste berichten

Terug
Bovenaan Onderaan