Introducing Lektor – A Static File Content Management System For Python
lucumr.pocoo.orgDirect links to project:
* Website: https://www.getlektor.com/
* Github: https://github.com/lektor/lektor
Would be really curious to hear how people like it :)
You need to make sure you have the following software installed on your computer:
- 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?
I build this originally for myself and i don't use python 3. I'm happy to accept patches for python 3. I think it should not be hard.
"I build this originally for myself and i don't use python 3"
Great to see another useful bit of software created. Did you miss the opportunity to build it in Python3?
It's quite late for me so I've only had time to read the documentation, but so far I love what I see. I've had a goal of building the static site tool I've wanted to use for a long time now, name chosen and everything, but you may have built something nice enough I don't need to.
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.
Very nice. I had been building the same thing after wanting something more than pelican and less than wordpress. This seems to fit perfectly.
Is there a roadmap for contributing to the project? I failed to see one on github.
> 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.
Would you mind listing some specific features you're interested in? I ask because I've recently switched from WordPress to Pelican, and I'm quite happy, so far at least.
Looks nice, Armin
A question (that will surely become a FAQ) - how does this compare with Pelican? Is this a non-programmer-friendlier alternative to Pelican?
It is. But it also is a lot more flexible. It's more of a framework than a simple generator.
Interesting. Being a framework and more flexible sounds like something that's more programmer oriented rather than more "common people" oriented. I'll check out how you managed to pull this off once I get some free time
the ini-file configuration seems a bit strange to me(esp since it seems to be ini-files that occasionally contain python code). Why did you go with them instead of making these python classes? To allow the GUI to edit parts of them as well?
> the ini-file configuration seems a bit strange to me(esp since it seems to be ini-files that occasionally contain python code). Why did you go with them instead of making these python classes? To allow the GUI to edit parts of them as well?
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 :)
>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 :)
Was that the only thing that bothered you about YAML/pyyaml or were there other things you'd like to see fixed?
YAML is really quite complex. I like it in general but it's impossible to dump the data out without destroying the structure of the file (throw away comments, change whitespace, formatting style etc.)
Did you look at https://pypi.python.org/pypi/ruamel.yaml ?
Nope. Did not see it. That's neat though. Would probably have done it differently in that case, but no real reason to switch now.
TOML? It was made because YAML was too complex.
Thanks. Yes, the code-as-configuration thing is difficult, it invites people to do very strange things sometimes.
(from the categories example) looked a lot like embedded code to me ;)[children] replaced_with = site.query('/projects').filter(F.categories.contains(this))Since there is no SQL I'm using the expression language from the templates for queries :)
I always love your work, Armin. Definitely sounds like something I've been looking for for ages. Definitely will give it a try.
This looks nice! Thanks for sharing it.
My feeling is that every serious programmer will end up inventing tools like this simply because the overhead of incorporating other people's tools eventually starts to overtake the overhead of maintaining one's own system.
Let's not forget that Lektor solves actual problems. Show me another CMS that offers:
- 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!
Checkout SpudPress - Static WordPress hosting. All the same except you can use WordPress theming and Admin. If you know how to distinguish between static and dynamic. It's insanely useful
I think a lot of people who would love to use a self-hosted version of this. However, paying for $20/m is usually not worth for a hobby/blog site.
Correct me if I'm wrong but they are either hosted CMS solutions (Grav, Cockpit) or static website generators (Harp) like Jekyll and friends.
Harp actually is a static generator (didn't think it was, never used before).
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?
Lektor is a static site generator: it generates a "compiled" version of the site that is uploaded to a simple web server, without any server-side scripts running. If you want to edit something, you run it locally, make your changes, generate new files and copy those to the web server.
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.
GravCMS perhaps? http://getgrav.org
Grav advertises "smart caching", so it's not static export by design, is it?
You're right, it's not a static site generator, but a (very fast) dynamic flat file CMS. I guess I got this mixed up because I found it while looking into static site generators.
Did you test this generator in production? If not, the verdict is not out yet on Lektor and remains to be seen how it will fare in production environments and on the battlefields.
I think that's why we have so many static site generators. However programmers typically end up just making the static site generator which is why there was nothing like Lektor before (to the best of my knowledge at least).
I remember that Blogger, in the beginning, used to work as a static site generator. You edited your posts in the user interface, and you could publish the result to a static hosting via FTP.
https://web.archive.org/web/20020210134317/http://www.blogge...
it was shut down in 2010 http://blogger-ftp.blogspot.com/2010/01/deprecating-ftp.html
I know it was shut down. But I think it's interesting to see how the wheel turned, again.
That's the problem with Static Site Generators (SSG) in general. They're opinionated by nature and the learning curve could prove steep to process all the details of the configurations necessary to get the maximum mileage out of the framework but as you dig deeper and deeper, you realize that you'd be better off building your own framework that's fit to your objectives and use cases and improve and expand on that as you go along.
I disagree. The great thing about SSGs like Jekyll and Middleman is that they're very easy to build plugins for. Jekyll in particular is easy to learn, and easy to expand. I honestly can't imagine a bona fide programmer having that much difficulty picking up Jekyll.
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.
I'm building my own productivity software program using Rails for this reason. I want to see only what I want to see on that page, I want nobody else's ideas getting in the way. It has an intended audience of exactly one, and will in all likelihood never acquire another user.
Yep.
I dare say it's how many currently-popular products came into being.
:-)
I always love Armin's stuff. In quality, it's often near that oh-so-very-special spot that is reserved for Steve Yegge's best posts. Now I will simultaneously be lynched by both the people who think that Steve sucks, and the people who think that Steve's stuff is 1 million times better than anything Armin could ever post. Not to mention 500 other groups who I don't even know.
nope, you're upvoted b/c i also appreciate source-level userfriendliness of pocoo projects
From the original post:
> 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?)
> I'd point to Gulp and Rails' latest as a sign that there's more work to do here.
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.
I definitely do see gulp et. al. as belonging to the same category of tools, although they're much more general-purpose. I think that's where I map the terrain differently than you. I do so because I'm hopeful that future innovations there will find their way back to tools like Lektor, etc.
(And completely agree on the programmer-centric nature of these tools.)
Armin Ronacher just makes more and more awesome stuff. I think I'm going to ditch my pelican site, and go for Lektor.
I'm really suffering from an acute case of Analysis Paralysis when it comes to Static Site Generators. The offerings on the market are overwhelming and you don't know which one to pick, do you go with an incumbent or mainstream like Jekyll with a huge selection of functionality at your disposal or go for the underdog and minimal one offering just the basics or just build your own framework and adapt to the evolving needs of your projects over its lifetime.
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.
i had this problem a week ago- ended up building an ultra-low-frills low-dependency one in an afternoon just a few weeks ago. Seems silly - i am pretty sure with sufficient time investment i am better off learning how to use popular frameworks (because learning how to use frameworks will make me better at learning how to use frameworks).
I'm in the same situation. I think I'm going to go with Pandoc + make and escape SSGs altogether.
Considering that one of the project's main goals is to address the needs of non-programmers, do you plan to add an improved Markdown editor (with some syntax highlighting and maybe buttons for things like titles, bold, etc.)?
Absolutely. See also the open ticket here: https://github.com/lektor/lektor/issues/7
This looks great! The native desktop app is a powerful way to drive adoption with non-technical people.
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
I want to also vote up Cactus despite the lack of attention paid to it lately. IMO it's very well designed and deserves to be worked on by a wider community.
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.
Very neat. Static site generators are hard to get right (I've been hacking away at a hybrid solution at http://sushy.no-bolso.com / http://blog.carmo.io - same engine, different themes).
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.
The .lr format is easy to explain: it conforms to data models and is easy to parse and generate. Frontmatter does not fit into these requiements. I tried it quite a bit but it makes everything more complex. Not worth it.
Well (and this is only an opinion) having to separate each field makes it harder to edit manually, and a new file extension will be a hassle for non-technical users who want to use their favorite editor.
(I went with .txt/.md/.textile to support multiple markup engines and make it easier for people to edit with literally anything)
> Well (and this is only an opinion) having to separate each field makes it harder to edit manually, and a new file extension will be a hassle for non-technical users who want to use their favorite editor.
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.
> Why the new file extension (.lr) and the field separator?
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.
> Lektor belongs to a separate org and the project does not use any resources only I have access to (other than the domain name and the server travis-CI deploys to).
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.
Armin, are you not afraid that having to install Lektor locally could be a serious obstacle for "people that have no understanding of programming"?
I wonder how hard it'd be to bundle up into a single executable that the user could run. I know I've been battling with Python -> exe tools ever since I started using Python, though.
There is a bundled cersion for osx with a ui. Just didn't have the time to do it for windows and linux.
Respectfully, I don't think this puts this project outside the scope of any other static site generators as listed.
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?
Services such as the one you describe do exist, e.g. [Contentful](https://www.contentful.com/). I've used it on a few projects and it's pretty awesome.
The only thing it's missing from your description is graphql. :)
This looks really interesting. I always love seeing new static site builders. Each one is a bit different, which is cool.
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/
Thanks for the link Brian. The "Get In Line For The Beta" button does not work for me (it does not do anything).
Out of topic: When the next version of Flask will be released? Does Flask has a roadmap or it is "abandonware"?
This is great! I'm using pelican and while a very good tool, I was considering building out a desktop/local-front-end for it...But this is MUCH better than what I could build (with my current level of expertise)...i think i'll be using this, and seriously consider contributing! Kudos @mitsuhiko!
I love Armin's work, especially Flask, but this seems like lot of other products out there. I have no incentive to switch to this from the generator I'm already using, and for non-techy people I think it's still a big jump in terms of just opening up a tumblr blog.
> for non-techy people I think it's still a big jump in terms of just opening up a tumblr blog
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 :)
> ...just opening up a tumblr blog
[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.)
What other static file CMS are you using?
I don't use a static file "CMS", but I use my own generator[1] which I made because I wanted something really fast. If you want a flat file cms, then a Google search will throw a lot of them. Kirby is the most popular, IMO. But it's not FLOSS. PicoCMS ticks all those boxes though.
I wanted a "full" CMS and a GUI, and it looks like finally I got one now. I hadn't seen another static generator that had a GUI of any kind (that seemed to be supported.)
As he said in blog, another framework is not enough easy use for non-tech user
Nice stuff! (Again and again :)) What's about multi-language website? Tips? Advice?
Urubu (A micro CMS for static websites, with a focus on good navigation practices.) might be an alternative: http://urubu.jandecaluwe.com/
Does it support some kind of live preview mode (like with HarpJS) ?
Depends on what you mean by live. If you hit the save button the page renders immediately and you can see it. It rebuilds as files change.
Hmm - gonna have to steal this for a project in new year. This comment is more a bookmark than any contribution to society
I found sculpin pretty much perfect, but having a built-in admin panel is a nice touch.
Why did you call it Lektor?
It's German for editor. I'm gonna guess for the same reason that his WSGI library is called Werkzeug (tool).
i like http://www.mkdocs.org, it's also python based.