Serendipity Forums

Discussion thread for https://github.com/s9y/Serendipity/issues/94

The request is to have a mechanism to see whether updates are available. I see this mechanism:

That might actually be a bit complicated. At a specific point in the backend (opened dashboard? plugin page?), we'd need to let spartacus do a plugin upgrade check. If there are upgrades, we'd have to set a (setings?) variable. If that variable is set, we'd show the update buttons in the dashboard and mark the update buttons in the plugin page (design might differ).

But I do not see a good execution point for that check. Has someone an idea how to get that feature?

onli wrote:

At a specific point in the backend (opened dashboard? plugin page?), we'd need to let spartacus do a plugin upgrade check.

But I do not see a good execution point for that check. Has someone an idea how to get that feature?

I think it should be both – before showing the dashboard (because it now is a central hub for info about the blog) and before showing the plugins page. Those are the two places in the backend where one would expect to be notified about plugin updates.

We might want to think about adding another point to the Maintenance section, though.

YL

That is not what I mean. The buttons could be anywhere, but yes, I agree that those are the good places :)
But s9y has to know that upgrades exist. For that, spartacus has to run a "are there upgrades" function. I do not see where and how to add that call.

In the dbcron plugin and start bundling that with the core?

We could very easily check, if files https://github.com/s9y/additional_plugi ... Sevent.xml (or package_sidebar.xml) were changed by an Automagic XML sync, compared to last check of the backend tasks.

That would give us a hint about something having changed.

Then run a loop with (fakecode) which would give us the plugin being updated etc.

Then we could check if an old version of this plugin is installed and let the upgrade Button(s) pop up to run spartacus on clients demand.

Couldn't we?!

Depends on how much time it takes. The network call alone make it impractical to run this on each dashboard load for example.

Apart from that yeah, that sounds possible (and about what spartacus would do for us)

That does not really make a difference, I can tell from my experiences (since I am currently playing around with a rss feed test plugin for the dashboard, which hasn't even got a cache for a day option yet).
And this cache for a day would be the one in favour -like for the autoupate and dashboard check.

The XML parsing could take a lot of time. If we just want to try it out on dashboard open, we will see how much it costs. I'm okay with trying.

We could start the update fetch in an ajax call. That way, the load time of the dashboard won't be any longer than before.

onli wrote:We could start the update fetch in an ajax call. That way, the load time of the dashboard won't be any longer than before.

Personally I would prefer for it to work like this:

First, the spartacus plugin gets its own event like "crontab_check_sidebar" and "crontab_check_event" (or even only one), and this would simply execute the same features like we currently to do list the available plugin updates.

Second, we enhance the actual execution of the spartacus plugin, so that when it is performed, we create/update a new temporary database table (or extend the serendipity_pluginlist DB table) and permanently store the results of the last update. It might even already do that currenty, but I couldn't check right now.

Third, we add a new event to list the temporarily stored remote plugin version updates, and this event could be triggered by the dashboard and other places. Since we'd do no remote checks, that should work quickly.

Fourth, we add the two crontab functions to our dbcron plugin so that regular update queries can be performed at convenient times.

Fifth: Do what I did testwise.
Take what we have already and use it in a new plugin. Shall I paste that testwise to 2.1 plugins?

Timbalu wrote:Fifth: Do what I did testwise.
Take what we have already and use it in a new plugin. Shall I paste that testwise to 2.1 plugins?

Not sure what you mean? Duplicate spartacus code as a new plugin? I think we should do it properly, and not by duplicating spartacus code...

No. Not duplicate. Read: USE spartacus code (spartacus_remote) very nice!

Ah, I see. Yeah. Completely forgot about this one. We then already have a stub for this, yay. However the performance of this would suck, we'd definitely need an intermediate cache to not fetch and parse the XML time and again...

Got that already. Set to 6 hours. Its not really an XML, it is a plain txt file, which could even be made more simple for this case.

The culprit for my plugin is, you have to have activated the spartacus plugin and have to allow that option yourself. I don't think that dependency is too bad, since you have to want this feature in the dashboard by installing this plugin to the Dashboard.