Skip to content
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

[Work In Progress] Sculpin Browser-Based Editor #443

Draft
wants to merge 28 commits into
base: main
Choose a base branch
from

Conversation

beryllium
Copy link
Member

This project suggests a way for making a browser-based editor part of the Sculpin --serve flag. This might be one inroad for making Sculpin more approachable for folks.

However, other directions are also possible, so additional review from project administrators is requested to ensure that we choose the best direction forward.

Those other directions could include an app-based editor that runs Sculpin internally, saving users from CLI complexity, and/or expanding Sculpin's support of data sources to include API-based CMS-as-a-service platforms.

Changes

This new editor mode hooks into the --serve mechanism in dev mode and detects outgoing HTML files. Then, it injects a payload into the footer of the HTML which contains the web editor interface. Via an exposed route in the server module, it allows incoming edits to be persisted to disk.

The JS for the editor aims to have zero dependencies so it can be directly injected with minimal complexity.

The whole thing is very much only a proof-of-concept, but I wanted to put it into PR since it's been sitting on my system for a while with no time for improvements. I need to understand if it's a viable path forward before I spend additional time on it.

- Modifies HttpServer output to inject editor JS
- EditorJS creates textarea/button for editing and saving

TODO:
- CSS
- Listen for PUT and securely verify & apply changes
- Maybe a hash to make sure nothing will get obliterated?
- Maybe local storage to make sure nothing is lost if user navs away?
- Use async XHR or form submit instead of sync XHR
@dragonmantank
Copy link
Member

I like this as a first step (though it doesn't seem to actually edit the file). I just tried it with a simple basic site, not anything I'm using in Production, but I will do that soon.

Those other directions could include an app-based editor that runs Sculpin internally, saving users from CLI complexity

I'd rather just have it open a browser window to the address directly as a first step. I don't see the need to have a separate application to do this.

and/or expanding Sculpin's support of data sources to include API-based CMS-as-a-service platforms.

This is actually something I've wanted to do with Fillet for a long time, especially now that Wordpress has a very nice API and Drupal's has gotten better. I do know that there is a use-case for having Wordpress as the CMS backend to handle users and editing workflows, and using a static generator to extract and publish the actual content. Fillet is already set up to take a data source and convert it to markdown, so maybe an update and expansion to it is in order?

@dragonmantank
Copy link
Member

Just removing myself to clean up my PR request list

beryllium and others added 17 commits June 24, 2020 00:03
- Reads the contents of the supplied manifest file and returns an array
  to be exposed as a Twig global variable
- If the parameter is found & exists on disk, the WebpackEncoreHelper
  will expose its contents as an array in Twig files
- Typically this would be a relative path to the source dir that is
  declared in `app/config/sculpin_kernel.yml`
  e.g.,

  sculpin_twig:
    webpack_manifest: build/manifest.json
- Also includes composer create-project example commands
This is intended to address the fact that eyes just aren't where they
used to be, so users should be directed to Twitter and to the GitHub repo.
Yes, the removed projects (Octopress, Hyde, Phrozn, Pie Crust 1 & 2)
were important for the beginning of Sculpin, but it does not serve
potential users well to direct them to projects that haven't been
updated in 5 years or more.
- Modifies HttpServer output to inject editor JS
- EditorJS creates textarea/button for editing and saving

TODO:
- CSS
- Listen for PUT and securely verify & apply changes
- Maybe a hash to make sure nothing will get obliterated?
- Maybe local storage to make sure nothing is lost if user navs away?
- Use async XHR or form submit instead of sync XHR
@beryllium
Copy link
Member Author

Somehow a bunch of extra commits have snuck in (isn't git adorable?), but anyway, I've applied some updates here that take a more dynamic approach to updating content and ensuring the changes have been processed before the updated page is loaded. So now editing should actually feel like you've succeeded at editing.

- This is a hacky attempt to prevent an infinite polling loop
  when checking for hash changes that will never happen (because the
  content is identical).
- The infinite polling loop could still occur if a whitespace change
  is made that gets trimmed out in the markdown processing.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants