Skip to content

Render placeholders located in hyperlink URLs#650

Open
alranel wants to merge 1 commit into
elapouya:masterfrom
alranel:hyperlinks
Open

Render placeholders located in hyperlink URLs#650
alranel wants to merge 1 commit into
elapouya:masterfrom
alranel:hyperlinks

Conversation

@alranel

@alranel alranel commented Jun 25, 2026

Copy link
Copy Markdown

As of today, if you create a hyperlink in your docx template, placeholders such as {{ foo }} are rendered only in the visible text of the hyperlink but are ignored if placed in the destination URL.
With this simple PR, we'll render those templates even in the URL part making it fully customizable.

@xdong99

xdong99 commented Jun 27, 2026

Copy link
Copy Markdown

Thanks for the PR. I took a local pass through this because rendering relationship targets seems like the right place to fix hyperlink URLs.

What I checked locally on b98ff321d31bdeceff9c4f306374c1b701361afc:

  • ..\env\Scripts\python.exe hyperlink.py from tests/ passes once the usual tests/output/ directory exists.
  • ..\env\Scripts\python.exe -m flake8 docxtpl tests setup.py --count --max-line-length=127 --show-source --statistics passes.
  • I also ran the existing test scripts with the venv interpreter. Nothing looked attributable to this PR; the run did expose the pre-existing test-runner issue where module_execute.py can print a failed child command but still let the suite continue.

One edge case I found: when callers pass a custom jinja_env with custom delimiters, document XML is rendered with that environment, but hyperlink relationship targets are skipped because render_hyperlinks() and the new relationship scan in get_undeclared_template_variables() only look for the default Jinja markers {{, {%, and {#.

Minimal reproduction from the new fixture:

from jinja2 import Environment

env = Environment(variable_start_string="[[", variable_end_string="]]")
# relationship target is [[ foo ]]
# visible document text renders, but word/_rels/document.xml.rels still contains [[ foo ]]

For a relationship-only variable using those delimiters, get_undeclared_template_variables(jinja_env=env) also returns set().

A small way to keep this aligned with the provided environment would be to base the marker check on the active environment, for example using env.variable_start_string, env.block_start_string, and env.comment_start_string, then render/parse with that same env.

With that handled, this looks like a useful feature and the fixture is a good addition.

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.

2 participants