New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issues with the Admin Interface #458

Open
mitsuhiko opened this Issue Sep 22, 2017 · 16 comments

Comments

Projects
None yet
8 participants
@mitsuhiko
Copy link
Member

mitsuhiko commented Sep 22, 2017

This is a followup issue to #457 without the license or technology conversation.

Current issues with the admin:

  • It is designed in a way that makes it seem like it should be possible to run multiple admins on one page (useful for testing). That's not possible due to a shared event bus for dialogs.
  • All views such as edit, add-child, preview, etc. are dynamically injected to the application but their presence is required by the side-bar component. To add a new view the side-bar must be modified manually anyway.
  • Routing state must be manually passed around which makes things really awkward in a lot of places, and it's hard to track what's being passed.
  • Global hotkeys are handled by the Breadcrumbs component instead of the app itself.
  • It depends heavily on the unsupported v2 of React-Router. Quite a few things needs fixing before upgrading (#430)

Some points I would like to stick with as far as the admin goes:

  • Base it on webpack
  • Build it on JavaScript
  • Stick with React or consider Preact. However that decision should be made exclusively on code quality / community support and not the patent grant.
@mitsuhiko

This comment has been minimized.

Copy link
Member

mitsuhiko commented Sep 22, 2017

With regards to the points that @runfalk brought up about the code quality of the admin interface I agree that it has major issues. It was my first react project and it shows. In particular I also strongly agree with it being a good idea to separate the admin from the server more so you can host the UI externally.

Right now that however also depends on the backend API calls being just not great.

I think it would be worth having a conversation at this point to decide on the following points:

  • do we want to keep the admin structure as it is?
  • does it make sense to decouple the admin from the build process?
  • can we give it a permission model / multi user awareness?

In case it was not clear from the other conversation: I do not have an issue with rewriting the structure of the admin. If someone wants to step up on that I would however like to participate in that project :)

@mitsuhiko mitsuhiko added the design label Sep 22, 2017

@tariquesani

This comment has been minimized.

Copy link
Member

tariquesani commented Sep 23, 2017

I guess the topic of dropping React probably has to do more with the fact that the current team does not have a member onboard who can fix the current issues. That can probably be remedied.

That said,

1 I do feel that the structure and workflow of admin is not scalable. Specifically the sidebar gets unwieldy after about a dozen pages. I would suggest having a separate listing page with pagination and search for pages of various models. A traditional CRUD workflow.

2 Decoupling admin from server will also be very useful as it would allow people to build admin interfaces of their choice. SPA, Traditional, Externally hosted and so on.

3 Once 2 is in place Adding permissions and user roles to admin would probably be easier.

I suggest an admin with more Flask, less JavaScript, perhaps BootStrap for good looks.

@runfalk

This comment has been minimized.

Copy link
Contributor

runfalk commented Sep 23, 2017

Facebook just went public that they'll remove the patents clause (and relicense it under MIT), so that discussion is now moot. Apparently they are also releasing version 16 next week too, which is a complete rewrite of the internals. I think sticking with React is a good idea.

The admin structure has mostly worked for my use cases. The only issue I've had is the child list in the sidebar which can't be ordered and it's not possible to see whether a child is hidden or not. I use Lektor for a travel diary. I often create children and write some keywords in them to remember what to write. Then I get back to them later and I ended up writing a Python script to order by date and displaying stars on hidden children.

I also think there is a problem of discoverability. It took me a long time to find the rebuild button (which would have saved me a lot of troubleshooting). In fact I don't think I've used any of them. Uploading of attachments is also one think I haven't used. I mostly use the file browser, but that doesn't update the list of attachments.

