There's no data stored into physical or logic folders, all data is usually set inside the database instead, so why do you want to add and map an inexistent server directory?
Well it's not a server directory, it's a rewrite rule that generates a DB query.
The original purpose of this style of URL structures is to have a human navigable path (which has the side effect of also helping search engines, especially 15-20 years ago).
By "human navigable" I mean that a human can easily decompose the URI back to the site root and get meaningful content along the way.
/2020/09/12/some-blog-post is a blog post posted today
/2020/09/12/ remove the post slug and now you've got all posts from today
/2020/09/ remove the day and now you've got all posts from this month
/2020/ remove the month and now you've got all posts from the year.
/ remove the year and now you've got all posts on the blog.
Without this structure a human would have to perform a search typically with an ugly URL with a bunch of query params that are difficult for a human to type easily. Sure you could dynamically generate a link to archives that fills in the params but you don't really want to pollute your pages with links for every year, month and day you've posted content.
This URL structure is an artifact from the early days of blogging when we had much debate exactly like this.
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
Yup, of course I know and understand the origin. Moreover there was some blogging tools that generates physical/logical server directories with text files to store the data.
Nowadays you don't need those params, and the average user hardly will be editing the URL so you build usable UIs with nice options to search and filter through your data to provide content to your users/customers. That implies providing links that shows correctly and on a non-verbose way what it's all about. Specially because most of time the URL string is shown break so you can not read it all.
Moreover if you provide a good search in between your data (title, content, category, tags, media alts and so) it will be much more fast than giving options to filter only (by year, category and tags).
Well it's not a server directory, it's a rewrite rule that generates a DB query.
The original purpose of this style of URL structures is to have a human navigable path (which has the side effect of also helping search engines, especially 15-20 years ago).
By "human navigable" I mean that a human can easily decompose the URI back to the site root and get meaningful content along the way.
/2020/09/12/some-blog-postis a blog post posted today/2020/09/12/remove the post slug and now you've got all posts from today/2020/09/remove the day and now you've got all posts from this month/2020/remove the month and now you've got all posts from the year./remove the year and now you've got all posts on the blog.Without this structure a human would have to perform a search typically with an ugly URL with a bunch of query params that are difficult for a human to type easily. Sure you could dynamically generate a link to archives that fills in the params but you don't really want to pollute your pages with links for every year, month and day you've posted content.
This URL structure is an artifact from the early days of blogging when we had much debate exactly like this.
Yup, of course I know and understand the origin. Moreover there was some blogging tools that generates physical/logical server directories with text files to store the data.
Nowadays you don't need those params, and the average user hardly will be editing the URL so you build usable UIs with nice options to search and filter through your data to provide content to your users/customers. That implies providing links that shows correctly and on a non-verbose way what it's all about. Specially because most of time the URL string is shown break so you can not read it all.
Moreover if you provide a good search in between your data (title, content, category, tags, media alts and so) it will be much more fast than giving options to filter only (by year, category and tags).
Also for RSS sharing getting a link like:
domain/post-title
Will be preferred in comparison to:
domain/year/month/day/post-title