The Editor
At its core the concept of the editor is a dynamic documentation system. In that it lets you view, manipulate, tweak, and even create individual components of the theme all within a simple to use user interface. It provides the ability to both view and modify the twig code and the CSS. Furthermore because the CSS is built using SCSS it allows for the creation and editing of variables directly on the page. Important note is that this is its own full fledged self contained app.
The Backend (Backend DEV)
Under the hood the editor will require several libraries across several different techs to make everything work. Since the editor is essentially building the page views based on reading the template files directly this requires strict formatting of the SCSS files via @ hooks. The backend can be coded in either PHP or NodeJS and really is just performing static file based DB operations using the file read/write functionality. It will read all the files and build the required API for which we can then construct the interface.
NodeJS will be required however for the build phase of the theme which is why I would prefer everyhting to be done in NodeJS or simplicity. We will need to include scss and twig(nunjucks Twig equivalent with cusstom extensions to fill in any needed gapped functionality is backend is NodeJs based) rendering in the front-end to render the scss and twig on the fly in the editor.
The structure required for the all folder is as follows
- All
- CSS
- theme.css
- JS
- SCSS
- settings
- tools
- objects
- components
- theme.css
- TWIG
- IMG
- CSS
- Second Theme
- CSS
- theme.css
- JS
- SCSS
- objects
- components
- theme.scss
- TWIG
- IMG
- CSS
Required Configuration:
- need to be able to point to and read/write to a local phpbb install via an option? So set path for styles folder. If not then all should be provided and will not be editable!
- needs to be installable
- needs to be lockable in that if its setup on a server and hosted we need to be able to configure it to not be able to edit global but instead convert to theme and edit.
- array: settings, base, objects, components, theme
- get list of themes: (route /themes) - should ignore all folder
- get file tree: (route /tree)
- returns obj similar to the following
- settings
- base
- each file in all/scss/base
- objects
- each file in all/scss/objects
- components
- each file in all/scss/components
- “theme”
- objects
- each file in “theme”/scss/objects
- components
- each file in “theme”/scss/components
- theme
- each file in “theme/scss/theme
- objects
- returns obj similar to the following
- get specified scss file contents: (route /“folder”/“filename”) where folder is either all or “theme”
- returns object like such:
- name
- description
- settings
- each layout with its value
- each theme setting with its value
- scss code
- twig code from corresponding twig file (if scss file is from all folder than twig file is in all/twig, if scss file is from “theme” folder than twig file is from “theme”/twig)
- returns object like such:
- put settings (route /update/settings)
- updates settings in specified specified scss file
- put name (route /update/name)
- renames specified scss & twig file
- updates name in header of specified scss file
- put description (route update/description)
- updates description in specified scss file
- put scss (route /update/scss)
- replaces the scss in specified scss file
- put twig (route update/twig)
- replaces the twig in specified twig file
- create(name, theme, layer) (route /add)
- makes new scss file using local generic template var for contents
- makes new empty twig file
To provide all the interactivity required we will use VueJS(better than AngularJS) to handle all the AJAX based CRUD routing calls.
We will require some jquery for the scaling functionality
We will also leverage some third party libraries for the editor interface.
Additional Possible Requirements
Will probably need some mock phpbb JSON for the editor to use to render the TWIG
Hopefully I have covered everything, I will update this as the discussion/progression moves forward. I will say that the backend can be coded in php to speed up the work on it, but think that at somepoint it should be converted to node if so as its easier to work with one coding language not to mention the fact that its a front-end tool and will no doubt attract front-end devs to help maintain it.
