Introducing Lektor – A Static File Content Management System For Python
lucumr.pocoo.org
lucumr.pocoo.org
* Website: https://www.getlektor.com/
* Github: https://github.com/lektor/lektor
Would be really curious to hear how people like it :)
Is there a roadmap for contributing to the project? I failed to see one on github.
Nope. Hoping to get some feedback to see what people need. It does what I need pretty much at the moment. Just figured i add some docs and share it as some sort of Christmas or whatever else you celebrate present.
I grew to heavily dislike the idea of just executing random code to configure things. Impossible to expose to tools, even harder to reason about it. Note that these files do not contain python code at all. They just sometimes contain little Jinja templates.
The idea is indeed that the GUI can eventually edit some of these things. It also is already used for `lektor plugins add` for instance which updates the project ini file.
Lastly the reason ini over yaml is purely that this can preserve comments and doing the same for yaml is a lot more work i did not have time for :)
[children]
replaced_with = site.query('/projects').filter(F.categories.contains(this))
Was that the only thing that bothered you about YAML/pyyaml or were there other things you'd like to see fixed?
If this is as nice yo use as the documentation leads me to believe it will be, I may just turn some of my existing exploratory code into plugins for this instead of building my own entire tool around them.
- Python 2.7 (not Python 3.x)
I've read some of your remarks about Python 3, but it seemed like you were (at least begrudgingly) accepting the shift to Python 3. So why no forwards compatibility here? Any plans to support Python 3 in the future?
Great to see another useful bit of software created. Did you miss the opportunity to build it in Python3?
A question (that will surely become a FAQ) - how does this compare with Pelican? Is this a non-programmer-friendlier alternative to Pelican?
I dare say it's how many currently-popular products came into being.
- Static HTML export with elegant dependency tracking by design (reducing attack vectors and maintenance cost on the frontend server)
- Admin interface (I can't tell a non-techie to connect via SSH, fire up vi and run Jekyll)
- Flexible content structure (Title/Author/Content doesn't really scale beyond a simple blog)
- Elegant design and implementation (I could do anything with WordPress and half a dozen plugins, but I fail to even find a bare-bones theme without kilobytes of code that I will never need; the whole ecosystem revolves around the novice user who understandably prefers "quick and dirty" over touching code)
I have been looking for a CMS that fulfills these exact criteria for quite some time. Lektor looks ideal for projects where the developer prepares a non-trivial page structure (think book listings, music albums, anything that goes beyond bold and italic), but the client should be able to edit content. Thank you, Armin!
And yes, Grav and Cockpit are self-hosted flat-file CMS, but now that you ask makes me confused. I was under the impression that Lektor was similar where you have a flat-file CMS and whenever a change is made, the static files are created.
My second guess is that this actually a CMS that exists locally and deploys static files when a change is made?
The key addition is that there is a nice UI for adding content in the system running locally, so it can be used by less technical users that might not feel comfortable with writing in text files with special tags/metadata, as traditional static generators require.
If you did want to build a custom SSG, I think you're best bet is starting from Gulp, and building from there. At least then you can leverage the Gulp ecosystem instead of re-building everything yourself.
> There is very little innovation in that space and that's a bit unfortunate
I'll have to respectfully disagree with Armin here, but perhaps I map the terrain a little differently than he does.
In addition to the half-dozen tools he names, which are more narrowly targeted at blog-like static sites, the broader space of asset pipelines and static generation is seeing a lot of innovation. I'd point to Gulp and Rails' latest as a sign that there's more work to do here. Even strictly in the Django world, there are a zillion asset-pipeline-like-apps; django-compressor and django-pipeline, the two most used, are quite different in their approach and philosophy.
I'm excited by this proliferation of tools for generating static web content "offline" and expect to see far more in the future. Lektor looks like another interesting piece to the puzzle, particularly in its focus on end-users rather than programmers. (Anyone remember Movable Type? That's probably the first user-centric static site generator to gain widespread use?)
If you want to throw them into the same category, then sure, there is different stuff happening. But Gulp is even further away from something non programmers can use.
(And completely agree on the programmer-centric nature of these tools.)
If you're thinking that the scene of MVC JavaScript frameworks resembles more of the good ol' days of the Wild Wild West, wait to see how things are currently like on the SSG front.
Cactus was on the right track with that although I'm fairly sure the author, Koen Bok is now focussed on his company, Framer. Are there plans to build clients for other platforms? I guess the community can jump in at any time.
Sidenote: do people know of native clients for the other major static site generators like Jekyll, Hugo, Middleman?
Shameless plug: If you're looking for somewhere to host your static site, please check out my side project, http://www.knownly.net
It's open sourced via BSD 3 clause: https://github.com/koenbok/cactus
I especially liked the "deploy to s3" feature, IMO the cheapest way to run a highly scalable static site today.
Alternatively, a "deploy to GitHub page" would be neat as well.
I would work on extending Cactus if it was a bigger problem personally, but so far what's released fits my needs already.
I do have two questions, though. Why the new file extension (.lr) and the field separator?
Jekyll's front matter format is easier for most people - and my engine uses a plain newline to separate front matter from text, and supports multiple file extensions to make it easier for desktop editors.
(I went with .txt/.md/.textile to support multiple markup engines and make it easier for people to edit with literally anything)
A non technical user would use the admin interface.
Obviously a custom file extension is not particularly nice but there is really not that much one can do around that. Renaming the file to `.md` will not magically make things better because the contents are just wrong and the Markdown format just does not do what Lektor needs.
This made me chuckle. Many comments seem to fall into two categories: 1) How is it different from SSG_X? 2) Why is it different from SSG_X? (Both are valid questions, no doubt.)
The flexibility in content structure is what makes Lektor a more framework-like CMS. The possible complexity can't really be represented with newlines. For example, my "Abstract" field might be several paragraphs long.
Really appreciate you starting it out this way from the getgo.
> Because I run so many Open Source projects and maintenance of all of them turns out to be tricky I figured I do this better this time around.
Looking forward to seeing Flask & Flask-SQLAlchemy moved to a dedicated Flask org on github. Ideally with another person or two having Pypi creds for pushing releases.
In my view a content only API would be more disruptive. A smart content API as a service could be used for any project. Give it a beautiful interface for authors and focus on the writing experience.
Maybe this is Mediums potential new market/ platform. What if you could grab and query your content with a smart api with graphql? No updates, servers, etc.
Any new project I used, I grab my content from this saas and use whatever tech/framework I want. Why aren't more devs looking at this as an option going forward?
The only thing it's missing from your description is graphql. :)
I'm working on making hosting for static sites easier. My static hosting service is still in beta, but we have a sign up form if people are interested. http://www.statichosting.co/
True, but that's not the audience anyways. The idea is that if you (as a web developer) want to make a portfolio site for a customer you could use lektor instead of wordpress or something like this. I generally always prefer static website generators for my own work but I cannot give it to a non technical person to fill with content. That's what motivated it.
But nobody needs to switch for anything. It's just another tool in the shed :)
[I run a Tumblr software blog at http://sandpaper.io.]
A related idea on my mind lately is using Tumblr just as a backend CMS. Then pull the content via their API to display to end users on a separate site. For example, with a bot that automates publishing to a gh-pages branch.
The motivation is that their editing tools and app are so nice, but their presentation makes a site feel less professional. (Also because of the limited abilities to tweak CSS, use JS, and optimize performance can be a bit frustrating.)