starred/wiki

Fork 0

mirror of https://github.com/requarks/wiki.git synced 2026-03-02 22:57:36 -05:00

Abstracting the template from main project. #164

New issue

Closed

opened 2026-02-20 15:15:39 -05:00 by deekerman · 5 comments

deekerman commented

2026-02-20 15:15:39 -05:00

Owner

Originally created by @Bamieh on GitHub (Aug 25, 2017).

Originally assigned to: @NGPixel on GitHub.

I use python notebooks (jupyter) with pelican for my blog, and they have a great feature of the ability to extend the template or override it by having a src file in the root file of the running wiki.

This way the template can be abstracted from the main project, and allow the community to contribute in extra templates and endless features.

Basically a wiki project look into the folders of the project for a template directory, if its there one, it will use what is there. lets say i want to edit the css of the project, i will have something like

myWiki
├── config.yml
├── template
│   ├── style.css
│   ├── index.html

You can check jupyter projects or pelican themes for jupyter for example: https://github.com/getpelican/pelican-themes

Originally created by @Bamieh on GitHub (Aug 25, 2017). Originally assigned to: @NGPixel on GitHub. I use python notebooks (jupyter) with pelican for my blog, and they have a great feature of the ability to extend the template or override it by having a src file in the root file of the running wiki. This way the template can be abstracted from the main project, and allow the community to contribute in extra templates and endless features. Basically a wiki project look into the folders of the project for a template directory, if its there one, it will use what is there. lets say i want to edit the css of the project, i will have something like ``` myWiki ├── config.yml ├── template │ ├── style.css │ ├── index.html ``` You can check jupyter projects or pelican themes for jupyter for example: https://github.com/getpelican/pelican-themes

deekerman

2026-02-20 15:15:39 -05:00

closed this issue
added the
enhancement

deferred
labels

deekerman commented

2026-02-20 15:15:42 -05:00

Author

Owner

@NGPixel commented on GitHub (Aug 28, 2017):

Interesting idea. Something similar could be implemented in 2.0 however it will likely not be disk based as your example. Users could instead enter their template / css / js code via the UI.

@NGPixel commented on GitHub (Aug 28, 2017): Interesting idea. Something similar could be implemented in 2.0 however it will likely not be disk based as your example. Users could instead enter their template / css / js code via the UI.

deekerman commented

2026-02-20 15:15:42 -05:00

Author

Owner

@Bamieh commented on GitHub (Aug 28, 2017):

@NGPixel i can start working on it, but can you clarify by what you mean exactly that they enter their code via the UI?

Here are some thoughts i have:

It would be nice to have the user npm install a template package for wiki.js, and say use this one in the config.yml.
Writing code inside the UI is not that nice, because developers love their personal editors, also it might raise unexpected bugs.
Why do we want it in the UI? since the template should not be a runtime thing, it should be modified during the build/maintenance of the personal wiki, rather than during runtime.
Removing the template code from the main repo will be a very good move. It will make it easier for those who want to contribute to the project (project learning curve, less setup, more specific). Also it will allow people to contribute with their own templates, or customize the default template without having to clone the repo and hack it.
I find the disk case really nice, since it can be pushed to github with the project, its easy to understand what is going on without reading any documentation aswell.

@Bamieh commented on GitHub (Aug 28, 2017): @NGPixel i can start working on it, but can you clarify by what you mean exactly that they enter their code via the UI? Here are some thoughts i have: - It would be nice to have the user npm install a template package for wiki.js, and say use this one in the `config.yml`. - Writing code inside the UI is not that nice, because developers love their personal editors, also it might raise unexpected bugs. - Why do we want it in the UI? since the template should not be a runtime thing, it should be modified during the build/maintenance of the personal wiki, rather than during runtime. - Removing the template code from the main repo will be a very good move. It will make it easier for those who want to contribute to the project (project learning curve, less setup, more specific). Also it will allow people to contribute with their own templates, or customize the default template without having to clone the repo and hack it. - I find the disk case really nice, since it can be pushed to github with the project, its easy to understand what is going on without reading any documentation aswell.

deekerman commented

2026-02-20 15:15:42 -05:00

Author

Owner

@NGPixel commented on GitHub (Aug 28, 2017):

The main case for entering template code via the UI is to save it to the database + not having to restart the app on every change.

The issues with disk based templates are 1) If you run multiple instances (distributed on multiple servers), you'd have to copy your templates to every server as well. 2) Very difficult to use disk based templates in containers like docker or heroku. You'd have to clone a repo, make the changes and redeploy the container every single time.

That being said, having both options is totally possible.

@NGPixel commented on GitHub (Aug 28, 2017): The main case for entering template code via the UI is to save it to the database + not having to restart the app on every change. The issues with disk based templates are 1) If you run multiple instances (distributed on multiple servers), you'd have to copy your templates to every server as well. 2) Very difficult to use disk based templates in containers like docker or heroku. You'd have to clone a repo, make the changes and redeploy the container every single time. That being said, having both options is totally possible.

deekerman commented

2026-02-20 15:15:42 -05:00

Author

Owner

@Bamieh commented on GitHub (Aug 29, 2017):

sounds good, its easy to implement both options i believe. i'll start working on it this weekend

@Bamieh commented on GitHub (Aug 29, 2017): sounds good, its easy to implement both options i believe. i'll start working on it this weekend

deekerman commented

2026-02-20 15:15:42 -05:00

Author

Owner

@NGPixel commented on GitHub (Oct 21, 2017):