Hoss Man commented on SOLR-10595:

bq. Note the rest of my sentence that you quoted from: "...which do not 
redirect to a particular version but stays on that URL"
bq. If we redirect confluence to this redirect that in turn redirects to 6_6 
then the PageRank of a page will not be permanently transferred to a stable URL 
in the new guide but to a moving target..

The existing {{/guide/foo -> /guide/X_Y/foo}} redirects are 302(temporary) 
redirects, so in theory any bookmark/link/301(permanenant) redirect to 
{{/guide/foo}} _should_ maintain the existing PageRank/goodness/history of the 
original page, even if {{/guide/foo}} then ultimately does a 302(temporary) 
redirect to some other {{/guide/X_Y/foo}}

(If folks really wnat to go further and have {{/guide/latest/foo}} URLs that 
serve up content w/o a redirect that should probably be discussed in it's own 
broader scope jira along with doing the same for javadocs ... IIRC that idea -- 
for jdocs -- was proposed in the past and deemed confusing for folks who try to 
bookmark the docs for the "current" release they are using, and then come back 
later and the same url they bookmarked before now talks about code newer then 
what they are using)

But frankly: regardless of wether a "latest" URL redirects or does a server 
side rewrite, I think having the cwiki redirects go to version-less URLs is a 
bad idea.  If you asked me 5 months ago i would have been on board, but the 
switch to asciidoc has already started facilitating/motivating people to 
discuss ideas about how to revamp and re-organize the content into new pages 
(with new URLs) now that it's so much easier to edit, and I'm concerend that 
having {{cwiki->/guide/latest}} redirects will be harmful in the long run as 
the content on those pages change and/or pages get renamed, moved, etc....

I think in the long term it's better for our users to (301-permenantly) 
redirect the cwiki URLs to {{guide/6_6}} since that's what those cwiki pages -- 
at the moment they were last in use -- most directly map to content wise.

If we're going to worry about people with "old" bookmarks/links finding "old" 
versions of pages, we should wory about that and care about it just as 
much/more with the existing {{/guide/X_Y}} URLs moving forward (as new versions 
get released) as we might care about _legacy_ {{cwiki.apache.org}} urls -- and 
solve that type or probably independently (possible with a javascript+css info 
box or something like that in the hosted HTML pages?)

For the same reasons/concerns, I no longer think my original suggestion of a 
"two layer" redirect is a good idea -- depending on how we might implement the 
{{cwiki.apache.org/.* -> /guide/old/.*}} URLs (301 vs 302) and likewise how 
(301 vs 302) we might do the {{/guide/old/.* -> /guide/X_Y}} (or 
{{/guide/old/.* -> /guide/latest}}) i feel like things could get really 
complicated/confusing/bad in terms of what URLs google displays in results, how 
bookmarks get updated, etc...


I think the next step should be to file an INFRA jira requesting new redirects 
added on cwiki.apache.org that 301 redirect the old cwiki page names/numbers 
directly to the {{lucene.apache.org/solr/guide/6_6/}} equivilent URLs, and work 
with infra to provide the redirect rules in whatever format they prefer (list 
of RewriteRules, DB mapping file, etc...) in the aim of redirecting as many URL 
variants as reasonably possible.

Example: both of these URLs below should redirect to 

* https://cwiki.apache.org/confluence/display/solr/Function+Queries
* https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=32604260

If there are no objections in the next day or two, i'll follow up with infra on 
how to proceed.

> Redirect Confluence pages to new HTML Guide
> -------------------------------------------
>                 Key: SOLR-10595
>                 URL: https://issues.apache.org/jira/browse/SOLR-10595
>             Project: Solr
>          Issue Type: Sub-task
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: documentation
>            Reporter: Cassandra Targett
>         Attachments: new-page-urls.txt, page-tree.xml
> Once the new Ref Guide is live, we may want to redirect pages from Confluence 
> to the new HTML version. 
> I'm undecided if this is the best idea, I can see pros and cons to it. On the 
> pro side, I think it helps firmly establish the move away from Confluence and 
> helps users adjust to the new location. But I could see the argument that 
> redirecting is overly invasive or unnecessary and we should just add a big 
> warning to the page instead.
> At any rate, if we do decide to do it, I found some Javascript we could tell 
> Confluence to add to the HEAD of each page to auto-redirect. With some 
> probably simple modifications to it, we could get people to the right page in 
> the HTML site: 
> https://community.atlassian.com/t5/Confluence-questions/How-to-apply-redirection-on-all-pages-on-a-space/qaq-p/229949

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to