zulip/templates/zerver/documentation_main.html

62 lines
2.8 KiB
HTML
Raw Normal View History

{% extends "zerver/portico-help.html" %}
{% set entrypoint = "help" %}
{# Zulip user and API documentation. #}
{% block title %}
<title>{{ PAGE_TITLE }}</title>
{% endblock %}
{% block portico_content %}
<div class="app help terms-page inline-block{% if page_is_help_center %} help-center{% endif %}{% if page_is_api_center %} api-center{% endif %}">
<div class="sidebar">
<div class="content">
{% if not page_is_policy_center %}
<h1><a href="https://zulip.com" class="no-underline">Zulip homepage</a></h1>
<h1><a href="{{ doc_root }}" class="no-underline">{{ doc_root_title }} home</a></h1>
{% endif %}
{% if page_is_policy_center %}
markdown: Fix use of pure_markdown for non-pure markdown rendering. `render_markdown_path` renders Markdown, and also (since baff121115a1) runs Jinja2 on the resulting HTML. The `pure_markdown` flag was added in 0a99fa2fd669, and did two things: retried the path directly in the filesystem if it wasn't found by the Jinja2 resolver, and also skipped the subsequent Jinja2 templating step (regardless of where the content was found). In this context, the name `pure_markdown` made some sense. The only two callsites were the TOS and privacy policy renders, which might have had user-supplied arbitrary paths, and we wished to handle absolute paths in addition to ones inside `templates/`. Unfortunately, the follow-up of 01bd55bbcbf7 did not refactor the logic -- it changed it, by making `pure_markdown` only do the former of the two behaviors. Passing `pure_markdown=True` after that commit still caused it to always run Jinja2, but allowed it to look elsewhere in the filesystem. This set the stage for calls, such as the one introduced in dedea237456b, which passed both a context for Jinja2, as well as `pure_markdown=True` implying that Jinja2 was not to be used. Split the two previous behaviors of the `pure_markdown` flag, and use pre-existing data to control them, rather than an explicit flag. For handling policy information which is stored at an absolute path outside of the template root, we switch to using the template search path if and only if the path is relative. This also closes the potential inconsistency based on CWD when `pure_markdown=True` was passed and the path was relative, not absolute. Decide whether to run Jinja2 based on if a context is passed in at all. This restores the behavior in the initial 0a99fa2fd669 where a call to `rendar_markdown_path` could be made to just render markdown, and not some other unmentioned and unrelated templating language as well.
2023-03-10 02:47:44 +01:00
{{ render_markdown_path(sidebar_index) }}
{% elif page_is_help_center %}
markdown: Fix use of pure_markdown for non-pure markdown rendering. `render_markdown_path` renders Markdown, and also (since baff121115a1) runs Jinja2 on the resulting HTML. The `pure_markdown` flag was added in 0a99fa2fd669, and did two things: retried the path directly in the filesystem if it wasn't found by the Jinja2 resolver, and also skipped the subsequent Jinja2 templating step (regardless of where the content was found). In this context, the name `pure_markdown` made some sense. The only two callsites were the TOS and privacy policy renders, which might have had user-supplied arbitrary paths, and we wished to handle absolute paths in addition to ones inside `templates/`. Unfortunately, the follow-up of 01bd55bbcbf7 did not refactor the logic -- it changed it, by making `pure_markdown` only do the former of the two behaviors. Passing `pure_markdown=True` after that commit still caused it to always run Jinja2, but allowed it to look elsewhere in the filesystem. This set the stage for calls, such as the one introduced in dedea237456b, which passed both a context for Jinja2, as well as `pure_markdown=True` implying that Jinja2 was not to be used. Split the two previous behaviors of the `pure_markdown` flag, and use pre-existing data to control them, rather than an explicit flag. For handling policy information which is stored at an absolute path outside of the template root, we switch to using the template search path if and only if the path is relative. This also closes the potential inconsistency based on CWD when `pure_markdown=True` was passed and the path was relative, not absolute. Decide whether to run Jinja2 based on if a context is passed in at all. This restores the behavior in the initial 0a99fa2fd669 where a call to `rendar_markdown_path` could be made to just render markdown, and not some other unmentioned and unrelated templating language as well.
2023-03-10 02:47:44 +01:00
{{ render_markdown_path(sidebar_index) }}
{% else %}
{{ render_markdown_path(sidebar_index, context=api_url_context) }}
{% endif %}
{% if not page_is_policy_center %}
<h1 class="home-link"><a href="/" class="no-underline">Back to Zulip</a></h1>
{% endif %}
</div>
</div>
<svg height="32px" class="hamburger" style="enable-background:new 0 0 32 32;" version="1.1" viewBox="0 0 32 32" width="32px" xml:space="preserve" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
<path d="M4,10h24c1.104,0,2-0.896,2-2s-0.896-2-2-2H4C2.896,6,2,6.896,2,8S2.896,10,4,10z M28,14H4c-1.104,0-2,0.896-2,2 s0.896,2,2,2h24c1.104,0,2-0.896,2-2S29.104,14,28,14z M28,22H4c-1.104,0-2,0.896-2,2s0.896,2,2,2h24c1.104,0,2-0.896,2-2 S29.104,22,28,22z"></path>
</svg>
<div class="markdown">
<div class="content">
{% if page_is_policy_center %}
markdown: Fix use of pure_markdown for non-pure markdown rendering. `render_markdown_path` renders Markdown, and also (since baff121115a1) runs Jinja2 on the resulting HTML. The `pure_markdown` flag was added in 0a99fa2fd669, and did two things: retried the path directly in the filesystem if it wasn't found by the Jinja2 resolver, and also skipped the subsequent Jinja2 templating step (regardless of where the content was found). In this context, the name `pure_markdown` made some sense. The only two callsites were the TOS and privacy policy renders, which might have had user-supplied arbitrary paths, and we wished to handle absolute paths in addition to ones inside `templates/`. Unfortunately, the follow-up of 01bd55bbcbf7 did not refactor the logic -- it changed it, by making `pure_markdown` only do the former of the two behaviors. Passing `pure_markdown=True` after that commit still caused it to always run Jinja2, but allowed it to look elsewhere in the filesystem. This set the stage for calls, such as the one introduced in dedea237456b, which passed both a context for Jinja2, as well as `pure_markdown=True` implying that Jinja2 was not to be used. Split the two previous behaviors of the `pure_markdown` flag, and use pre-existing data to control them, rather than an explicit flag. For handling policy information which is stored at an absolute path outside of the template root, we switch to using the template search path if and only if the path is relative. This also closes the potential inconsistency based on CWD when `pure_markdown=True` was passed and the path was relative, not absolute. Decide whether to run Jinja2 based on if a context is passed in at all. This restores the behavior in the initial 0a99fa2fd669 where a call to `rendar_markdown_path` could be made to just render markdown, and not some other unmentioned and unrelated templating language as well.
2023-03-10 02:47:44 +01:00
{{ render_markdown_path(article) }}
{% elif page_is_help_center %}
{{ render_markdown_path(article, context=api_url_context, help_center=True) }}
{% else %}
{{ render_markdown_path(article, context=api_url_context) }}
{% endif %}
<div class="documentation-footer">
<hr />
{% if corporate_enabled %}
{% if page_is_policy_center %}
<p>Please contact {{ support_email_html_tag }} with any questions about Zulip's policies.</p>
{% else %}
<p>Your feedback helps us make Zulip better for everyone! Please <a href="mailto:{{ support_email }}">contact us</a> with questions, suggestions, and feature requests.</p>
{% endif %}
{% else %}
<p>Don't see an answer to your question? <a href="mailto:{{ support_email }}">Contact this Zulip server's administrators</a> for support.</p>
{% endif %}
</div>
</div>
</div>
</div>
{% endblock %}