My wish would be to create the possibility to omit file extensions for HTML documents such as html or php or to make them configurable. So instead of /path/filename.html I would like to use /path/filename or /path/filename/.
Of course, the static copy of the website created may then only be usable with the help of a web server. This is a known fact.
I assume that the URL will be split into its components anyway. Ideally, you could then make the directory hierarchy and the file name structure fully configurable. The components could be assigned to variables or placeholders and then used in the new parameter.
s:scheme
h:host
p:path (with leading but without trailing slash)
f:filename (without last dot and extension)
e:extension (without dot)
b:basename (with all dots and extension)
q:query (without ?)
a:fragment (anchor link without #)
We should make it as simple as possible and stick to the rules of parse_url() and pathinfo().
Example: --custom-site-structure='%s%h%p/%f__%q#%a'
Care must be taken to ensure that there is no collision with the replace-query-string functionality.
Adjusting the file extension for HTML documents would be sufficient for now. However, my ideas may be useful for preparing further configurability in the code, even if this is not yet feasible.
My wish would be to create the possibility to omit file extensions for HTML documents such as html or php or to make them configurable. So instead of /path/filename.html I would like to use /path/filename or /path/filename/.
Of course, the static copy of the website created may then only be usable with the help of a web server. This is a known fact.
I assume that the URL will be split into its components anyway. Ideally, you could then make the directory hierarchy and the file name structure fully configurable. The components could be assigned to variables or placeholders and then used in the new parameter.
We should make it as simple as possible and stick to the rules of parse_url() and pathinfo().
Example: --custom-site-structure='%s%h%p/%f__%q#%a'
Care must be taken to ensure that there is no collision with the replace-query-string functionality.
Adjusting the file extension for HTML documents would be sufficient for now. However, my ideas may be useful for preparing further configurability in the code, even if this is not yet feasible.