Serendipity Forums

Hmm, should I change the Subject of this thread? (not sure if I can)

Sorry for the confusion.

u1amo01 wrote:Hmm, should I change the Subject of this thread? (not sure if I can)

Nah, it's all good. I already created a GitHub issue for this.

YL

garvinhicking wrote:Speaking of that, I faintly remember someone (onli?) already created some proof of concept for it?

serendipity_event_autosave_local, stores the entry in the local browserstorage and is a superior concept. Needs testing though. Current version in http://board.s9y.org/viewtopic.php?f=4&t=19368.

Cool. Seems we'd have a tester?

(Still would love to have this in our actual core rather than a plugin - I'd still say now is the time to introduce this, rather than later?)

Yes, that'd be nice :)

garvinhicking wrote:(Still would love to have this in our actual core rather than a plugin - I'd still say now is the time to introduce this, rather than later?)

I actually couldn't wrap my head around how to integrate this soundly, as the event-hooks are pretty integral to the concept right now. Maybe I'm too close, could you have a look?

onli wrote:Yes, that'd be nice

garvinhicking wrote:(Still would love to have this in our actual core rather than a plugin - I'd still say now is the time to introduce this, rather than later?)

I actually couldn't wrap my head around how to integrate this soundly, as the event-hooks are pretty integral to the concept right now. Maybe I'm too close, could you have a look?

Maybe you could use the internal core hooks for that, like defined in include/plugin_api.inc.php:
This is what the core also uses for frontend_header and backend_header currently to inject jquery at places where event plugins are usually called. You could outsource this on its own file in include/plugin_api_autosave.inc.php or so to capsulate it...?

HTH,
Garvin

I tested the serendipity_event_autosave plugin with 2.0-beta and the new backend. I did not dig in deep, just tried to get it to run and see if it autosaves an entry.

Conclusion: It doesn't work anymore. It is the cause for some JS errors in the entry view, whether WYSIWYG is enabled or not. That pretty much breaks everything in the new backend.

The plugin's JS is hard to read (for me, at least, even if I've seen worse).

So, yes, maybe we should look for a different solution and deprecate this plugin for 2.0 (is there a way to deprecate plugins or restrict their usage to versions < 2?).

Mattsches

PS: If there was a way (in Spartacus?) to deprecate plugins that are too old, we could get rid of some other legacy stuff, too. E.g. serendipity_plugin_zooomr is a plugin for a service that doesn't even exist anymore. Another idea would be to manually move outdated plugins to a "archived_plugins" repo so that the code isn't lost, but they are removed from Spartacus.

Just to mention it:
At least for the WYSIWYG-Editors the serendipity_event_autosave plugin didn't work in 1.7 (and prior?) too. For the CKEDITOR Plugin I suggested (http://board.s9y.org/viewtopic.php?f=4& ... #p10435691) to use a CKEDITOR Plugin for this.

Maybe we can find a solution that is editor agnostic and works even for non-WYSIWYG editors. I haven't checked out onli's approach yet, but from what I read in the corresponding thread this could be a possible solution.

Mattsches