Mirror
/
zulip
mirror of https://github.com/zulip/zulip.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
zulip/templates/zerver/documentation_main.html

62 lines
2.8 KiB
HTML
Raw Normal View History

help: Redesign /help/ pages to be a single page app. This redesigns the /help/ page sets to be a single page app that uses history.pushState to work the same as the old app. The big new feature is that now we have the index in a nicely designed left sidebar.
2017-07-10 20:50:11 +02:00
{% extends "zerver/portico-help.html" %}
templates: Use just one webpack entry point per page. Signed-off-by: Anders Kaseorg <anders@zulipchat.com>
2019-10-23 07:46:34 +02:00
{% set entrypoint = "help" %}
docs: Add a simple markdown-based help center. The plan is to use this for adding user documentation to Zulip.
2016-11-09 01:45:36 +01:00
docs: Fix more capitalization issues. Signed-off-by: Anders Kaseorg <anders@zulip.com>
2020-10-23 02:43:28 +02:00
{# Zulip user and API documentation. #}
docs: Set <title> to article title. Previously the title for all pages of the user and API documentation was just "Zulip", which does not only bad for UX but also for accessibility. We were already extracting the title from the Markdown for the og:title tag, so we just need to set the <title> tag. Since our documentation fetches pages with Ajax if you have JavaScript enabled, we also need to save the titles in the article cache. Part of #15948.
2020-07-29 07:44:08 +02:00
{% block title %}
templates: Rename `OPEN_GRAPH` variables to `PAGE` or `PAGE_METADATA`. Renames existing template variables starting with `OPEN_GRAPH` to be either `PAGE` or `PAGE_METADATA` since these variables are used for adding both open graph metdata and page titles/descriptions for SEO.
2022-09-05 16:12:21 +02:00
<title>{{ PAGE_TITLE }}</title>
docs: Set <title> to article title. Previously the title for all pages of the user and API documentation was just "Zulip", which does not only bad for UX but also for accessibility. We were already extracting the title from the Markdown for the og:title tag, so we just need to set the <title> tag. Since our documentation fetches pages with Ajax if you have JavaScript enabled, we also need to save the titles in the article cache. Part of #15948.
2020-07-29 07:44:08 +02:00
{% endblock %}
docs: Add a simple markdown-based help center. The plan is to use this for adding user documentation to Zulip.
2016-11-09 01:45:36 +01:00
{% block portico_content %}
help: Add CSS class to distinguish /api/* from /help/*.
2019-02-08 21:47:41 +01:00
<div class="app help terms-page inline-block{% if page_is_help_center %} help-center{% endif %}{% if page_is_api_center %} api-center{% endif %}">
help: Stop collapsing sidebar sections. Three reasons: 1. The sliding was disorienting. 2. The collapsing disallowed searching for other pages with Ctrl+F. 3. The collapsing mechanism wasn't accessible (not usable with the keyboard / no ARIA tags). Tweaked by tabbott to center the left sidebar on the selected page. Part of #15948.
2020-07-28 22:48:50 +02:00
<div class="sidebar">
help: Refactor help page CSS to eliminate padding on content containers. This is essential for using simplebar, since simplebar doesn't account for parent <div> paddings, which might cause scrollbars to be mispositioned if not considered.
2018-07-11 19:18:36 +02:00
<div class="content">
portico: Use /help/ style pages for displaying policies. This replaces the TERMS_OF_SERVICE and PRIVACY_POLICY settings with just a POLICIES_DIRECTORY setting, in order to support settings (like Zulip Cloud) where there's more policies than just those two. With minor changes by Eeshan Garg.
2021-11-03 21:36:54 +01:00
{% if not page_is_policy_center %}
docs: Add proper backlink to the homepage from /help and /api. Currently, the "Home" link at the top takes one to the doc root, i.e., /help or /api. This is a little misleading since "Home" seems to be more synonymous with the Zulip homepage. This commit adds a proper backlink to the top logo that takes you to the homepage and renames "Home" to be more specific. The text after "|" will now take you to the doc root instead (/help or /api). Note that this allows us to link the /help and /api pages from the homepage while ensuring that backlinks allow the visitor to get back to the homepage.
2021-06-29 18:10:16 +02:00
<h1><a href="https://zulip.com" class="no-underline">Zulip homepage</a></h1>
docs: Add doc root links to sidebar. A recent commit (5a94bfcb88bffc245c159dc896eb5ab873461805) introduced a couple of regressions: * The part of help.js that highlights the active page in the sidebar raised an exception on /help and /api since there was nothing to highlight for the doc roots in the sidebar anymore. * Moving the doc root links to the header after the logo made it such that on narrow mobile widths, there was no way to get to the doc root since the links in the header were truncated. With a CSS change by tabbott to avoid awkward vertical spacing.
2021-07-28 23:31:40 +02:00
<h1><a href="{{ doc_root }}" class="no-underline">{{ doc_root_title }} home</a></h1>
portico: Use /help/ style pages for displaying policies. This replaces the TERMS_OF_SERVICE and PRIVACY_POLICY settings with just a POLICIES_DIRECTORY setting, in order to support settings (like Zulip Cloud) where there's more policies than just those two. With minor changes by Eeshan Garg.
2021-11-03 21:36:54 +01:00
{% 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) }}
api-docs: Move include markdown macro files for API documentation. Moves files in `templates/zerver/help/include` that are used specifically for API documentation pages to be in a new directory: `templates/zerver/api/include`. Adds a boolean parameter to `render_markdown_path` to be used for help center documentation articles. Also moves the test file `empty.md` to the new directory since this is the default directory for these special include macros that are used in documentation pages.
2022-12-07 19:41:17 +01:00
{% 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) }}
portico: Use /help/ style pages for displaying policies. This replaces the TERMS_OF_SERVICE and PRIVACY_POLICY settings with just a POLICIES_DIRECTORY setting, in order to support settings (like Zulip Cloud) where there's more policies than just those two. With minor changes by Eeshan Garg.
2021-11-03 21:36:54 +01:00
{% else %}
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, context=api_uri_context) }}
portico: Use /help/ style pages for displaying policies. This replaces the TERMS_OF_SERVICE and PRIVACY_POLICY settings with just a POLICIES_DIRECTORY setting, in order to support settings (like Zulip Cloud) where there's more policies than just those two. With minor changes by Eeshan Garg.
2021-11-03 21:36:54 +01:00
{% endif %}
{% if not page_is_policy_center %}
help: Rename back button text. Renamed back button text to Zulip instead of Home.
2018-09-12 08:27:28 +02:00
<h1 class="home-link"><a href="/" class="no-underline">Back to Zulip</a></h1>
portico: Use /help/ style pages for displaying policies. This replaces the TERMS_OF_SERVICE and PRIVACY_POLICY settings with just a POLICIES_DIRECTORY setting, in order to support settings (like Zulip Cloud) where there's more policies than just those two. With minor changes by Eeshan Garg.
2021-11-03 21:36:54 +01:00
{% endif %}
help: Refactor help page CSS to eliminate padding on content containers. This is essential for using simplebar, since simplebar doesn't account for parent <div> paddings, which might cause scrollbars to be mispositioned if not considered.
2018-07-11 19:18:36 +02:00
</div>
help: Redesign /help/ pages to be a single page app. This redesigns the /help/ page sets to be a single page app that uses history.pushState to work the same as the old app. The big new feature is that now we have the index in a nicely designed left sidebar.
2017-07-10 20:50:11 +02:00
</div>
Make /help/ sidebar more discoverable on mobile/narrow. This makes the /help/ sidebar more discoverable at windows less than 1000px in width because it makes it stick out a bit when it is closed with the hamburger menu at the top. Fixes: #6038.
2017-08-22 21:03:28 +02:00
help: Redesign /help/ pages to be a single page app. This redesigns the /help/ page sets to be a single page app that uses history.pushState to work the same as the old app. The big new feature is that now we have the index in a nicely designed left sidebar.
2017-07-10 20:50:11 +02:00
<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>
Make /help/ sidebar more discoverable on mobile/narrow. This makes the /help/ sidebar more discoverable at windows less than 1000px in width because it makes it stick out a bit when it is closed with the hamburger menu at the top. Fixes: #6038.
2017-08-22 21:03:28 +02:00
help: Redesign /help/ pages to be a single page app. This redesigns the /help/ page sets to be a single page app that uses history.pushState to work the same as the old app. The big new feature is that now we have the index in a nicely designed left sidebar.
2017-07-10 20:50:11 +02:00
<div class="markdown">
<div class="content">
portico: Use /help/ style pages for displaying policies. This replaces the TERMS_OF_SERVICE and PRIVACY_POLICY settings with just a POLICIES_DIRECTORY setting, in order to support settings (like Zulip Cloud) where there's more policies than just those two. With minor changes by Eeshan Garg.
2021-11-03 21:36:54 +01:00
{% 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) }}
api-docs: Move include markdown macro files for API documentation. Moves files in `templates/zerver/help/include` that are used specifically for API documentation pages to be in a new directory: `templates/zerver/api/include`. Adds a boolean parameter to `render_markdown_path` to be used for help center documentation articles. Also moves the test file `empty.md` to the new directory since this is the default directory for these special include macros that are used in documentation pages.
2022-12-07 19:41:17 +01:00
{% 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(article, context=api_uri_context, help_center=True) }}
portico: Use /help/ style pages for displaying policies. This replaces the TERMS_OF_SERVICE and PRIVACY_POLICY settings with just a POLICIES_DIRECTORY setting, in order to support settings (like Zulip Cloud) where there's more policies than just those two. With minor changes by Eeshan Garg.
2021-11-03 21:36:54 +01:00
{% else %}
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, context=api_uri_context) }}
portico: Use /help/ style pages for displaying policies. This replaces the TERMS_OF_SERVICE and PRIVACY_POLICY settings with just a POLICIES_DIRECTORY setting, in order to support settings (like Zulip Cloud) where there's more policies than just those two. With minor changes by Eeshan Garg.
2021-11-03 21:36:54 +01:00
{% endif %}
user docs: Add reference to support email in docs footer.
2018-06-19 16:52:29 +02:00
footer: Integrate newly designed footer. This footer was designed and mostly written by @terpimost. This adds a new design of the footer for both corporate and not corporate enabled pages.
2023-03-08 19:14:05 +01:00
<div class="documentation-footer">
templates: Mark all void tags as self-closing. This reverses the policy that was set, but incompletely enforced, by commit 951514dd7dd2fafb67e9e9c6930d31b9295741c0. The self-closing tag syntax is clearer, more consistent, simpler to parse, compatible with XML, preferred by Prettier, and (most importantly now) required by FormatJS. Signed-off-by: Anders Kaseorg <anders@zulip.com>
2021-04-21 00:46:14 +02:00
<hr />
templates: Improve footer content on documentation pages. Makes the footer content on doc pages more contextually appropriate for self-hosted organizations, when `settings.CORPORATE_ENABLED` is false. When `settings.CORPORATE_ENABLED` is true, there is specific footer content for the policy documentation pages, and for the help center and API documentation pages. Fixes #23068.
2022-09-27 13:18:33 +02:00
{% 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 %}
user docs: Add reference to support email in docs footer.
2018-06-19 16:52:29 +02:00
</div>
Added footer to all user docs. Fixes #3112
2017-01-11 11:24:58 +01:00
</div>
</div>
docs: Add a simple markdown-based help center. The plan is to use this for adding user documentation to Zulip.
2016-11-09 01:45:36 +01:00
</div>
{% endblock %}