There is no place in the current interface for actions not directly related to pages:

  • Edit model files, such as removing or renaming a field. Since it requires editing all files that use the model it makes sense to add a feature for it (#98)
  • Seeing which plugins that are installed, maybe a way to install plugins from a repository in the future and store them in the project file. That way they won't need to be checked into source control
  • Editing the project file to add custom extensions and global variables
  • Managing deploy targets
  • See and manage data bags
  • See and manage flow blocks
  • See and manage templates
  • Browse and manage global assets

I don't think all these should be added in one go, but it makes sense to design an updated UI that allows all this. There are also things discussed in #324.

I think exposing a stable REST API makes a lot of sense if the admin is rewritten from scratch. I also think it makes sense to expose a lot of events like heartbeat and update triggers using server-sent events.

Is a user/permission model a good idea? I think the current code will deal pretty badly with concurrent updates, like two people modifying the same file. I have no idea if multiple build processes can run simultaneously, racing each other. If Lektor is used locally in conjunction with a Git repository the merge request may be a better place to verify permissions. Encouraging a remote Lektor installation might be a security risk as arbitrary files can be uploaded, and depending on server configuration maybe executed if the user misconfigures his web server or Lektor. Does anyone need this?

I'm interested in pursuing this issue in my spare time.

@nixjdm

This comment has been minimized.

Copy link
Member

nixjdm commented Sep 25, 2017

It seems to me a big consistent theme here is the desire for admin to be decoupled from Lektor. For that we need a good, documented, API. Extending that would be a matter of Python. Custom admins could be built to use it in various ways, with Flask, with React, whatever that architect wants. It could be hosted remotely, enable user permissions, etc.

A separate notion to me, is what the default driver for the admin is in this project. @tariquesani is right that we have a current lack of capacity in this team to develop it in React. If we stick with it, we are limiting our pool of developers. However, if we refactor without React then there is an initial lag time to make that refactoring. They both have pretty big negatives, but I'm leaning towards Flask.

@runfalk

This comment has been minimized.

Copy link
Contributor

runfalk commented Sep 26, 2017

Even if the current SPA admin is dropped for an old-school hybrid solution the need to learn a JS build system doesn't just go away. A lot of other things requires it too:

  • Babel has become the de-facto standard for JavaScript to deal with lack of browser support
  • Current admin uses SCSS which might be a good thing to keep going, JS build system
  • Webpack is used to bundle fonts like Roboto Slab and Font-Awesome
  • Electron

The thing that does go away is the need to learn another library (React in this case). Reacts API surface is so small it seems a bit ignorant to say that nobody on the current team knows it. I think rewriting the admin with Jinja will initially be a bliss, but as more JavaScript enhancements are added to replicate old functionality the codebase will become harder and harder to reason about. The current admin codebase is very simple. It just has problems with some weird coupling and opaque state that's being passed around.

@davidism

This comment has been minimized.

Copy link
Contributor

davidism commented Sep 26, 2017

My vote is not to throw out the current UI / tooling if possible. Yes, there are some migration problems right now, but my experience recently is that React and the other libraries have stabilized compared to the rapid development they were seeing when the admin UI was written. If we can get through this migration, it should get easier from there.

@tariquesani

This comment has been minimized.

Copy link
Member

tariquesani commented Sep 26, 2017

If someone can solve the current issues plaguing the admin and create a paginated searchable sidebar it would be the simplest way forward.

I would still like to see a redesigned workflow and a redesigned editor which can among other things accommodate flowblocks. At some point decoupling of admin from the server.

@nixjdm

This comment has been minimized.

Copy link
Member

nixjdm commented Sep 26, 2017

Certainly we can't get rid of the whole js build system, regardless. At least not without a ton of sacrifices.

@runfalk If we, and it's looking like mainly you, can correct some of the weird couplings and opaque state, then the current React admin will probably become much more accessible to me (and hopefully others) than I find it right now. I'm not that opposed to it, but at the moment I feel reliant on others like yourself to help achieve that. You're a bit ahead of the curve from me on this one.

@tariquesani Points out important scalability issues with admin and important enhancements we could make. Technically, these could probably be done before or after revamping how admin couples with the core of Lektor. I'm thinking it would be easiest to tackle those issues after the decoupling. If that's right, and agreed, then the first step would be to work on the decoupling. It seems like it's the most central design decision to me (apart from library) about all of this.

@runfalk

This comment has been minimized.

Copy link
Contributor

runfalk commented Sep 26, 2017

@nixjdm I can have a go at unwinding the current admin a bit. I just didn't want to commit to until I knew the state the project was in. It should be pretty easy to fit it into a redesigned API once that takes form.

@Jossnaz

This comment has been minimized.

Copy link

Jossnaz commented Sep 26, 2017

sounds awesome guys. I am looking forward to some improvements in the backend.

I was just looking at my admin interface and wondered how I'll explain to my client how he should use that sidebar to paginate through, currently, 3 pages, to find a record. With no indication what type the records are. He can use the frontend to press edit, but that doesn't work in all cases, e.g. not in the case where there is no actual display of the specific child record, e.g. we have pages where you click categorya and it lists all child records, you cannot jump into them though.

what would be important in my opinion is that it either really should fill almost all requirements one has to the admin interface or should allow some way to plugin your own code. Not sure how plugin friendly react is, but I don't think it really is plugin friendly is it? I mean plugin is life. Don't hate on me, but wordpress is big not because they have a good coding style, but because they have a lot of plugins and never really changed their way of doing things. They still have those 2000 actions and hooks from 2004.

personally, I didn't like angularjs back in the day, I doubt I am a big fan of react neither. But by all means, it would be good to see this project move forward. And with react native there is some initiative to learn react actually.

@nixjdm

This comment has been minimized.

Copy link
Member

nixjdm commented Sep 27, 2017

@runfalk It looks like we've got @tariquesani's agreement (from his thumbs up). You have mine. Please, take a whack at it :)

