Skip to content

Conversation

aG0aep6G
Copy link
Contributor

@aG0aep6G aG0aep6G commented Feb 9, 2015

Adding redirects so that the old URLs stay functional.

This is mostly moving pages, creating redirects, and updating links.
Non-bulk changes are:

  • dlang.org.ddoc: Changed GLINK2 to $(ROOT)/language/*. I'm assuming that
    GLINK2 is for links to /language/ pages only.
  • doc.ddoc: A bulk change on its own, but distinct from the others.
  • language/language.ddoc: New file used with /language/ pages.
  • posix.mak

I used HTML meta refresh for the redirects, because we use it already (e.g. appendices.html).

That technique has at least one major flaw: it loses the fragment/anchor/hash-thingy. E.g., http://dlang.org/appendices.html#copyright redirects to http://dlang.org/dstyle.html, losing the #copyright part.

I'd rather use HTTP 301 redirects, but I don't know how to go about it.
Do we have .htaccess and mod_rewrite?
Do we have PHP and would MultiViews load foo.html.php when foo.html is requested?


As a next step, I'm going to add a search box option for the language reference, when Google has indexed the new locations.

@CyberShadow
Copy link
Member

I'd rather use HTTP 301 redirects, but I don't know how to go about it.

I agree.

Do we have .htaccess and mod_rewrite?

No, but we should. I'll ask the system administrator to enable it.

Do we have PHP and would MultiViews load foo.html.php when foo.html is requested?

Yes: http://dlang.org/test/

But I don't like this solution. It requires two .php files to maintain compatibility with URLs with and without the .html extension (which are used in some places).

@CyberShadow
Copy link
Member

We now have .htaccess redirects!

The existing redirects should be migrated to those. We should also see if we have links to redirect pages in existing pages, and either fix those to point to the redirect targets, or leave the HTML meta redirects as is, so the redirects keep working without Apache.

@CyberShadow
Copy link
Member

Note: RewriteBase seems be required by the current server configuration for .htaccess redirects.

@andralex
Copy link
Member

andralex commented Feb 9, 2015

What is the motivation behind this? It looks like a lot of churn for a small benefit. Also, assuming this goes through, the redirect pages should be all generated with a macro.

@CyberShadow
Copy link
Member

Ideally, the redirect pages should be all replaced with a few lines in .htaccess.

@aG0aep6G
Copy link
Contributor Author

aG0aep6G commented Feb 9, 2015

We now have .htaccess redirects!

Sweet. Added a commit to use them. Not 100% sure about RewriteBase.

What is the motivation behind this?

The goal is an indepently searchable language reference. As discussed (a little) here: http://forum.dlang.org/post/mailman.5287.1422186138.9932.digitalmars-d@puremagic.com

@andralex
Copy link
Member

@ghost
Copy link

ghost commented Feb 12, 2015

What is the motivation behind this?

I think this will enable us to search the language spec via google (currently you can't limit searching only to the spec because all pages are in root apparently).

@CyberShadow
Copy link
Member

It looks like a lot of churn for a small benefit.

The benefit is small, but you might be overestimating the amount of "churn" as well. The redirects will make the move transparent to users.

@ghost
Copy link

ghost commented Feb 13, 2015

So, what's the status on this? And is my statement true about making things searchable? It would really be a welcome change.

@CyberShadow
Copy link
Member

Yes, it is true. I have attempted to construct a Google search that only searched the reference, and could not. Even if it is possible, it would require many search operators and filters.

@CyberShadow
Copy link
Member

@andralex If you don't find this pull request acceptable as it is now, we can only change the location of the generated .html files, without moving the .dd files. This should avoid most of the "churn" you speak of.

@ghost
Copy link

ghost commented Feb 13, 2015

It makes it even easier to edit these files if you know the language reference is in its own folder.

@MartinNowak
Copy link
Member

Sounds like we could achieve the searching using annotation files.
https://developers.google.com/custom-search/docs/annotations

@CyberShadow
Copy link
Member

Hmm, looks like those files still need to be uploaded manually every time they change, as opposed to auto-discovery like robots.txt or sitemap.xml (or even a parameter to the search widget)...

@CyberShadow
Copy link
Member

I just realized that we can implement this with only .htaccess changes. Make /language/ URLs redirect to non-/language/ locations internally, and non-/language/ URLs redirect to /language/ URLs using a HTTP redirect.

@CyberShadow
Copy link
Member

OK, not really, because of all the relative links to static resources, and because we can't rely on the .htaccess always being in effect (as it would prohibit testing offline).

@MartinNowak
Copy link
Member

Hmm, looks like those files still need to be uploaded manually every time they change, as opposed to auto-discovery like robots.txt or sitemap.xml (or even a parameter to the search widget)...

Where is the problem, you need to upload the updated pages as well. It's just a matter of generating them automatically.

@CyberShadow
Copy link
Member

You have to use a browser or write an API client, assuming one exists, and then there's the matter of Google account access. OTOH uploading dlang.org is one command.

@MartinNowak
Copy link
Member

I had much less trouble to support dlang.org/spec/template.html than dlang.org/language/template.html, which avoids to repeat "language" in the URL and is shorter.

@MartinNowak
Copy link
Member

as it would prohibit testing offline

We shouldn't break that.

@aG0aep6G
Copy link
Contributor Author

Sounds like we could achieve the searching using annotation files.
https://developers.google.com/custom-search/docs/annotations

If I get this right, that would mean updating the annotation files when a spec page is added/moved. I'd prefer a more automatic solution.

I had much less trouble to support dlang.org/spec/template.html than dlang.org/language/template.html, which avoids to repeat "language" in the URL and is shorter.

/spec/ would be fine with me. If there's consensus, I'll change things over.

@MartinNowak
Copy link
Member

We could reuse our .dpl_rewrite_map.txt file for the redirects. I think a separate search for the language specs is well worth the effort.

@CyberShadow
Copy link
Member

So should we go forward with this?

@andralex
Copy link
Member

I think we should, with the following ultimate purpose in mind: language reference should be accessible for specific versions of the language. For example, lexical is now http://dlang.org/lex.html. We should have http://dlang.org/reference/2.067/lex.html and so on for each version. http://dlang.org/lex.html redirects to the latest version.

That way people who work with a specific version of the language can see what the definition was at that release point.

@CyberShadow
Copy link
Member

Not sure we want a redirect, in most cases the intention is to link to the latest version of a page rather than a permalink to whatever version is latest at the time, so I think having the latest version at one location would be better. There's also the issue with search engine indexing that I mentioned before in regards to versioned Phobos docs.

How would this be achieved? Forward-porting DDoc files to the current layout and macros, or archiving old HTML files as they were built? Either way, given that this task is non-trivial, and given that we distribute documentation in a variety of formats with the compiler, I doubt that this will add enough value for the effort.

@CyberShadow
Copy link
Member

@aG0aep6G Anyway, if you want to update this we try an expedited merge. Last I looked I didn't see any technical issues with this PR.

@aG0aep6G aG0aep6G force-pushed the language-subdir branch 3 times, most recently from 9ee6aad to d940988 Compare November 22, 2015 15:46
@aG0aep6G
Copy link
Contributor Author

Updated. Still going with the /language/ URLs. If you guys prefer /spec/ or /reference/, please agree on one.

Regarding versioned variants of the spec/reference: I think /lex.html should be a legacy redirect to language/lex.html (as with this PR), and /language/lex.html should be a copy/alias of the newest versioned URL (but not a redirect). That scheme could be done on top of this PR.

@CyberShadow
Copy link
Member

make -f win32.mak chm gives:

Error: don't know how to make 'objc_interface.html'

Looks like the makefiles need to be updated due to #1129.

@aG0aep6G
Copy link
Contributor Author

Fixed win32.mak. Apparently I had missed some more files than just the new objc_interface.html.

@CyberShadow
Copy link
Member

Something is wrong.

The style, images etc. are broken on the moved pages in the doc autotester, however they look fine when I build them here on Windows.

Still, locally there are other issues with the generated docs, e.g. GLINK2 seems to be wrong from inside the language directory.

@aG0aep6G
Copy link
Contributor Author

Fixed GLINK2. But I'm at a loss as to why the autotester doesn't pick up the root path. I tried a clean clone; no problems.

@aG0aep6G
Copy link
Contributor Author

Figured it out. The order of rules in posix.mak matters. I think I had fallen in the same trap with the changelog subdir. Autotester displays properly now.

@CyberShadow
Copy link
Member

Could you add a comment to the makefile describing the issue to warn future contributors?

@CyberShadow
Copy link
Member

Even though there are the Apache redirects, we need to ensure this PR doesn't create broken links when not under Apache, for the CHM and offline HTML documentation. One example is the link to ../hash-map.html in arrays.dd. chmgen displays a list of broken links, but not their location, there is probably a better way to do this.

@aG0aep6G
Copy link
Contributor Author

Could you add a comment to the makefile describing the issue to warn future contributors?

Done.

we need to ensure this PR doesn't create broken links when not under Apache, for the CHM and offline HTML documentation.

I used the linkchecker command line tool and found a couple links that still needed updating. Will have to update some phobos pages, too. linkchecker also found some unrelated broken links, but those are for another pull request.

@CyberShadow
Copy link
Member

I see a few more broken links that look related to this PR:

Warning: Unknown page: attribute.html
Warning: Unknown page: contracts.html
Warning: Unknown page: cpp0x.html
Warning: Unknown page: expression.html
Warning: Unknown page: language/        contracts.html
Warning: Unknown page: language/phobos/core_attribute.html
Warning: Unknown page: language/phobos/object.html
Warning: Unknown page: property.html
Warning: Unknown page: type.html
Warning: Unknown page: version.html

@aG0aep6G
Copy link
Contributor Author

Warning: Unknown page: cpp0x.html

cpp0x.html is not being built (not changed in this PR). So that's expected.

Warning: Unknown page: language/ contracts.html

Changed the only spot I could find that could end up with that.

Warning: Unknown page: language/phobos/core_attribute.html
Warning: Unknown page: language/phobos/object.html

Fixed.

Otherwise, I can't find these links, except from phobos. These are from the .chm file and that includes phobos, right?

Should I make phobos/druntime PRs so that we can test everything together?

@CyberShadow
Copy link
Member

Otherwise, I can't find these links, except from phobos. These are from the .chm file and that includes phobos, right?

Yep.

Should I make phobos/druntime PRs so that we can test everything together?

Yes, and ideally they should be merged simultaneously too.

@aG0aep6G
Copy link
Contributor Author

Yes, and ideally they should be merged simultaneously too.

Ok, that'll have to wait until tomorrow, though.

Maybe we can decide on a name for the directory until then. Ping @MartinNowak @andralex: Which one shall it be, /language/, /spec/, or /reference/?

@andralex
Copy link
Member

I'm preapproving this as a step in a good direction. @CyberShadow please take over the merging process once your concerns are addressed.

FWIW I personally have a mild preference for /spec/ over /language/ but out of respect I'll leave it to the folks involved in the work.

Adding redirects so that the old URLs stay functional.

Links to the moved pages are updated in a separate commit.
Assuming that dlang.org.ddoc's GLINK2 macro is for links to language
reference pages only.
@aG0aep6G
Copy link
Contributor Author

Changed to /spec/, squashed down to two commits, made companion PRs:

@aG0aep6G
Copy link
Contributor Author

@CyberShadow: I just noticed your PR against my branch. After a little git adventure, I think I managed to include it properly.

@CyberShadow
Copy link
Member

Thanks, will have a look again tomorrow :)

@aG0aep6G aG0aep6G changed the title move "D Reference" pages to /language/ move "D Reference" pages to /spec/ Nov 24, 2015
@CyberShadow
Copy link
Member

Alright, Let's Do This.

CyberShadow added a commit that referenced this pull request Nov 25, 2015
move "D Reference" pages to /spec/
@CyberShadow CyberShadow merged commit c1da655 into dlang:master Nov 25, 2015
@CyberShadow
Copy link
Member

I guess we can now add the search option in the dropdown?

@aG0aep6G
Copy link
Contributor Author

aG0aep6G commented Dec 1, 2015

I guess we can now add the search option in the dropdown?

I'm waiting for google to pick up the new locations. So far it seems to have only found some of the pages: https://www.google.de/search?q=site%3Adlang.org%2Fspec

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants