Many pages contain absolute links with fsfe.org #1378
레이블
레이블 없음
bug
build
cgi Scripting
design
disruptive
documentation
duplicate
easy
feature-request
help wanted
javascript
priority/low
question
system-hackers
tagging
text
translations
wait/bugfix
wait/inprogress
wait/misc
wait/proofread
wontfix
xsl
마일스톤 없음
담당자 없음
참여자 4명
알림
마감일
마감일이 설정되지 않았습니다.
의존성
No dependencies set.
Reference: FSFE/fsfe-website#1378
불러오는 중...
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Even though it has always been the rule that links within fsfe.org should be relative, there are many many links written as absolute links - some pointing to https://fsfe.org, some to http://fsfe.org, some to http://www.fsfe.org/, and some even to www.fsfeurope.org.
Unfortunately I don't think that this can be fixed with a global search and replace, because there might be occasions where an URL is written in a text, purposedly including the servername (but potentially having to be updated from a former version to https://fsfe.org).
To avoid misunderstandings: it's about whether the link should contain protocol and server ("https://fsfe.org"), not whether the path is absolute or relative. So a link to "/foo/bar.html" is perfectly okay, but "https://fsfe.org/foo/bar.html" should be changed into "/foo/bar.html".
Yes, far too many for my taste. Unfortunately, during editing news items or so in a collaborative text editor, I can see the point of using absolute links: a proofreader or editor can immediately click on the link to check whether it works or how it looks like (and if it makes sense). The truncated links are harder to check.
So while I agree that using protocol+server is bad style, I wonder how we can assure that with the next news item the problem will be reintroduces.
Why is that? Using a regex, or some XSL tooling, we could explicitely search for href attributes to not update the content itself.
I am tempted to answer this concern by adding a dependency on #138 to this issue :-) so we would have our own tool to turn markup into HTML. But I guess that's a long way until we're there.
Until then, I guess we could make things already a lot better by removing at least the old versions like www.fsfeuropr.org or www.fsfe.org or the ones without https.
Yes, you're right, something like
s;href="http://www.fsfeurope.org;href=";gshould actually do the trick.OK, let's start with the cleanup first, and then think of long-term solutions later.
#138 is of course yet another heavy change which would influence the workflow of editors, so the links may be part of that step.
I've submitted a pull request with a cleanup. We should probably expand the webhooks to warn for absolute URLs.
Thank you @nico.rikken! This is an important first step. Of course we shall not forget about the other variants like http (without "s"), www.fsfe.org, or www.fsfeurope.org.
Indeed, so various permutations:
As the pull request #1383 focusess on
href="https://fsfe.org/it replaces the bulk. Afterwards I can open up pull-requests for the rest.I was wearry of replacing the campaigns pages, assuming they were also published under a seperate url like https://pdfreaders.org/ . But reading further I get the impression that is not the case. Can ALL xhtml and html pages, and XML events be replaced to absolute URls?
You were absolutely right not doing the replacements in the pdfreaders and drm.info directories, since they are indeed published under different URLs.
I just created the pull request to solve this issue.
What to do with pdfreaders and drm.info ? I can check and correct the URLs to be
https://fsfe.orgstyle.Looks very good to me, I just merged it.
That would be excellent, thank you!
Check: #1424
I noticed that there are still some things to be replaced:
No links:
Mailman links:
edit: Addressed by #1425 - merged
Link names (not the actual hyperlink):
edit: Addressed by #1431 - pending
Codified email addresses:
More specific URLs:
Files:
edit: Addressed by #1429 - pending
Other links:
Links in tables?:
Links in events pages:
edit: Addressed by #1431 - pending
I've created PR #1425 to solve the mailman links. Which actually solves a lot of broken links 🎉😃
I'm looking into links back to the homepage, like
<a href="http://fsfe.org">. I can change it to<a href="https://fsfe.org">or<a href="/">. Of course the latter is no option for the drm.info and pdfreaders sections. Personally I prefer te"/"option. What do you think?edit: I created #1428 to address this - merged
I also noticed some links to the
test.fsfe.orgdomain.edit: the test URLs seems to be correct.
And in #1424 the suggestion came up to convert major website links to
https://(likewikipedia.org)Thank you so much for fixing all this step by step, I consider this a huge improvement for our whole website!
I absolutely agree! I merged your pull request.
Oh, wow. Some of them might be intentional (explaining that there is the test instance of the website), but where this obviuosly is not the case, it should also be changed.
I wouldn't worry too much about these. We could probably spend hours every month to update external links that have changed...
Does it make sense to include some of these improvements into the automated build or testing process? The relevant links I can think of now:
http, alwayshttpsfsfe.orgare relative, not absoluteOther improvements related to this issue seem of a temporary nature. So once the fixes are in master, problems like
fsfeurope.orgdomains and Mailman links are unlikely to return.Depending on how the current CI/CD setup works, the URLs could also be changed automatically on a merge request, or be modified when building the website for publising.
I think the best way to handle this would be in the pre-commit hook.
@max.mehl what do you think?
A point I'd like some feedback on:
There are plenty of links to the old fellowship pages:
<a href="http://fellowship.fsfe.org/">. Looking for non-https links they stand out. But in practice they result in a 404 error. Should I update these to behttps://or leave them as they are?@mk @max.mehl what do you think about how to handle links to fellowship.fsfe.org?
@nico.rikken do you have a list of what links that are? Maybe it makes more sense to update those links to point to fsfe.org/donate or to fsfe.org/contribute or maybe other parts.
@mk The link variants are limited:
It seems that all links are broken.
Thinking a bout it now, it seems as odd to land on a 404 error, as randomly ending up on a totally different page. Perhaps we need a simple redirect page that briefly explains that the fellowship is no longer, and there is still the option of supporting the FSFE through donations. It could include a link to the donation page. That would smooth the transition in case people click on an old link. Then again, just having the donation page might suffice. Looking through the link context briefly, a lot refer to donations directly, some also to membership.
I was looking for the fellowship interview of Georg Greve in archive.org, and found that even in 2009 this was handled using a redirect to the blogs.fsfe.org interview (see attached image).
So I suggest that we update those links to the new URL of the Greve interview: https://blogs.fsfe.org/fellowship-interviews/?p=27
Thanks @nico.rikken
Those can both be forwarded to https://fsfe.org/donate
Maybe this one can be forwarded to https://wiki.fsfe.org/TechDocs/CardHowtos or also just to the /donate.
They could both https://fsfe.org/contact
IMHO they can be removed. (Now we have something similar, but this is internal docu https://wiki.fsfe.org/KnowHow/FSFELife/VolunteerAccountCreation )
See above: /donate
See below, I agree with forwarding it to blogs.fsfe.org, but maybe it is even better to just directly change the link on our pages to the correct link.
https://fsfe.org/news/
https://fsfe.org/news/news.en.rss
Both again to /donate/
Not a big fan of adding a new page to explain this. I would just use the /donate page as you said. Plus for some minor pages we could add forwardings or directly change the links in our pages (see the Fellowship interview).
Thank you!
I would suggest to change the links instead of forwarding.
Also, I would suggest https://my.fsfe.org/donate instead of https://fsfe.org/donate.
Third, if you change the links, please link to a file (e.g. https://fsfe.org/contact/index.html) instead of a directory (like https://fsfe.org/contact/), so the build script will automatically insert the correct language into the link.
@mk thanks, I've almost got that replacement scripted, so I can open a merge request.
I noticed a link where the link text was still the fellowship.fsfe.org domain, but was actually linking to the donation page:
Do you want me to update the link texts as well in case they specify the URL?
In the case above, that would result in:
Since @mk is on vacation for the next 2 weeks, I dare to say that it makes more sense to also change the link text, so let's do it that way.
I agree to this approach, thanks @nico.rikken!
Regarding the pre-commit hook: I do not think that we need to check for http:// in fsfe.org domains, I didn't see them in a long time. For relative links, I can include a check in the pre-commit commit routine that looks for
https?://fsfe(urope)?.org. However, if a match is found, I would not abort it because some subsites, e.g. DRM or pdfreaders, do require an absolute URL. So this would be a warning, just like some other checks.Would that be OK for you?
@reinhard
Regarding the fellowship replacement:
Currently there are different links:
https://my.fsfe.org/donate/donate/donate/donate/donate.html/donate/donate.en.htmlWhich should I default to? To me
/donate/donateor/donate/donate.htmlseem to make most sense, rather than directly referring to a subdomain. But I'm missing context here, so I hope you can fill me in.Also, can I drop the language-specific links in the search-replace action? For example a Dutch (nl) translation contains a link to the English contact page. Can I drop it like so: ?
https://my.fsfe.org/donate, this is where most other "donate" or "become a supporter" links already point to as well.
/donate/donate.htmlwas a page where one could choose whether to donate one-time or become a supporter, and then be forwarded to different forms. We now have a single form for both purposes, so the step in between is not necessary any more./donate/donate.htmlnow forwards to https://my.fsfe.org/donate anyway.Yes, exactly.
I'd like to remove the
fsfeurope.orgemail adresses as well. Can I just convert the@fsfeurope.orgdomain to@fsfe.org, or should it be changed to@lists.fsfe.org?Some e-mail adresses that are linked directly:
Some adresses are constructed like
team at fsfe.org,team @ fsfe.organd similar. I can update those later.Ah, this is a tricky one. Here the better addresses one by one:
Why so many contact@? The ticket system has been introduces just a few years back, and since then we can easily dispatch requests to the respective teams.
Also: rather than using the email addresses directly, would it make more sense to link to fsfe.org/contact instead of contact@fsfe.org?
@max.mehl I like your proposal to refer to the contact page. That would require a more manual replacement, but I'll have a look at it.
@max.mehl some additional email adresses I found, in different formatting:
Can you please provide a similar set of alternative addresses?
Ah sure!
can we remove the deprecated private addresses altogether? Otherwise, contact@fsfe.org or /contact would work.
I noticed
http://links in other files, like.svg,.xsl,.php,.pland.txt. I'll take a look at those as well.@nico.rikken, you touched so many files and improved so many bits that I lost oversight (which is a good sign, so thanks a bunch!). Do you think we've fixed all of them now, or are there still open issues?
I think we've fixed all of them meanwhile, and a pre-commit hook is in place to detect those links. Whoop whoop!