Proposal: silverstripe-stride

[zanderwar]

silverleague/silverstripe-stride

Why?

Occasionally you may be required to provide a client with a safe way to modify CSS, Javascript and/or .SS template files, but don't want to provide FTP access for example, this module would add a LeftAndMain interface which would scan the /themes/ directory and index the files within which can be then edited directly through the CMS.

The module would be fully permissive, that is if you only wanted to allow the end user to edit CSS, Javascript, and/or Templates etc you could do so via CMS permissions or even a YAML configuration.

Whats the name mean?

Stride is just a play on words and really is just Stripe and IDE conjoined

Details

This module will provide an interface for end-users to modify their theme-related files directly within the CMS

Functionality

• [x] Ace Editor Implementation into a CMS LeftAndMain subclass.
• [ ] Permissions to Edit, View existing files and to Create new files
• [ ] Create CSS files
• [ ] Create Javascript files
• [ ] Create SS template files
• [ ] Indexing for template functionality. E.g. $ThemeEditorJS and $ThemeEditorCSS to pull in all requirements(?). New templates can just be added using the <% include File %> template tag that already exists, or maybe a custom Requirements backend that does this on-the-go
• [ ] Create new CSS, JS and Template Files (.SS)
• [ ] Ability to have multiple files open at once (some rather straight forward JS to accomplish this)
• [ ] Capture Cmd + S / Ctrl + S and save
• [ ] Warning for leaving the page with unsaved files
• [ ] Flush on file save
• [ ] Flush on "create template"
• [ ] Blame History
• [ ] Rollback Functionality

Suggestions

• "Create New" from a predefined template (ie navigation menu etc)
  • We can populate this from a public repo using any number of means
  • Subclass detection of Page and offer where appropriate
• Custom Ace Editor syntax highlighting for SS template files
• Support for an existing community module that provides a Requirements backend for a PHP CSS pre-processor

[robbieaverill]

What kind of in-browse IDE would we use for this? CodeMirror seems like a pretty common option.

[zanderwar]

I've had great experiences with implementing Ace Editor could put it to a vote

[Firesphere]

Ace looks good

[andrewandante]

I've seen this kind of thing somewhere before. Main concern is that your theme is no longer stored in git. Which is odd.

This is the one I have seen: https://github.com/silverstripe-archive/silverstripe-dynamictemplate

However, I see the use case. +1 for Ace, used it for a Yaml field before. I forked another module:

Original: https://github.com/nathancox/silverstripe-codeeditorfield Mine: https://github.com/andrewandante/silverstripe-codeeditorfield

Need to make that PR. Oops!

[zanderwar]

Thanks for the CodeEditorField, It's been tightly coupled with the POC I'm working on at the moment, have updated it to be compatible with SS4 and cleaned it up quite significantly. Credit is given to the original author(s)

[madmatt]

I don't know that editing files on the filesystem is a good idea. In any multi-server environment this won't work and will end up being inconsistently applied - as well as the issue that then your UAT and production environments are different, and neither of them are built from a common source (version control system).

Even if you you add a system like Drupal Features that make these a bit easier to export and re-apply to other environments I think this isn't the greatest option. At the very least, it needs to be really clear that a template on-disk has been modified.

Perhaps the better option that modifying files in place is to store templates in the database, and allow database templates to override local files if they exist. That way the physical codebase doesn't change, you avoid concurrency/multi-server issues, and as long as it's clear where a template has come from (e.g. adding a URL variable to enable SSViewer.source_file_comments and indicating overridden templates) it would make it easy for developers to figure out why any changes they make aren't working.

[Firesphere]

Perhaps the better option that modifying files in place is to store templates in the database, and allow database templates to override local files if they exist.

I think there's a module that does exactly that. Allowing "inline templates" to be built from given. https://github.com/nyeholt/silverstripe-usertemplates I think does that.

[Firesphere]

Also, in addition to @madmatt his comment. The changes won't reflect in a VCS repository, thus be overwritten on the next deploy, possibly causing frustration, confusion, anger and all kinds of other things.

[robbieaverill]

I think DB based template overrides would make sense. I think this proposal initially was focussing on the "editing templates" more than where to save them, but agree that not editing files on the server is a good plan

[Firesphere]

I would reject in favor of possible DB changes recorded.It is too sensitive and not taking VCS into account.

Further updates fixing this are up for reconsideration of course.

Idea/Concept: Good Execution: Needs some work

[robbieaverill]

It is too sensitive and not taking VCS into account.

I believe the original idea was to let you mock stuff up on the server and export as a diff patch (takes VCS into account).

I don't see much point in rejecting a proposal that's in progress - we should just amend the scope to say "it should store modified templates in the DB" and "it should use DB templates in a higher priority than those in the template manifest where they exist"

[Firesphere]

Valid. Agreed on that.

What does concern me however, is still VCS. If a template changes, but is loaded from DB because DB overrides actual templates, confusion/anger etc. may still occur. For me to agree I would need a way to set that straight.

[robbieaverill]

That's a good point - perhaps the DB record needs to store the object hash that it was based from so we can compare in say a GridField view of DB templates and notify the user when it has diverged from the source.

[Firesphere]

That would cover most of it. But that's a "probably", not a "yep, would do". I'd like to hear @zanderwar his thoughts on the issue at hand?

[zanderwar]

Yes, altering files directly was always a frowned upon approach, however regarding this module, the working POC would do exactly that and then promptly move to a versioning based/DB system instead.

Even which I'd imagine it'd be a mix of DB storage and direct file manipulation, where the original would always be stored in DB along with any subsequent versions. The file itself would always have the latest version and we can just opt to call dev/build?flush=1 functionality rather than integrating our own methodology to override templates albeit looks simple enough given the usertemplates module linked above. (Could even go as far as file based versioning system)

I'd imagine irregardless the module would need to be shipped "at your own risk" as this module is intended for the dev-savvy, not the average content editor.

Which reminds me, I need to get that POC out :1st_place_medal:

[robbieaverill]

I'm guessing this lost traction - is anyone still keen on getting it going?

[robbieaverill]

There's some similar movement in this area here: https://github.com/mikenz/silverstripe-codeeditorfield

[robbieaverill]

Also not the same, but similar enough to be worth pointing out: https://github.com/tractorcow/web-console

cc @andrewandante @zanderwar - if you guys aren't keen to get this going I think we'll close it in the next couple of weeks

[andrewandante]

My SilverStripe dev time has plummeted of late for obvious reasons. I'm not going to be able to kick it off.

[robbieaverill]

@andrewandante no worries. @zanderwar still keen? Let's close it if not