I'm using short video clips quite a bit with Lektor and sometimes I want to thumbnail them. This PR adds both thumbnailing and some basic metadata support.

Example

{% set video = this.attachments.videos.first() %}
<img src="{{ video.thumbnail(250, 250)|url }}">
<img src="{{ video.thumbnail(250, 250, crop=True)|url }}">

The full function signature is:

.thumbnail(width, height=None, seek=None, crop=False, quality=None)

The parameters are the same as for images, but the seek parameter is new. seek is a timedelta offset for when image should be captured (default is halfway in).

I've also added some basic metadata support:

{{ video.width }}
{{ video.height }}
{{ video.duration }} (timedelta)

(I haven't made the test cases yet, as I wanted some initial feedback)

Todo

• [x] Add caching for pip -> https://github.com/actions/cache/blob/master/examples.md#python---pip
• [x] Add caching for node

Issue(s) Resolved

Fixes #733

Related Issues / Links

#226

Hi, This is a POC of themes support, I follow the advice in https://github.com/lektor/lektor/issues/226#issuecomment-226142885 and implement it in a way very similar to Hugo themes.

Themes could be installed in the themes directory, It will look like this:

project
├── assets
├── models
├── content
...
└── themes
    └── lektor-theme-nix
        ├── assets
        ├── models
        └── templates

Many themes could be added and the variable theme in .lektorprojectwill define the theme to be loaded:

[project]
  theme = lektor-theme-nix

Themes could provide templates, assets, and models (also flowdocks)

And atheme_settings section in .lektorproject file could be used for parametrize themes:

[theme_settings]
  name = "Rafael Laverde
  email = "[email protected]"
  about = ""
  profilepicture = "img/image.jpg"

And those settings will be accessed in templates through the config env variable:

{{ config.theme_settings.name }}

This is working? Yep, I'm using it to build my personal website, you could take a look at how the structure look like: https://github.com/rlaverde/rlaverde

I also did a theme https://github.com/rlaverde/lektor-theme-nix (based in an Hugo theme )

I think this PR is only missing tests, but there's a lot of stuff to do to:

• Documentation of how to create a theme
• A better way to create index.html and 404.html pages
• A repo to track all themes
• A site for displaying themes previous
• A more complete example project that will be used for themes as a guide
• A command to generate the basic structure of a theme (lektor new theme)
• Define a file (theme.ini) to contain metadata of the theme: name, author, version, lektor-required-version, keywords...
• ...

I tried installing Lektor on Linux via the installer script at https://www.getlektor.com/install.sh. This resulted in the following error messages:

/usr/bin/python: can't open file './src/virtualenv.py': [Errno 2] No such file or directory
/usr/bin/python: can't open file './virtualenv.py': [Errno 2] No such file or directory

It seems the internal structure of the virtualenv package changed again. If I modify the installer script to force an older version of virtualenv, it works again:

VENV_URL = "https://pypi.org/pypi/virtualenv/16.7.9/json"

I've downloaded the dmg from the lektor website and tried the following:

1. Open Finder and navigate to Downloads
2. Open OS X Console, clear it and insert marker
3. Double-click Lektor.dmg
4. Drag to Applications (progress bar appears, no errors)
5. Open Applications in Finder
6. Double-click Lektor.app
7. OS X errors appears saying “Lektor.app” is damaged and can’t be opened. You should move it to the Trash.

Console shows the following log messages right after the marker.

11/04/16 16:42:16,148 CoreServicesUIAgent[353]: Error -60005 creating authorization
11/04/16 16:42:18,382 diskimages-helper[1004]: *** -[NSMachPort handlePortMessage:]: dropping incoming DO message because the connection is invalid
11/04/16 16:42:23,334 lsd[235]: LaunchServices: Could not store lsd-identifiers file at /private/var/db/lsd/com.apple.lsdschemes.plist
11/04/16 16:42:27,297 lsd[235]: LaunchServices: Could not store lsd-identifiers file at /private/var/db/lsd/com.apple.lsdschemes.plist
11/04/16 16:42:27,326 CoreServicesUIAgent[353]: Error -60005 creating authorization
11/04/16 16:42:29,133 CoreServicesUIAgent[353]: Error SecAssessmentCreate: The operation couldn’t be completed. (OSStatus error -67061.)
11/04/16 16:42:32,947 com.apple.xpc.launchd[1]: (com.apple.xpc.launchd.oneshot.0x1000001b.Electron[1006]) Service exited due to signal: Killed: 9
11/04/16 16:42:32,953 lsd[235]: LaunchServices: Could not store lsd-identifiers file at /private/var/db/lsd/com.apple.lsdschemes.plist
11/04/16 16:42:32,978 lsd[235]: LaunchServices: Could not store lsd-identifiers file at /private/var/db/lsd/com.apple.lsdschemes.plist

What does everyone think about adding pre-commit with black/isort/flake8 to the codebase? It would make everything look more consistent and would enforce the style at the CI level. flake8 would also get rid of some common bugs.

I have found that I can halve my image size if I pass -strip to ImageMagick. Due to my thumbnail plugin being what it is, I would greatly benefit by process_image being able to accept a list of extra parameters to pass to ImageMagick.

It would not be appropriate to include these parameters in process_image in mainline because not everybody wants thumbnail-quality, but for my plugin they're ideal. Would this be a desirable PR to open? If so, I can submit it ASAP.

What do you think, @nixjdm?

I get this on master:

Uncaught (in promise) TypeError: Cannot read property 'props' of undefined
    at Object.isActive (http://localhost:5000/admin/static/gen/app.js:9182:27)
    at http://localhost:5000/admin/static/gen/app.js:9241:29
    at Array.map (native)
    at Object.render (http://localhost:5000/admin/static/gen/app.js:9232:44)
    at http://localhost:5000/admin/static/gen/vendor.js:16301:22
    at measureLifeCyclePerf (http://localhost:5000/admin/static/gen/vendor.js:15581:13)
    at ReactCompositeComponentWrapper._renderValidatedComponentWithoutOwnerOrContext (http://localhost:5000/admin/static/gen/vendor.js:16300:26)
    at ReactCompositeComponentWrapper._renderValidatedComponent (http://localhost:5000/admin/static/gen/vendor.js:16327:33)
    at ReactCompositeComponentWrapper.performInitialMount (http://localhost:5000/admin/static/gen/vendor.js:15867:31)
    at ReactCompositeComponentWrapper.mountComponent (http://localhost:5000/admin/static/gen/vendor.js:15763:22)

Oddly enough the generated code seems completely wrong:

	  isActive: function isActive(field) {
	    var value = undefined.props.value;
	    if (value == null) {
	      value = undefined.props.placeholder;
	      if (value == null) {
	        return false;
	      }
	    }

Not sure why this is undefined.props; the source says this.props.

I followed the procedure on Lektor's webpage, and despite having installed all prerequisites, I get the following errors:

Building wheel for inifile (setup.py) ... error
  ERROR: Command errored out with exit status 1:
   command: /usr/local/lib/lektor/bin/python3 -u -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/tmp/pip-install-af6y5v9m/inifile/setup.py'"'"'; __file__='"'"'/tmp/pip-install-af6y5v9m/inifile/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' bdist_wheel -d /tmp/pip-wheel-ayl9hhi2
       cwd: /tmp/pip-install-af6y5v9m/inifile/
  Complete output (6 lines):
  usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
     or: setup.py --help [cmd1 cmd2 ...]
     or: setup.py --help-commands
     or: setup.py cmd --help

  error: invalid command 'bdist_wheel'
  ----------------------------------------
  ERROR: Failed building wheel for inifile
  Running setup.py clean for inifile
  Building wheel for EXIFRead (setup.py) ... error
  ERROR: Command errored out with exit status 1:
   command: /usr/local/lib/lektor/bin/python3 -u -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/tmp/pip-install-af6y5v9m/EXIFRead/setup.py'"'"'; __file__='"'"'/tmp/pip-install-af6y5v9m/EXIFRead/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' bdist_wheel -d /tmp/pip-wheel-mxtpmzko
       cwd: /tmp/pip-install-af6y5v9m/EXIFRead/
  Complete output (7 lines):
  Warning: 'classifiers' should be a list, got type 'tuple'
  usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
     or: setup.py --help [cmd1 cmd2 ...]
     or: setup.py --help-commands
     or: setup.py cmd --help

  error: invalid command 'bdist_wheel'
  ----------------------------------------
  ERROR: Failed building wheel for EXIFRead
  Running setup.py clean for EXIFRead
  Building wheel for watchdog (setup.py) ... error
  ERROR: Command errored out with exit status 1:
   command: /usr/local/lib/lektor/bin/python3 -u -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/tmp/pip-install-af6y5v9m/watchdog/setup.py'"'"'; __file__='"'"'/tmp/pip-install-af6y5v9m/watchdog/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' bdist_wheel -d /tmp/pip-wheel-5pxag3tc
       cwd: /tmp/pip-install-af6y5v9m/watchdog/
  Complete output (6 lines):
  usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
     or: setup.py --help [cmd1 cmd2 ...]
     or: setup.py --help-commands
     or: setup.py cmd --help

  error: invalid command 'bdist_wheel'
  ----------------------------------------
  ERROR: Failed building wheel for watchdog
  Running setup.py clean for watchdog
  Building wheel for pathtools (setup.py) ... error
  ERROR: Command errored out with exit status 1:
   command: /usr/local/lib/lektor/bin/python3 -u -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/tmp/pip-install-af6y5v9m/pathtools/setup.py'"'"'; __file__='"'"'/tmp/pip-install-af6y5v9m/pathtools/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' bdist_wheel -d /tmp/pip-wheel-xurhnhnp
       cwd: /tmp/pip-install-af6y5v9m/pathtools/
  Complete output (8 lines):
  /tmp/pip-install-af6y5v9m/pathtools/setup.py:25: DeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses
    import imp
  usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
     or: setup.py --help [cmd1 cmd2 ...]
     or: setup.py --help-commands
     or: setup.py cmd --help

  error: invalid command 'bdist_wheel'
  ----------------------------------------
  ERROR: Failed building wheel for pathtools

Any sugestions? It installed without issue in windows, so I suppose it is something related to Ubuntu 20.04.

Issue(s) Resolved

Fixes #713

Description of Changes

• [x] Wrote at least one-line docstrings (for any new functions)
• [x] Added unit test(s) covering the changes (if testable)
• [ ] Included a screenshot or animation (if affecting the UI, see Licecap)
• [ ] Link to corresponding documentation pull request for getlektor.com

Actual relative URLs that omit unnecessary folder traversing.

Example: /articles/2019/07/brownies -> link to -> /articles/2019/07/brownies/image-gallery

Previous output: ../../../../articles/2019/07/brownies/image-gallery/ Ouput with this PR: image-gallery/

Note: Resources in the same directory are linked without ./ in front. With the only exception if the link target is the same. /blog/ -> link to /blog/ will result in ./ -> link to /blog/a.jpg will result in a.jpg

Tiny URLs for all :)

Is there any documentation or thoughts around a release schedule for Lektor?

There have been quite a few changes since the last release in May of 2016. If assistance is needed for preparing a release, I'd be willing to contribute some time towards doing so.

Add missing alt in pad query.

Issue(s) Resolved

Fixes #1092

Description of Changes

• [x] Wrote at least one-line docstrings (for any new functions)
• [ ] Added unit test(s) covering the changes (if testable)

Lets say, I use site.query('/path', this.alt)|list in a template. This will not only include the records of the provided alt, but also the records for the default alt.

Assuming the default alt is EN:

• layout-en.html with query('/pages', alt='en') tracks dependency on page1-en.html and page2-en.html.
• layout-de.html with query('/pages', alt='de') tracks dependency on page1-en.html, page2-en.html, page1-de.html, and page2-de.html.

In a plugin I'm writing, I wanted to change the jinja env, like so:

self.env.jinja_env.variable_start_string = r"\VAR{"
self.env.jinja_env.variable_end_string = "}"

in on_setup_env.

This seemed to work fine at first, but eventually I bumped into trouble at strange and (for me) unexpected places. For example, the field type select stopped working.

Eventually I figured out that Lektor is assuming in multiple locations in its source that the variable start and end strings are the default {{ and }}, for example in line 4 of https://github.com/lektor/lektor/blob/master/lektor/environment/expressions.py.

A quick test revealed to me that, at least at that particular spot, Lektor has access to the updated jinja environment settings, making this an easy fix.

Would there be an interest to support this case of alternative jinja settings in Lektor?

For a long time now, it has become clearer that having Lektor manage the installation of a project's Python plugins is a significant pain point for maintainers and users. There are a lot of issues that have popped up over the years, from bugs, to missing features. I and some other maintainers are leaning toward minimizing Lektor's role in installing and managing a project's plugin Python packages. @mitsuhiko do we have your go-ahead? Thoughts or concerns?

Regardless of the exact goal chosen, there are the normal concerns about breakages and deprecations in order to prepare users for the changes and not make things unnecessarily hard.

We need to decided what exactly this looks like. For example, this could mean:

Rough option 1) - minimize plugin management:

• Removing the lektor plugins command, and it's sub-commands
• Removing the use of the [packages] section from project files
• Remove the automated use of packages/ subdirectory
• Give specific and simple guidelines for installing packages in the docs, such as how to use a very basic Poetry setup, or requirements.txt.
• Possibly leave in the ability run a similar command to lektor dev new-plugin, though this would likely be modified, at least to match the changed docs instructions. I don't see this, isolated, to be very burdensome, and is potentially very helpful.

In my opinion this option is the best, because

• At presents everyone with a clear demarcation of responsibility, and lets a dedicated package manager do what it was made for
• It reduces maintenance burden to the minimum on this issue.

This plan has the con of potentially removing some convenience features for users, such as only having to understand and use a single program (Lektor) instead of a minimum of two (Lektor and pip/poetry/etc). The burden of choice at least can be minimized by clear instructions in our docs.

Rough option 2) - do some level of wrapping of a preferred packaging tool

Should we try to keep some pieces of lektor plugins, such as add, remove, and list, and adapt them to match or wrap a chosen tool like Poetry? Should we leave in [packages] and somehow translate that to invoke a tool like Poetry? Should we auto-install things from packages/? These goals are somewhat independent, and they may offload some maintenance burden, but they clearly add some too. Choosing this path could mitigate some of the drawbacks of the option 1). In my opinion, that is not a good enough tradeoff.

N.B. there are also several discussions about using a different package management strategy internally to maintain this repo. This wouldn't matter much if we choose option 1), above, but the less we approach option 1), the more it might reduce mental overhead to use the same tool for integrations for projects and to manage this repo itself.

I started working on packaging Lektor using hatch a few weeks ago.

The use of hatch allows for:

• Building the frontend javascript and css as part of the PEP517 build process using a build hook. In addition to simplifying the distribution building process by eliminating the make build-js step, this allows Lektor to be installed directly from a git repo.
• Management of development (and, potentially, test) virtual environments.

Issue(s) Resolved

Fixes #1081 Fixes #1057

Related Issues / Links

Description of Changes

• [ ] Wrote at least one-line docstrings (for any new functions)
• [ ] Added unit test(s) covering the changes (if testable)

• [ ] Link to corresponding documentation pull request for getlektor.com

(This work probably needs a bit of freshening. I'm creating this PR now since it relates to the newly created #1081.)

All or most of our tox tests could probably be converted to hatch scripts. At present, however, hatch does not support running scripts in parallel (e.g. there is no equivalent of tox -p) so running the full set of tests via hatch is painfully slow.

Currently, the frontend assets are missing if we install from a Git URL or zipball provided by GitHub. This is because we build the frontend files in a Makefile and it is called when publishing to PyPI.

~~Plus, are you open to switching to hatch as the build backend?~~ Oh, you are already doing it!