There appears to be an issue in which on production the
./landing-page/assets folder is excluded from the build process,
so move it to the parent folder to fix the assets to appear in
production.
This changes the JavaScript to fix the hash system to correctly save
state to allow a user to deep link to a particular app platform.
The mechanism is handled by a click event on #apps-tabs [data-toggle]
that fires a hash setter which then fires a hash getter which loads the
correct tab if necessary.
This results in a substantial performance improvement for all of
Zulip's backend templates.
Changes in templates:
- Change `block.super` to `super()`.
- Remove `load` tag because Jinja2 doesn't support it.
- Use `minified_js()|safe` instead of `{% minified_js %}`.
- Use `compressed_css()|safe` instead of `{% compressed_css %}`.
- `forloop.first` -> `loop.first`.
- Use `{{ csrf_input }}` instead of `{% csrf_token %}`.
- Use `{# ... #}` instead of `{% comment %}`.
- Use `url()` instead of `{% url %}`.
- Use `_()` instead of `{% trans %}` because in Jinja `trans` is a block tag.
- Use `{% trans %}` instead of `{% blocktrans %}`.
- Use `{% raw %}` instead of `{% verbatim %}`.
Changes in tools:
- Check for `trans` block in `check-templates` instead of `blocktrans`
Changes in backend:
- Create custom `render_to_response` function which takes `request` objects
instead of `RequestContext` object. There are two reasons to do this:
1. `RequestContext` is not compatible with Jinja2
2. `RequestContext` in `render_to_response` is deprecated.
- Add Jinja2 related support files in zproject/jinja2 directory. It
includes a custom backend and a template renderer, compressors for js
and css and Jinja2 environment handler.
- Enable `slugify` and `pluralize` filters in Jinja2 environment.
Fixes#620.
The SSO build of the desktop app is intended only for those users who
who have settings.SSO_ONLY set, i.e. the only way to login is via the
site's SSO REMOTE_USER authentication. We were incorrectly linking to
it on all production installations :(.
In order to enable internationalization support in Zulip, and to use
Django internationalization tools, all strings in Zulip frontend needs
to be marked for translation.
These may not work at time of writing due to propegation delays, but I
promise they'll be active soonish.
(imported from commit 4ed9e85f282fb868a75fa427f897bad8469d9e03)
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)
The problem here is that some error-related templates render without
the context managers that we specify, and so we want the handling of
"the context was not set" to default to the enterprise case (because
the enterprise version will work basically fine on !enterprise, but
the opposite is not true because the enterprise distribution doesn't
even have the templates for certain !enterprise pages that may be
linked to).
(imported from commit 7547311d87e048d33221587f44b82fe0ba320ca1)
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)