Kleine Vragen Topic #4

Waarom zou je dat willen weten dan? De datum staat meestal toch wel vermeld op de pagina, ik ga dan echt niet in de url zoeken naar een mogelijke datum..

Bugged schreef:

Waarom zou je dat willen weten dan? De datum staat meestal toch wel vermeld op de pagina, ik ga dan echt niet in de url zoeken naar een mogelijke datum..

Want je moet ook echt zoeken in die url?Zie je toch gelijk als je die url leest..

Luuko schreef:

Eerdere citaten tonen

Bugged schreef:

Waarom zou je dat willen weten dan? De datum staat meestal toch wel vermeld op de pagina, ik ga dan echt niet in de url zoeken naar een mogelijke datum..

Want je moet ook echt zoeken in die url?Zie je toch gelijk als je die url leest..

Ik bedoelde het iets anders, als ik naar een datum zoek, ga ik niet eerst in de url kijken maar op de pagina zelf.

Dylan schreef:

Eerdere citaten tonen

Sevvlor schreef:

Wat voor URLs vinden jullie beter: /posts/2017/01/01/dit-is-een-blog of: /posts/dit-is-een-blog

De eerste , weet heb gelijk wanneer de blog gepost is.

Het ligt een beetje aan het doeleinde. Als het om nieuwsberichten gaat die anderen delen, dan zou ik voor de gemakkelijkheid de datum erbij zetten. Dan weet iedereen als ze de URl zien of het een recent nieuwsbericht is.

Als het bericht geen meerwaarde heeft om te delen voldoet de titel.
Ikzelf gebruik liever een ID of andere unieke waarde in de URL. Bijvoorbeeld:

http://www.treinenweb.nl/news/4397/papieren-treinkaartje-hoeft-niet-terug-te-keren.html

Sevvlor schreef:

Wat voor URLs vinden jullie beter: /posts/2017/01/01/dit-is-een-blog of: /posts/dit-is-een-blog

Eerste, sowieso.
Vind het super fijn als de datum erbij staat.
Is een algemene plek om de datum neer te kwakken, ipv dat je de hele pagina door moet zoeken waar déze website nou weer de datum heeft staan.
Daarnaast staat het gewoon netter.

toevoeging op donderdag 9 maart 2017, 1810:

Aarclay schreef:

Eerdere citaten tonen

Dylan schreef:

Eerdere citaten tonen

Sevvlor schreef:

Wat voor URLs vinden jullie beter: /posts/2017/01/01/dit-is-een-blog of: /posts/dit-is-een-blog

De eerste , weet heb gelijk wanneer de blog gepost is.

Het ligt een beetje aan het doeleinde. Als het om nieuwsberichten gaat die anderen delen, dan zou ik voor de gemakkelijkheid de datum erbij zetten. Dan weet iedereen als ze de URl zien of het een recent nieuwsbericht is.

Als het bericht geen meerwaarde heeft om te delen voldoet de titel.
Ikzelf gebruik liever een ID of andere unieke waarde in de URL. Bijvoorbeeld:

http://www.treinenweb.nl/news/4397/papieren-treinkaartje-hoeft-niet-terug-te-keren.html

Wat heeft de bezoeker aan een ID? Als je die link nu deelt, heb ik een idee waar het over gaat, maar niet hoe oud het artikel is.

Je zou bijvoorbeeld een link plaatsen:
nu.nl/news/1234/obama-blijft-president-van-amerika
Terwijl dat een artikel van like 4 jaar geleden zou zijn.

@Jessee De bezoeker heeft inderdaad niks aan het ID, maar hoe moet ik het juiste bericht dan ophalen in de database? De titel wil soms ook wel eens aangepast worden tussentijds ([update] tagje of algehele aanpassing van titel m.b.t. actualiteiten bijv.), en dan zouden andere URLs niet meer werken.

Als je een robuuste manier kent, dan hoor ik die graag. En verder ben ik ook benieuwd hoeveel mensen er nou werkelijk naar die datum-kenmerken in de URL kijken.

Iemand die kan toelichten hoe Laravel (5.4) precies omgaat met inloggen e.d.? Ik wil het inloggen uitbreiden met two-factor authentication, maar ik weet niet precies waar ik wat moet aanpassen om ervoor te zorgen dat ie je niet inlogt, maar eerst redirect naar een pagina om je 2FA te valideren, voordat je wordt ingelogd, sessie wordt gemaakt en redirect naar homepagina krijgt..

Bugged schreef:

