-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Relative urls not checked #8
Comments
We do something a little similar with anchors. Maybe we could store a display URL as well as the URL to actually check? |
So then you would add a new field in Url class? And in utils.py/update_urls, we'd have to detect relative urls to handle them similarly as anchors. |
Alternatively we could calculate the 'display_url' on the fly where needed? Less performant but possibly more flexible and we won't need a migration. |
I don't see how you would calculate display_url on the fly, when for example a "../parentdir" relative link was transformed to "/absolute/parentdir". I understand however you try to prevent migrations as much as possible. |
Doh! I've just seen the flaw in my own reasoning. We have no idea whether a link was absolute or relative so even if we can convert it (by referring to the absolute url of the containing instance) we don't know whether we should display it as relative or absolute. So every Link object would need to store a is_relative flag. And if we do that then we might as well simply store the original form of the url so we can display it correctly. In that case I wonder if we should do the same with same page anchors for the sake of consistency (and simplicity - we could remove some of the logic around anchor display). |
Sure, storing the original url each time it is different from the url field makes sense. |
This isn't top priority for me right now so if you find yourself with some time then go ahead and have a go at it :) |
Currently, if you have a relative URL (a href="subpage"), it is marked as Invalid URL.
As such URLs can be valid in one Link context, and not in another, it is not easy to resolve this issue with the current model. One possibility would be to recreate the absolute link when links are harvested in content. The downside is that the shown URL in the report would not equal the real URL in the content. What do you think?
The text was updated successfully, but these errors were encountered: