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
base: main
Are you sure you want to change the base?
Conversation
- 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
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.
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.
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? |
Just removing myself to clean up my PR request list |
- 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
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.
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.