Iemand die kan toelichten hoe Laravel (5.4) precies omgaat met inloggen e.d.? Ik wil het inloggen uitbreiden met two-factor authentication, maar ik weet niet precies waar ik wat moet aanpassen om ervoor te zorgen dat ie je niet inlogt, maar eerst redirect naar een pagina om je 2FA te valideren, voordat je wordt ingelogd, sessie wordt gemaakt en redirect naar homepagina krijgt..

Je kunt zelf je Auth routes aanmaken en eventueel koppelen aan je eigen LoginController. Deze laat je dan je 2FA afhandelen en daarna laat je de échte login afhandelen door Laravels LoginController.

Aarclay schreef:

@Jessee De bezoeker heeft inderdaad niks aan het ID, maar hoe moet ik het juiste bericht dan ophalen in de database? De titel wil soms ook wel eens aangepast worden tussentijds ([update] tagje of algehele aanpassing van titel m.b.t. actualiteiten bijv.), en dan zouden andere URLs niet meer werken.

Als je een robuuste manier kent, dan hoor ik die graag. En verder ben ik ook benieuwd hoeveel mensen er nou werkelijk naar die datum-kenmerken in de URL kijken.

Titels kan je aanpassen, slugs niet(!!)
En [Updated] kan je dan in de titel zetten, de slug wordt dan niet aangepast.
En slug moet dan uniek zijn per dag.. Maar het liefst nog voor altijd.
Als je een monthly update wil doen dan is het:
/news/2017/01/01/montly-update-january
/news/2017/02/01/montly-update-february
/news/2017/03/01/montly-update-march

En de titel kan dan zijn: "Monthly Update", maar kan ook zijn: "Montly Update [January]" bijvoorbeeld.

Dan zou ik dus de slugs als de identifier moeten gebruiken i.p.v. de IDs, en die voor alle bestaande items moeten genereren in een apart databaseveld zodat die vast blijven staan. Maar dan moet je ook een extra tabel hebben die meerdere slugs aan één artikel kan koppelen. Want je wilt dat meerdere slugs op hetzelfde artikel uitkomen om dode URLs tegen te gaan.

Ik zal eens wat proberen binnenkort, en houd het in gedachten voor een volgende update van mijn site.

Alleen een oplopend getal is doorgaans kleiner dan een slug, dus beter voor indexatie.

Jessee schreef:

Alleen een oplopend getal is doorgaans kleiner dan een slug, dus beter voor indexatie.

Daarmee beweer je dat een korte URL beter is dan een langere URL? Is daar enige vorm van bewijs voor? Het lijkt me namelijk niet uit te halen, tenzij je echt een gigantisch lange URL hebt.

Aarclay schreef:

Dan zou ik dus de slugs als de identifier moeten gebruiken i.p.v. de IDs, en die voor alle bestaande items moeten genereren in een apart databaseveld zodat die vast blijven staan. Maar dan moet je ook een extra tabel hebben die meerdere slugs aan één artikel kan koppelen. Want je wilt dat meerdere slugs op hetzelfde artikel uitkomen om dode URLs tegen te gaan.

Ik zal eens wat proberen binnenkort, en houd het in gedachten voor een volgende update van mijn site.

Dat is wat ik nu doe. Ik sla gewoon steeds een nieuwe slug op bij een verandering daarnaast heb ik óók het datumsysteem ingebouwd

Hallo Allemaal,

Ik heb een PHP script gemaakt om de nu spelende track van mijn shoutcastserver af te halen. Dit werkt super. Alleen nu refresh ik het met meta, dus elke keer is de browser druk bezig om te vernieuwen en dat zie je.

Nu had ik gelezen dat dit met javascript ook mogelijk is, en het laden dan stukken minder wordt.

Iemand tips of ideeën?

Lennard schreef:

Eerdere citaten tonen

Jessee schreef:

Alleen een oplopend getal is doorgaans kleiner dan een slug, dus beter voor indexatie.

Daarmee beweer je dat een korte URL beter is dan een langere URL? Is daar enige vorm van bewijs voor? Het lijkt me namelijk niet uit te halen, tenzij je echt een gigantisch lange URL hebt.

Integer is kleiner (in bits), en volgens mij daarom ook sneller (qua indexatie)

toevoeging op zaterdag 11 maart 2017, 13:55:17:
En beweer niet dat kleine url beter is dan een lange, maar dat ID denk ik beter zou zijn voor indexatie dan een slug.

toevoeging op zaterdag 11 maart 2017, 13:56:07:
http://stackoverflow.com/a/5504621

Verder zelf nog niet getest, pin mij er daarom ook niet op vast dat wat ik nu zeg klopt hoor.