Currently, when using %baseurl, this is substituted with the host-relative base URL.
While this works neatly with pages when displayed in a normal HTML page context on the original site, it breaks when used with RSS agregations, and other forms of content aggregation. It would therefore be useful to be able to have the module optionally output fully absolute URLs, include the host part.
The suggest patch adds this optional behaviour, and a setting to enable it. It is disabled by default to maintain consistency with previous versions.
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | README.txt.patch | 2.23 KB | fgm |
| #4 | url_replace_filter-1.patch | 3.39 KB | fgm |
| url_replace_filter.patch | 3.21 KB | fgm |
Comments
Comment #1
David Lesieur commentedGood point... In fact, does it make any sense to maintain the current behavior? Given the problems it can cause and that you have pointed out, I doubt anyone would want it.
Comment #2
fgmActually, I suppose that not everyone wants his content to be aggregatable (?), and emitting full absolute URLs also has a slight bandwidth and readability cost above normal site-relative URLs. So I think it makes sense to keep your default behaviour as it currently is.
Comment #3
David Lesieur commentedThen how about adding a new token such as %baseurl-absolute instead of creating a new setting? That would allow more fine-grained configuration. I also think it would give the option more visibility than having it as a setting on a separate page.
It would also be useful to explain why one would choose absolute rather than relative, perhaps a statement like: "Some content aggregators might not be able to reference elements with relative URLs".
Comment #4
fgmHere is the module patched as suggested. I also included a README change mentioning both the new token and the uninstall procedure.
The .install file for uninstall can't be included in the patch since it does not yet exist. See http://drupal.org/node/255332 for its contents.
Comment #5
David Lesieur commentedI have not tested the patch, but it looks good. I have granted you CVS access to the module, if you have tested the patch thoroughly and would like to commit it yourself. ;)
My only suggestion would be for the readme file to mention that some aggregators may have problems with relative URLs.
An aggregating site that would republish relative URLs as-is would just be a buggy one. AFAIK, Drupal's core aggregator, FeedAPI or SimpleFeed modules do not have such problems.
Thanks!
Comment #6
fgmWell, technically, the item content in RSS 0.9x and 2.0 feeds is not supposed to be an HTML fragment. Its format is just undefined, so "by the book" it is not broken : the RSS 0.91 considers the "item" content may be HTML, but does not suppose it is, with mentions like
See http://backend.userland.com/stories/rss091 and http://cyber.law.harvard.edu/rss/rss.html for the full RSS 0.91 and 2.0 specifications. RSS 1.0 and Atom are a different story, though.
This being said, for most practical purposes today, the item content is an encoded HTML fragment, so aggregators should probably parse links, and I reworded the README in this new patch. Do you think this is better ?
Comment #7
David Lesieur commentedThe new README looks good to me. Thanks for the change!
Thanks also for the clarification regarding RSS.
Comment #8
fgmSo do you think we can commit this ? (set RTBC if applicable).
Since there are no other pending issues, it could be an occasion to make a new release: the previous one is almost one year old.
Comment #9
fgmBumping request: we could also apply it to the new 6.x branch.
Comment #10
David Lesieur commentedI agree with the idea. Haven't set the patch to RTBC because I haven't tested it, but feel free to commit it if you have tested it thoroughly and think it is ready. Thanks!
Comment #11
fgmIt's now 8.x time, and this module is not needed on 8.x, so won't fix.