Opened 2 years ago

Last modified 3 months ago

#5557 new change

Support link processing (especially localization) in <meta> tags [CMS]

Reported by: kvas Assignee:
Priority: Unknown Milestone:
Module: Sitescripts Keywords: goodfirstbug
Cc: juliandoucette Blocked By:
Blocking: Platform: Unknown / Cross platform
Ready: no Confidential: no
Tester: Unknown Verified working: no
Review URL(s):

Description (last modified by kvas)

Background

CMS localizes links in <a> and <img> tags, but not in <meta> tags. We would like content attribute of <meta> tags to undergo the same processing as a.href and img.src (see this review comment for more context).

What to change

Add a regexp for <meta> tags to converters.py:Converter.process_links so that the links in meta.content attributes would undergo the same processing as a.href and img.src.

Change History (5)

comment:1 Changed 2 years ago by kvas

  • Keywords goodfirstbug added

comment:2 Changed 2 years ago by kvas

  • Description modified (diff)
  • Summary changed from Support link processing (in particular localization) in <meta> tags [CMS] to Support link processing (especially localization) in <meta> tags [CMS]

comment:3 Changed 2 years ago by juliandoucette

There is one small/important difference. a.href and img.src can be (are currently) relative URLs. meta.content must be absolute URLs.

comment:4 Changed 2 years ago by kvas

Yes, this is an important difference. With existing logic it's not possible to generate absolute URLs without setting siteurl in the config. I see three options for dealing with this:

  1. Make website generation fail if we're trying to process meta.content without siteurl configured. This is the most reliable option in terms of output correctness, but it might cause some existing websites to stop generating until we update their configs.
  2. Implement a default value for siteurl, for example http://localhost/. Nothing will fail, but the URLs in <meta> tags might end up pointing to localhost.
  3. Don't process meta.content URLs unless siteurl is set (maybe display a warning). Existing websites without siteurl will work the same as before (and maybe display a warning). Existing websites that have siteurl will work better than before (for some definition of better).

I don't really like any of these options but my least favorite is 2, because of the possibility to silently generate broken URLs. Do you have any better ideas or does any of these options look acceptable to you?

comment:5 Changed 3 months ago by kvas

Dear stakeholders of this ticket,

I'm cleaning up Sitescripts tickets in Trac due to its phase out. This is one of the tickets that I could not myself close or move, so I need your input on it.

Please let me know if this ticket is still relevant for you and we can then discuss where it should be moved. If you think that this ticket is no longer relevant, you can write a comment explaining this or just ignore this message.

If I see now comments in the ticket on October 14, I will close it as rejected.

Best regards,
Vasily

Note: See TracTickets for help on using tickets.