This is the third big change of this idea. It’s a “back to basic” approach. I even got some history of why I started over again…
Thoughts behind the complete rewrite
Splitview failed
My first approach was called Splitview. It failed because I did everything from outside the panel. I simply could not keep track of everything that was happening in the panel when the urls changed. It caused many problems.
Reveal 0.2 failed
My second approach was Reveal 0.2. It included ajax and other fancy stuff. It was an extended textarea field. The plugin could only previewed textareas, not other fields. It also went a bit overhead with css and javascript in order to work well.
Current state
After some time and thought, I have come to a conclusion that if it’s going to be done correctly, the whole page needs to be previewed and take all fields into account. By not only targeting the textarea would make it possible for any field to be previewed.
In this version there are no options and no ajax. It refreshes on save or refresh.
Ajax in the future
I still have in mind to include ajax again. This time my idea goes around the $_SESSION where all the temporary fields are stored. The problem is that I can’t manipulate an already created page object which I want to do to replace the fields. If I could do that I could use this function to generate the page: https://github.com/jenstornell/kirby-secrets/wiki/Snippet-preview
Therefor I’ll wait with Ajax for now. The field still works without it, but you need to save to see the changes.
It’s true that I still have some difficulties to send a force a language to the preview class. I plan to get back to it when I have more knowlage of how it works. What should happend now is that the preview does not preview correctly in multi languages sites, not a change in design or layout like the screenshots above.
What is this? It looks like it’s generated from a browser extension or perhaps a Kirby plugin? It’s not a part of Kirby Reveal.
I thought about the AJAX and data saved in session stuff (kirby sends and saves data in session on every keystroke you make in the panel)…
It would be possibile to extend the response or the template component and inject this session data into the template to create some kind of a “preview mode”.
This would enable you to put the previewing site into an iframe. And that would reduce the complexity of isolating the previewed content a lot (you wouldn’t have hamburger menus wandering around in the panel). It could even mean that we could create a real “preview mode” where an admin would see the whole site with contents that aren’t saved and published yet (but are only in his session).
The problem is that data doesn’t only come from the $page variable in a template.
Just think about a page that shows contents of other pages (a common usecase would be showing news articles in a homepage) or file metadata…
That content could only be injected by extending the “Content” class. But Kirby doesn’t let you to do this. Not until it decouples the “data is stored in files concept” from the kirby core. Which might never happen, since on the homepage it says “Kirby is a file-based CMS”.
It would be possibile to extend the response or the template component and inject this session data into the template to create some kind of a “preview mode”. This would enable you to put the previewing site into an iframe.
Yes, that is exactly what I do with this plugin, sending the session data to an iframe.
It also works with template stuff like controllers, pages methods etc, because I extend the template class.
