One disadvantage of relying on Jinja2 to load all templates is that it
only searches a finite set of pre-configured template directories.
Unfortunately, that breaks when someone tries to enable a custom
privacy or terms page and has the corresponding template in a
directory outside of Jinja2's recognized directories (for instance, it
won't find `/etc/zulip/terms.md`, the recommended path).
This commit makes it so that render_markdown_path can be more
sensible about pure Markdown files and load templates with
absolute paths directly without relying on Jinja2, if need be.
This commit transitions landing-page.css from the Django pipeline
to being compiled by webpack as landing-page.scss under the
'landing-page' and 'integration' bundles.
Apparently, essentially every one of our landing pages extending
portico.html had two copies of portico.css included in their head
section; one from porticocustomhead (or the super of customhead) and
the other directly included.
Clean this up by removing all these duplicate inclusions of the
portico stylesheet.
Apparently, the filters implementation was doing some sort of strange
caching, where you would need to restart the server in order to
refresh for changes to the markdown content.
We fix this by switching to just calling the render_markdown_path
function from Jinja2.
Fixes#5974.
While we already don't link to /terms anywhere on the site, they can still be
accessed if you navigate to /terms directly. Now, those routes will only be
exported on the Zulip.com service.
We should ideally provide a mechanism for deployments to specify their own
terms without modifying source code; in the interim, sites that have already
customised the provided Zulip.com terms can simply carry a patch reverting this
commit.
The check-handlebars-templates script now looks at most of our
back end templates to try and find imbalanced tags. This commit
fixes a bunch of the existing templates.
(imported from commit fad4a5d85d68160370dd588b41d6f125f64d198f)
This needs to be deployed to both staging and prod at the same
off-peak time (and the schema migration run).
At the time it is deployed, we need to make a few changes directly in
the database:
(1) UPDATE django_content_type set app_label='zerver' where app_label='zephyr';
(2) UPDATE south_migrationhistory set app_name='zerver' where app_name='zephyr';
(imported from commit eb3fd719571740189514ef0b884738cb30df1320)