Tijden veranderen
Htaccess maand
Graag zou ik de maand in tekst willen hebben in de URL.
Het is wel gelukt om de maanden in cijfers te krijgen, in de URL(Htaccess).
Ik weet dat F de volledige naam van een maand is.
$dt = new DateTime();
if(isset($_GET['y']) && isset($_GET['m'])) {
if(checkdate($_GET['m'], 1, $_GET['y'])) {
$dt = new DateTime($_GET['y'].'-'.$_GET['m'].'-1');
}
}
$intervalStart = $dt->format('Y-m-d'); // today
$intervalEnd = $dt->format('Y-m-t'); // end of month
echo '<a href="' . $dt->sub(new \DateInterval('P1M'))->format("m-Y") . '">Last month</a>
Htaccess -> ?m=$1&y=$2
Waar kan ik dit het beste allemaal aanpassen?
Met vriendelijke groet,
Levy
Toevoeging op 16/10/2019 15:30:38:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<?php
// PHP program to convert number to month name
// Declare month number and initialize it
$monthNum = 10;
// Create date object to store the DateTime format
$dateObj = DateTime::createFromFormat('!m', $monthNum);
// Store the month name to variable
$monthName = $dateObj->format('F');
// Display output
echo $monthName."\n";
?>
// PHP program to convert number to month name
// Declare month number and initialize it
$monthNum = 10;
// Create date object to store the DateTime format
$dateObj = DateTime::createFromFormat('!m', $monthNum);
// Store the month name to variable
$monthName = $dateObj->format('F');
// Display output
echo $monthName."\n";
?>
Je kan ook prima een datum als dd-mm-yyyy opgeven, afhankelijk van de context.
Dit zou ook min of meer inhouden dat elke pagina achter de schermen een bijbehorend standalone script heeft. Dus elke pagina vormt dan in wezen een ingang naar je website of -applicatie.
Als je zoiets aan het bouwen bent dan zul je dit proces meer moeten stroomlijnen (uit gebruikersgemak, maar ook uit oogpunt van veiligheid). Heel kort door de bocht zorg je dat je hele applicate één poort heeft die je toegang verschaft tot de rest van de code. Deze zogenaamde single point of entry is vaak index.php.
Wat dit soort applicatie dan ook vaak hebben is één enkele rewriterule die alles (intern) doorstuurt naar index.php. In index.php wordt dan de oorspronkelijk aangeroepen URL ($_SERVER['REQUEST_URI']) geïnspecteerd en wordt uitgerekend welke pagina geserveerd moet worden, of als blijkt dat dit bij nader inzien toch een onbekende pagina was, dan wordt een 404 pagina geserveerd. Je rekent dus in feite handmatig de pagina uit die bij een URL hoort, maar daarbij heb je het werk dus gedelegeerd van .htaccess naar PHP.
Een bijkomend voordeel van deze aanpak is dat je het verder uitrekenen van een specifieke pagina op zijn beurt ook verder kunt delegeren naar specifieke functionaliteit. Zo zou je (vanuit index.php) kunnen besluiten dat alles van de vorm calendar/* verder verwerkt wordt door de kalender-functionaliteit zelf. Hiermee paas je in wezen alles door naar de "interne voordeur" van dit specifieke stuk functionaliteit. En dit beïnvloedt verder niet de standaard "flow" waarbij alles door index.php gaat.
Zo zou je dus ook alles van de vorm forum/* kunnen delegeren naar een "forum index.php". Net zoals bij een kalender kan dit zeer handig zijn, want de diversiteit aan (zoekmachinevriendelijke) URL's die deze pagina's allemaal hebben is waarschijnlijk (op den duur) nogal groot, hiervan wil je niet een lijst in index.php hebben die alles doormapt naar een forum-overzicht, -categorie of -berichtenpagina. Dat zou een beetje onbegonnen werk zijn.
Het moge duidelijk zijn dat deze aanpak (single point of entry) zeer behulpzaam kan zijn bij het opstellen van zoekmachinevriendelijke URLs, zonder dat je je hiermee op voorhand beperkt qua mogelijkheden of vrijheid in de naamgeving.
echo '<a href="www.yoursite.com/index.php/iets'.$dt.'">>Last month</a>;
Het bovenstaande is dus maar een half antwoord, en daarmee dus eigenlijk geen antwoord.
Je hebt nu al op (ten minste) drie topics gereageerd met vanuit-de-heup-geschoten antwoorden die nogal kort door de bocht zijn.
Het gaat er niet om dat je zoveel mogelijk antwoorden geeft, het gaat erom dat je antwoorden geeft waar iemand iets aan heeft, en waar men mogelijk/hopelijk wat van opsteekt.
Het is fijn dat je zo enthousiast aan het typen bent, maar zou je dit enthousiasme wat in kunnen dammen ten faveure van iets langere, en beter onderbouwde, antwoorden die ook wat uitleg geven? Het bovenstaande voegt namelijk niet zoveel toe.
$dt = new DateTime(); //2019-11-27 06:00
$dt = date("F",strtotime($dt)); //November
Waarom voegt dit niks toe? En wat is dat voor achtelijke reactie, Thomas?
Het is erg attent dat je iemand wilt helpen, maar let dan op of een topic actueel is, en let er op dat je goede concrete antwoorden geeft die aansluiten op het vraagstuk. Tot nu toe zijn de gegeven antwoorden nog niet echt zinvol te noemen, hoewel het vriendelijk bedoeld zal zijn. Ook is enige uitleg als je een stukje code plaatst zeker niet overbodig.
Gewijzigd op 27/10/2019 13:37:47 door - Ariën -
Ik Google ook vaak wat dingen bij elkaar die ik zo niet precies weet en dat is prima, maar ik neem niet zomaar klakkeloos code of antwoorden over maar probeer te doorgronden wat er gebeurt zodat ik ook echt kan constateren dat het overnemen van code of een idee ook resulteert in het gewenste resultaat.
Vaak kom ik na een korte zoektocht op stackoverflow of een aanverwante site uit en het komt geregeld voor dat de reactie met de hoogste score, die het "antwoord" zou moeten geven op de vraag, niet het goede of beste antwoord is. Ik lees dus altijd nog even verder om te kijken of ik iets mis. Dit kan ontzettend veel inzicht opleveren. Vaak kun je prima volstaan met het (gedachtenloos) overnemen van het "antwoord" maar je mist dan (ten minste) een leermoment.
Dit inzicht, wat je ook opdoet door te programmeren, fouten te maken en deze vervolgens te debuggen (waarbij je echt met de neus op de feiten wordt gedrukt), is vele malen belangrijker dan de precieze code die je inklopt.
De implementatie doet er in wezen niet toe, deze doet naar alle waarschijnlijkheid wat deze behoort te doen en kan vele vormen hebben. Het gaat (wat mij betreft, in ieder geval) om de achterliggende gedachte(n) bij deze code. Daarom reageerde ik misschien wat gepikeerd op de korte codefragmenten zonder enige toelichting, die ook niet echt deden wat de topicstarter voor ogen had.
Achter zo'n reactie steekt misschien wel een briljant idee (waar zelfs ik niet aan gedacht had ;-)) maar als je dat dan niet onder woorden brengt/kunt brengen, hoe moeten anderen dan (direct) begrijpen wat je probeert te bereiken? Toegegeven, dat is een kunst apart, maar ook dat kun je min of meer leren door te oefenen.
En om antwoord te geven op je vraag:
Quote:
Waarom voegt dit niks toe?
Ik zei "niet zoveel", niet "niks". Op het moment dat je een soort van (complete) custom naamgeving wilt in de adressen van je webpagina's moet je ineens een heleboel dingen gaan regelen. Je moet dan een soort van stramien hebben die je in staat stelt om elke willekeurige URL te kunnen verwerken. En liefst ook een beetje op een fijne manier, wat het bakken van 4389573489538957358 RewriteRules al min of meer uitsluit :).
Vrije naamgeving in URLs valt min of meer in twee delen uiteen:
#1 het opstellen van de URLs zelf, en
#2 het verwerken van een URL die resulteert in het uitvoeren van de juiste bijbehorende code
Het gros van het werk zit in #2. Neemt niet weg dat #1 minder belangrijk is, maar als je ergens de nadruk op zou moeten leggen dan is dat #2.
Je zou #1 uit de losse pols kunnen doen, die verder helemaal niet is afgestemd op #2. Dat is in feite wat je in jouw codefragment doet: je verzint een of andere naamgeving voor een maand en plakt deze in een of andere (weliswaar statische, hard coded) URL. Prima, dat doet in wezen wat het moet doen en geeft "antwoord" op de vraag. Het dekt #1 min of meer, afgezien van het feit dat je rechtstreeks /index.php/ aanspreekt. Het idee van custom naamgeving is juist dat index.php zijn werk stilzwijgend op de achtergrond doet. Ook bestaat de site mogelijk uit meerdere onderdelen, dus het is misschien handig om dit op zijn minst te compartimenteren in een apart /calendar/ onderdeel ofzo. Wat in de kalenderfunctionaliteit gebeurt zou geen invloed moeten hebben op de naamgeving van de rest van de site tenzij misschien de hele website één grote kalender is ofzo, maar dat weet ik niet, dus daar doe ik ook geen aannames over.
Maar dan ga je eens kijken naar #2, de afhandeling hiervan. Hoe ga je zorgen dat deze altijd en onder alle omstandigheden werkt? De URL uit #1 was voor een groot deel statisch: het domein is hard coded. Dit heeft al tot gevolg dat zodra je deze code naar een ander domein verplaatst dat deze niet meer werkt. Er staat ook geen protocol voor de www, dus mogelijk wordt deze URL als een relatieve link beschouwd. Dan heb je gekozen voor "iets" als prefix (voorvoegsel), gevolgd door de maandnaam. Maar je bent helemaal vrij in je naamgeving, wat als je hier iets anders van maakt, bijvoorbeeld "kalender" ofzo, je hebt dan een omschrijvende naam van wat dat onderdeel doet. Hierbij zou (?) je ook gebruik moeten maken van slashes (/) om de verschillende onderdelen aan te duiden en niet alles simpelweg aan elkaar plakken. Elk partje van de URL heeft dan op die manier ook echt "betekenis". Een URL wordt dan bijvoorbeeld /kalender/december, ik noem maar wat. Maar je URL is nog steeds statisch. Wat als op een gegeven moment besloten wordt dat de /kalender functionaliteit verhuist naar het onderdeel /evenementen? Op dit moment is er geen enkele koppeling tussen #1 en #2 dus dat verandert niet automatisch mee. Je moet dan weer in code/een template gaan hacken om deze hard coded waarde te fixen. Wat ook weer foutgevoeliger wordt als je vanuit meerdere plaatsen naar deze functionaliteit verwijst.
Dit zou een ander verhaal zijn wanneer de volledige URL dynamisch opgebouwd zou worden met een soort van linkfunctie. Dan zou het protocol, de website en de interne locatie (van de "voordeur" van deze functionaliteit) dynamisch mee kunnen veranderen op het moment dat deze wijzigen en deze functionaliteit genereert dan automatisch de nieuwe URL zonder dat je ook maar één letter code hoeft aan te passen.
Als je dus met dit soort routingsvraagstukken te simpele oplossingen kiest dan bijt dit je waarschijnlijk na verloop van tijd enorm in je staart. Het is van groot belang dat je veel zorg en denkwerk steekt in je aanpak, zodat je hier bij een generieke implementatie de vruchten van kunt plukken.
Het streven zou altijd "Zo simpel mogelijk, maar niet simpeler." moeten zijn.
Het makkelijke deel van dit hele verhaal zit nog steeds in het genereren van de URLs (wat dus eigenlijk dynamisch zou moeten zijn) en in zekere zin maakt het niet zoveel uit wat je kiest (maar zinvole naamgeving is wel een pre) dus het enkel geven van een "implementatie" van één naamgevingsvariant lost het probleem nou niet bepaald op. Te meer omdat je nog met de hele verwerking (#2) zit. En daarbij de rest van je site ook nog normaal door moet blijven werken.
Daarom voegt jouw antwoord dus niet zoveel toe :).
NB: je zou natuurlijk ook voor een tussenvorm kunnen kiezen, waarbij je gedeeltes van URLs dynamisch maakt. Dan zou je wel wat meer RewriteRules kunnen inzetten, maar het gevaar daarvan is dat je dan toch snel weer op een hellend vlak terecht komt.
Gewijzigd op 27/10/2019 17:09:04 door Thomas van den Heuvel