[
https://issues.apache.org/jira/browse/SOLR-10295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15985637#comment-15985637
]
Hoss Man commented on SOLR-10295:
---------------------------------
bq. Second, we have no index.html in the set of files that are generated for
the webserver to default to if someone goes to just
https://lucene.apache.org/solr/guide/test-10290, for example. You just get a
listing of files under that path. We either need to do some redirect magic in
.htaccess, or change the "home" page of the Guide to be named index.html (which
has a bunch of other implications to the build process since the page
"apache-solr-reference-guide.adoc is considered the super-parent of every other
page of the Guide).
I think I brought this up in an github issue in the old POC repo but we never
discussed it much...
It would be fairly simple to change the "one time cwiki->asciidoc" code to use
{{index.adoc}} as the (created) name for the page currently named
{{apache-solr-reference-guide.adoc}} if that's what we want to -- but that
would mean all the pages that refer to it as a parent / link to it would have
to refer to it as {{index}} not {{apache-solr-reference-guide}} (this would
happen automatically for the "one time cwiki->asciidoc" converted
links/references).
Alternatively, a {{DirectoryIndex}} entry (or rewrite rule) in an {{.htaccess}}
file would also be easy to set up (but if we ever expect to ship a ZIPed up
copy of the directory that people might open on their desktops, we'll
definitely want an {{index.html}} file there -- even if it's just a link to
{{apache-solr-reference-guide.adoc}})
> Decide online location for Ref Guide HTML pages
> -----------------------------------------------
>
> Key: SOLR-10295
> URL: https://issues.apache.org/jira/browse/SOLR-10295
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
> Reporter: Cassandra Targett
>
> One of the biggest decisions we need to make is where to put the new Solr Ref
> Guide. Confluence at least had the whole web-hosting bits figured out; we
> have to figure that out on our own.
> An obvious (maybe only to me) choice is to integrate the Ref Guide with the
> Solr Website. However, due to the size of the Solr Ref Guide (nearly 200
> pages), I believe trying to publish it solely with existing CMS tools will
> create problems similar to those described in the Lucene ReleaseTodo when it
> comes to publishing the Lucene/Solr javadocs (see
> https://wiki.apache.org/lucene-java/ReleaseTodo#Website_.2B-.3D_javadocs).
> A solution exists already, and it's what is done for the javadocs. From the
> above link:
> {quote}
> The solution: skip committing javadocs to the source tree, then staging, then
> publishing, and instead commit javadocs directly to the production tree.
> Ordinarily this would be problematic, because the CMS wants to keep the
> production tree in sync with the staging tree, so anything it finds in the
> production tree that's not in the staging tree gets nuked. However, the CMS
> has a built-in mechanism to allow exceptions to the
> keep-production-in-sync-with-staging rule: extpaths.txt.
> {quote}
> This solution (for those who don't know already) is to provide a static text
> file (extpaths.txt) that includes the javadoc paths that should be presented
> in production, but which won't exist in CMS staging environments. This way,
> we can publish HTML files directly to production and they will be preserved
> when the staging-production trees are synced.
> The rest of the process would be quite similar to what is documented in the
> ReleaseTodo in sections following the link above - use SVN to update the CMS
> production site and update extpaths.txt properly. We'd do this in the
> {{solr}} section of the CMS obviously, and not the {{lucene}} section.
> A drawback to this approach is that we won't have a staging area to view the
> Guide before publication. Files would be generated and go to production
> directly. We may want to put a process in place to give some additional
> confidence that things look right first (someone's people.apache.org
> directory? a pre-pub validation script that tests...something...?), and agree
> on what we'd be voting on when a vote to release comes up. However, the CMS
> is pretty much the only option that I can think of...other ideas are welcome
> if they might work.
> We also need to agree on URL paths that make sense, considering we'll have a
> new "site" for each major release - something like
> {{http://lucene.apache.org/solr/ref-guide/6_1}} might work? Other thoughts
> are welcome on this point also.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
