Closed mrmowgli closed 8 years ago
Why?
Yea we don't control that subdomain
I was expecting this document to serve as an index: http://docs.kicad-pcb.org/en/webdocindex.html
How is docs.kicad-pcb.org generated? is it directly CMake's "build" directory?
@Caerbannog I know that you wrote the webdocindex, but now that we have http://kicad-pcb.org/help/documentation/ I don't think we need it, and I like to have the directionary listing it make it easier for people to discover the docs on that location in case the website (index) is not up to date.
But basically the things on docs.kicad-pcb.org is generated by the jenkins job, http://ci.kicad-pcb.org/job/any-kicad-doc-head/ Check the logs for the exact steps performed, commands are prefixed with "+ " in the log.
I agree with dropping the webdocindex for the freshness issue.
The current listing is quite crude, though.
cvpcb
, eeschema
, ... directories only contain an image folder, unused as far as I can tell.As is right now, there is app names in the root... but I did not intend that to be like so, I only wanted the languages. I have been trying to figure out why it is like so, but I can't see the error in my script.
Adding a link back would probably be good. But the webserver is not cherokee but nginx at the docs sudomain at the current time. Is it ok to fix this with a README file for now?
This module sounds good if time allows: http://www.nginxtips.com/nginx-fancyindex-ubuntu/
README draft follows. Do you want to include it in the CMake build or push it manually to the server?
Refer to KiCad's website for the state of the documentation and its translations:
http://kicad-pcb.org/help/documentation/
A recent snapshot is available at http://docs.kicad-pcb.org/
The server uses Cherokee On Sep 25, 2015 5:28 PM, "Caerbannog" notifications@github.com wrote:
This module sounds good if time allows: http://www.nginxtips.com/nginx-fancyindex-ubuntu/
README draft follows. Do you want to include it in the CMake build or push it manually to the server?
Refer to KiCad's website for the state of the documentation and its translations:http://kicad-pcb.org/help/documentation/
A recent snapshot is available at http://docs.kicad-pcb.org/
— Reply to this email directly or view it on GitHub https://github.com/KiCad/kicad-website/issues/72#issuecomment-143358777.
It's possible to do in the client index.html page: http://www.w3.org/TR/2015/NOTE-WCAG20-TECHS-20150226/H76
Or alternately if it's shared documentation with the rest of the source you can add a javascript fragment to move you to the full documentation if it detects 'docs.' in the url.
<!DOCTYPE html>
<html>
<head>
<title>Original page to redirect from.</title>
<script type="text/javascript">
var redirector = function() {
if (window.location.href.match(/docs\./m))
window.location.href = 'http://kicad-pcb.org/help/documentation/';
}()
</script>
</head>
<body>
Your page has permanantly moved.
</body>
</html>
@mrmowgli From what I understand, the domain docs.kicad-pcb.org will always serve the most up-to-date documentation. The only redirection that could be considered is for the index, but @nickoe indicated that:
...the listing makes it easier for people to discover the docs ... in case the website is not up to date
So no redirection is desirable, and the discussion moved to improving the index while keeping its dynamic nature.
Ah I see. Makes sense. Then really the current documentation build isn't working correctly? Also why have a separate http://kicad-pcb.org/help/documentation/ if they don't refer to the same documents?
Got it. I'll leave this open until the subdomain pulls up the actual documentation not the raw directory structure. I know kiCad currently directs help requests here.
@mrmowgli You never really answered my original question, but as @Caerbannog said, I had the antiargument. And I the http://kicad-pcb.org/help/documentation/ do refer to the same documents.
Existing links and shortcuts to docs.kicad-pcb.org will be broken, any resource requests should receive a HTTP 301 response: