etc

I'm fine with per theme forms, the question is per theme file output. Say, if we want some files to be displayed inline, we need to create a corresponding form...

I'm just saying that storing file output headers in *forms* complicates things. Say, you decide to display some pdf files inline rather than offering them for download (which is txp...

Where do we store it then, if not in a form (because forms belong to themes)? A pref, something else?

I like it very much! But no clear idea of implementation atm: should the cooked code be stored in the same or a separate table? should any field be potentially...

From a brief look, it seems that all of these (incl. jQuery UI) use their own markup, which makes switching from one to another a pain. We have already a...

We don't necessary need to write a library, we (me) should just avoid using third-party selectors as much as possible to make migrations easier. Vue.js looks interesting because of its...

We could make a js-less admin interface (like it was originally), but we'd loose - the possibility to undo/redo changes when saving an article - large files upload - local...

If we ever switch to `Vue.js`, we'll be able to plug in [tiptap](https://tiptap.scrumpy.io/) editor based on ProseMirror, but seemingly more easily configurable.

I think yes, but probably later, when we get a more clear idea? We have already 3 branches in work.

> My brother's company use Vue.js after testing a lot of alternatives - including React - and they think it's great. So maybe worth testing further. After some testing I...