[
https://issues.apache.org/jira/browse/SOLR-13548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16868550#comment-16868550
]
Jan Høydahl edited comment on SOLR-13548 at 6/20/19 2:13 PM:
-------------------------------------------------------------
[~arafalov] I believe INFRA's migration tool takes care of not transferring
system pages, at least when inspecting the "Old Moin Wiki" node of
[https://cwiki.apache.org/confluence/display/LUCENE] there are no system pages
moved over.
On the Google rank issue, I also think that the reason the 6.6 guide ranks on
top is due to all of the existing links to the old Confluence refGuide which
now have delegated its authority to the 6.6 asciidoc guide. And as long as site
owners do not get 404 they will probably not see the needs to upgrade their
links, so this situation will stay until we remove those redirects :(
Don't know how to fix this. Crazy idea: What if we add a {{robots.txt}} for
lucene.apache.org
{code:java}
User-agent: *
Disallow: /solr/guide/6_6/{code}
After some time, Google will discard those pages from its index and a newer
version will surface on top, probably 8.x or some late 7.x depending on search
terms.
Ideally I'd like us to have a real copy of the refGuide at
[https://lucene.apache.org/solr/guide/latest/] instead of today a redirect that
will rewrite the URL to latest if you omit the X_Y part. It would still be
possible to permalink to a specific version of the guide, but if e.g.
[https://lucene.apache.org/solr/guide/latest/solrcloud.html] would contain to
8_1 guide right now, and then once 8_2 is released, we publish it to both the
"8_2" subfolder and the "latest" subfolder, and the rank authority of that
"latest" URL would then remain, and over time hopefully grow strong? It would
also make it way easier for people to link to the latest version if they do not
care about version.
We'd obviously need to sort out how to handle URL renames and deletions. Part
of the release process could perhaps be to generate a list of all pages in
existing "latest" and new guide to be released, and for every page that existed
in X_Y but not in newest X_Z, we'd add a redirect rule to X_Y for that specific
page, to make sure we don't break too many links on the "latest" guide.
was (Author: janhoy):
[~arafalov] I believe INFRA's migration tool takes care of not transferring
system pages, at least when inspecting the "Old Moin Wiki" node of
[https://cwiki.apache.org/confluence/display/LUCENE] there are no system pages
moved over.
On the Google rank issue, I also think that the reason the 6.6 guide ranks on
top is due to all of the existing links to the old Confluence refGuide which
now have delegated its authority to the 6.6 asciidoc guide. And as long as site
owners do not get 404 they will probably not see the needs to upgrade their
links, so this situation will stay until we remove those redirects :(
Don't know how to fix this. Crazy idea: What if we add a {{robots.txt}} for
lucene.apache.org
{code:java}
User-agent: *
Disallow: /solr/guide/6_6/{code}
After some time, Google will discard those pages from its index and a newer
version will surface on top, probably 8.x or some late 7.x depending on search
terms.
Ideally I'd like us to have a real copy of the refGuide at
[https://lucene.apache.org/solr/guide/latest/] instead of today a redirect that
will rewrite the URL. It would still be possible to permalink to a specific
version of the guide, but if e.g.
[https://lucene.apache.org/solr/guide/latest/solrcloud.html] linked to 8_1
guide right now, and then once 8_2 is released, we publish it to both the 8_2
subfolder and the latest subfolder, and the rank authority of that stable URL
would then stay, and over time hopefully grow strong. It would also make it way
easier for people to link to the latest version if they do not care about
version.
We'd obviously need to sort out how to handle URL renames and deletions. Part
of the release process could perhaps be to generate a list of all pages in
existing and new guide, and for every page that existed in X_Y but not in
newest X_Z, we'd add a redirect rule to X_Y for that specific page, to make
sure we don't break too many links on the "latest" guide.
> Migrate Solr's Moin wiki to Confluence
> --------------------------------------
>
> Key: SOLR-13548
> URL: https://issues.apache.org/jira/browse/SOLR-13548
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: website
> Reporter: Jan Høydahl
> Assignee: Jan Høydahl
> Priority: Major
> Attachments: SolrCwikiPages.txt, SolrMoinTitles.txt,
> create_dummy_confluence_pages.py
>
>
> We have a deadline end of June to migrate Moin wiki to Confluence.
> This Jira will track migration of Solr's [https://wiki.apache.org/solr/] over
> to [https://cwiki.apache.org/confluence/display/SOLR]
> The old Confluence space currently hosts the old Reference Guide for version
> 6.5 before we moved to asciidoc. This will be overwritten.
> Steps:
> # Delete all pages in current SOLR space
> ## Q: Can we do a bulk delete ourselves or do we need to ask INFRA?
> # The rules in {{.htaccess}} which redirects to the 6.6 guide will remain as
> is
> # Run the migration tool at
> [https://selfserve.apache.org|https://selfserve.apache.org/]
> # Add a clearly visible link from front page to the ref guide for people
> landing there for docs
> After migration we'll clean up and weed out what is not needed, and then
> start moving developer-centric content into the main git repo (which will be
> covered in other JIRAs)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
