I strongly discourage using PlusKit to import Stacks pages into Stacks. Many things will not work at all. Some will work strangely.
PlusKit is built to import simple pages – pages with basic content and a few assets.
PlusKit warns against importing complex pages (like Stacks) – right inside the plugin setup.
Honestly, I really really want to just make this impossible, but too many people complained when I beta tested that – so here we are.
But seriously, just don’t do it.
Use partials. Or even externals editing in separate files. If editing a sub-page in its own file is STILL too slow, then it’s not RW or Stacks or your project or you – it’s time to demand that the Stack developer put some more effort in to speeding up edit-mode.
As a total aside, I’ve been considering attacking this sort of edit-mode performance things head on. Here’s my current brain-dump on that at the moment… feel free to ignore – and don’t respond here – it’s entirely off topic. If you have questions or comments about this, start a new thread. 😃
OK, let’s do this…
Most of the issue comes down to putting too much CSS/HTML into edit mode’s web view. Of course Edit mode was meant to be a simplified, style-free tool for composing the layout of your page – just enough style to guide you – leaving everything else for Preview mode. Of course everyone likes to see a bit more WYSIWYG preview in there too – and stack devs try to please… so after a decade of pleasing results are: stack developers try to force as much of preview-mode into edit mode. It looks nice, but it’s pretty slow – unless you have a blazing fast machine editing a big page or one with a few complex stacks can be frustrating.
There are various ways I can skin this cat:
- do only partial loading of just what you see on the screen at the moment
- limit the api to exclude the costly stuff
- add another new layer of fast-editing (this time for sure Rocky)
- etc.
partial loading
partial loading seems like a nice idea – but it only buys so much. frameworks like foundation/foundry/etc. load a heap of CSS at the top of the page and expect it to apply to the stacks at the bottom of the page – so partial loading would either have to account for that (in which case we haven’t really helped much) or force the frameworks to do some painful redesign.
honestly, i don’t see this solution as having any legs in the current ecosystem.
limit the api for edit mode
i did this a bit years ago – but developers resist it. i cut out a VERY slow API feature called “repeat” and told developers it would go away “soon” – and they should stop using it. That was about 7 years ago. there are stacks still being released that use the feature. in order to really make a dent on performance, i’ll would have to seriously chop – and that just seems nearly impossible. Developers won’t stop until they’re forced – and that means hurting customers which I’m loathe to do ever.
i’ve considered putting a big, high-profile, switch on the edit mode UI that just chops out most of the CSS – but controlled by the user. this would, at the cost of making edit mode very bland, radically speed things up. but i know if i do it that developers will start hiding styles inline within the HTML. so it’s probably just a temporary fix at best. i can combat that with some filtering. it would be a game of whack-a-mole.
despite these downsides, i still think there are potentials to this methodology. some combinations of limitations, filters, and user-controlled “enable fast mode now” switches seems like it could at least be a partial solution.
a fast edit-mode
since our nice once upon a time fast edit-mode has turned into a barely-faster-than-preview mode, it might be a good idea to make a really-really-i-mean-it-this-time-for-sure-edit mode. something that didn’t include any CSS – or maybe some hugely limited styling – or maybe just a plain vanilla source-list view of all the stacks – no layout, no style, no nothing – just rely on jumping over to preview or the RW simulator for seeing the results of your edits.
Of course none of those things, on its own, sounds too great either. Editing your stacks in a list-view seems only one step up from HTML. But again, maybe in combination with other solutions it might work?
I’ve probably already decided on which direction I’ll take Stacks, but since these forums seem to be scraped by the less-original amongst the competitors looking for feature ideas – i have to just let everyone guess at what that direction will be. 😉