@Jossnaz

plugin is life

Yeah, basically. With the admin becoming more decoupled, we should be able to allow plugins that completely replace our admin with a custom one. @runfalk What do you think? Does it makes sense / is it feasible to have plugins into our admin, not as an outright replacement? I'm imagining someone not replacing the entire admin, but only a component, or extending it in a custom way. At the moment I don't see why that couldn't happen.

@tariquesani

This comment has been minimized.

Copy link
Member

tariquesani commented Sep 28, 2017

Yes @runfalk I would really like to see the admin being fixed and usable again. React or otherwise. Currently I am using only the build process of Lektor. Would like to do everything in Lektor (edit, view, deploy)

@runfalk

This comment has been minimized.

Copy link
Contributor

runfalk commented Sep 28, 2017

@nixjdm once the state of the admin is solidified I think exposing the possibility for limited plugins makes sense. By limited I mean custom field types for instance. Custom fields are the only area I can currently think of, are there others? I'm not sure if extending existing components is a good idea.

I also think it's a good idea to maintain an official list of plugins, maybe as a repository like Homebrew does it. If the plugin is not in that repository backward compatibility may suffer across major version releases. That way there is a list of plugins to test; maybe it can even be automated using the new Chrome and Firefox headless modes. I think saying we'll maintain full backwards compatibility in a language as volatile as JavaScript can hinder further development.

@goanpeca

This comment has been minimized.

Copy link
Member

goanpeca commented Sep 28, 2017

I also think it's a good idea to maintain an official list of plugins, maybe as a repository like Homebrew does it.

https://www.getlektor.com/docs/plugins/list/ maybe we could create a repo on this org with git submodules to these plugins?

I mean to generalize the repo for backend and frontend plugins?

@runfalk

This comment has been minimized.

Copy link
Contributor

runfalk commented Sep 28, 2017

The problem with maintaining a list on the official page is people might see it as recommendations or endorsement (even with a disclaimer). I didn't even realize there was a list like that. That list is perfect for this sort of thing and goes well together with the idea of eventually allowing plugin installation directly from the admin UI.

@tino

This comment has been minimized.

Copy link

tino commented Jun 17, 2018

Has there been any progress on this? I really enjoy the functionality and ease that Lektor gives, but I'm hesitant including it in bigger or more demanding projects because of the current limitations of the admin.

I'm still searching for a static site generator that has an admin interface that can stay up as an app. I'd also love to add/plug in a WYSIWYG Markdown editor to give non-technical users a nice way to add content with limited styling capabilities. I'm feeling Lektor is the ideal candidate, but as noted it's a bit to hard to contribute in the area atm.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment