| Age | Commit message (Collapse) | Author |
|---|
|
This has been deprecated for a while and even before that (since 2.5) it
was just an alias, so switching our import should make no difference
other than working on jinja2 3.1.
|
|
Jinja2 v3.0 renamed contextfilter to pass_context. Put some code in that
handles both the v3 and v2 name at the same time, as a first step
towards supporting jinja2 v3.
|
|
This is one never seen before and seems to be used for shipping labels.
Bring it in and treat it like any other.
Noted by Christophe Pettus, but not his patch - going for a minimalistic
one. This code may need some further refactoring down the road.
|
|
This one unfortunately has to be less dynamic than the one in the
backend, and just hardcode support for Twitter and Mastodon for now.
|
|
|
|
Previously only json as supported for the template integration for
context.json and context.override.d. This adds support for yaml as well
both for a context.yaml file, and for putting yaml files in
context.override.d. If both a json and yaml exists with the same name
(in the root or in the override), then the json will be loaded first and
then the yaml merged on top of it.
YAML has a few features that are really useful for the context file such
as comments and easier on the eyes multi-line string handling, but
fundamentally the handling is exactly the same.
If the `yaml` module is not importable, then yaml files are simply
ignored.
|
|
|
|
Mention early that source and destination paths should be absolute. Otherwise
the user will only see it at runtime.
|
|
deploystatic.py will erase the unknown files in destpath. It is a wanted
feature which when used carelessly can lead to disaster. While one can not
protect from all disaster cases, a low hanging fruit is figuring out if destpath
is source controlled.
This is admittedly a minor gain, however it also minor to check.
|
|
This is complained about more loudly in newer versions of pycodestyle,
and it's a bad idea in general. So rename them all to something more
readable.
|
|
This can happen on a newly "git gc":ed repository during development.
We'd render the templates fine, but crash on creating
.deploystatic_githash.
|
|
It needs to be decoded from bytes to str.
TODO: see if there is a more holistic fix for this
|
|
|
|
Instead of loading a single override file in context.override.json, load
every file called *.json in the directory context.override.d.
This is useful for example for the case of downloading the schedule data
into a file and then using it for testing, instead of having to "stitch"
it into place in an existing file.
NOTE! For test cases using context.override.json today, just create a
context.override.d and move the existing override file into this
directory, and things should work like before again.
NOTE! As context.override.json is not supposed to be committed to the
git repository, this should not affect any production installs, but will
affect most local test setups.
|
|
|
|
While we don't need to restrict variable access (we always expose all of
context.json, and there is no database access through it..), we still
want to block disallowed methods on strings (for security reasons).
|
|
They were already utf8, but when comparing to an existing file we'd
open that file in whatever the default encoding was, which sometimes
could be ascii in a limited environment.
|
|
|
|
|
|
|
|
Previously in a case of dir1/dir2/dir3/file, if there were no files in
dir2 (only other subsdirectories, like dir3 in the example), all of dir2
would be removed, assuming there could be nothing in it further down.
|
|
In all our uses groupby_sort is used on an integer, and as of Python3
one cannot compare an integer and None (a very reasonable change). This
worked on Python2 more or less by mistake.
This fixes session list view in cases where there exists approved
sessions without tracks.
|
|
It has been deprecated, and instead we should use "in" and "not in", so
make that change across the board.
|
|
|
|
|
|
|
|
Mostly not important, but getting rid of the PIP warnings will help
catch errors in the future.
|
|
|
|
In an effort to close up with PEP8, we should use spaces for indent
rather than tabs... Time to update your editor config!
|
|
This removes the --githash parameter again, and replaces it with smarter
parsing. When working from a raw directory, do as before. When deploying
from a branch, call "git rev-parse" on the branch to get the branch tip,
and then use that hash. This is the same branch we actually deploy from,
so the contents should be correct at all times.
|
|
This will be needed when deploying off a branch, where we cannot just
open a file.
|
|
|
|
Factor out the removal of files/dirs into it's own function, making sure
both files and directories are cleaned up in both cases.
|
|
This allows a mode where only specific pages are deployed, and not all
of them. It also allows for files to be deployed to a different name
than their own.
|
|
|
|
Previously we only removed the files in the directories leaving empty
directories around. Better to remove the complete directory (including
subdirectories).
|
|
When using deploystatic to deploy directly from a repository branch,
there is no git repository in the resulting template directory. This
means that when the directory is loaded from the main jinja parser, it
does not find a .git, and thus does not set a githash.
To make this work, have deploystatic drop a file called
.deploystatic_githash into the target directory, and have the jinja code
specifically look for this code when trying to find the githash.
|
|
This is required because for example badge templates might reference
static data.
|
|
It's actually used in the rendering code.
|
|
This will deploy the template files themselves, not the result of them
being processed. These templates are then rendered by the master system.
Since these are not pages, it explicitly excludes the pages directory.
|
|
|
|
Support was present in the main website code, but not deploystatic.py,
making it less useful.
This adds a dependency to the standalone use of deploystatic.py for
markdown, but that should be trivial enough that it's not a problem.
Patch mostly from Stephen Frost
|
|
slugify already existed in the backend but was missing in deploystatic.
datetimeformat performs strftime() if the passed value is a date or time
object, and converts it to such an object to do strftime() on it if it
is not.
|
|
This avoids needing one repo cloned for each branch for returning
conferences (which is most of them).
|
|
|
|
This implements the ability to render confreg templates (registration,
cfp, schedules etc etc) using jinja2 instead of django templates. The
important difference is that these templates are rendered in a complete
sandbox, so they cannot reach into other parts of the system by
exploiting connected objects or by including templates they are not
supposed to.
Jinja templates are used whenever the "jinjadir" variable is set on a
conference. When it is, the variables for basetemplate, templatemodule,
templateoverride and templatemediabase are all ignored, as their
functionality is either no longer needed or implemented in a different
way using the templates.
For the time being we support both the old (django based) templates and
the new (jinja based) templates. That means that any changes made to the
confreg templates must be done twice. At some point not too far in the
future we should decide to either desupport old conferences that have
the old style templates, or re-render those as static. (For closed
conferences most pages aren't reachable anyway, but things like
schedule and session descriptions are reachable way past the end of
a conference)
Along with the templates come a new command called "deploystatic.py",
which runs outside the django environment. This command can be used for
deployment of static sites based on the jinja templates, similar to how
some conference sites have done it before. Since the templates run in a
sandbox, this should be much more safe than what's been done before, and
therefor access can be granted to more people. This command is made to
run standalone so conference template developers can run it locally
without having to install full support for django.
|
