Spartacus Plugin update noter

[Timbalu]

Hi Garvin and all

I just noticed a behaviour I did not expect to be like that (and I wonder no one has ever complained about it, including me ).
2 days before, I commited a new version to the staticpage sidebar plugin. The xml-sync with GitHub went through well, but did not appear in in the Spartacus-online-updater yesterday (neither in plugin nor event). Therefore I bumped the version number of the event plugin too, to get this into the pipe.

Todays Spartacus NEWly updated packages showed up in 'package_event_de.xml' only, but not, as expected, (also) in 'package_sidebar_de.xml'.

If this isn't some syncro error, this 2-day-event behaviour tells me, the "new sidebar plugins available" button is useless in this context. Shouldn't we drop it and rename the other one to something short, like "Plugin updates", if this is the intended behaviour?

[garvinhicking]

Hi!

Which package_sidebar_de.xml file did you check? Usually the XML files get completely rebuild every day, with all versions that are currently in CVS.

Regards,
Garvin

[Timbalu]

What do you mean?
I have the default set to netmirror, but the behaviour does not change if i choose something else.
I just checked the 2 xml syncs, which look fine. I expect this must be something in the spartacus script itself.

[garvinhicking]

What do you mean?
I have the default set to netmirror, but the behaviour does not change if i choose something else.
I just checked the 2 xml syncs, which look fine. I expect this must be something in the spartacus script itself.

Then I don't understand what you mean. I thought you said your new plugin version did not show up in the XML, but now you say it does?

[Timbalu]

please read again ... I'm afraid I can't explain more precise..., while I am talking about
my 'Neue Versionen von Seitenleisten-Plugins' & 'Neue Versionen von Ereignis-Plugins' button-click experience on xml-sync overnight, not the XML itself.
Simply I wanted to say "~...the sidebar updater is empty".
If this is intended, why do we have it?

[yellowled]

Are you saying it behaves as if updates are available, but it doesn't show any results in the list of of updateable plugins?

YL

[Timbalu]

yes, exactly! Do you have differing experiences?
So the xml.sync endet up telling spartacus to show these buttons (always both of them). This is correct, as there are updates available.

Now, in the case there was a sidebar-plugin GitHub commit only, well referenced and incremented by version, neither a plugin nor a event plugin shows up in Spartacus, but the update buttons do appear(~I can't proof this, as I always have some updates waiting while developing). We know this usually, but I forgot to do so. That is why we have to bump the event plugin version too, which I did the second day.

But then the updated plugin only shows up inside the Spartacus-event-button context, even if there is an updated sidebar plugin available. This is enough I expect, as updating the event-plugin will also handle the plugin update (possibly?~!). We all know what to do..., but John Doe might expect a plugin inside the link context of the buttons. This is the reason why I dared to ask, to get rid of the sidebar plugin update button, (if this isn't an error!), as it is useless, if not really used.

I am not sure we ever had this, if this is intended, an unsolved spartacus issue, or anything else.... my last sidebar plugin update is ages ago... (I tried this with two differing installations, so the chance I have a crude spartacus file in both is minimal).

[yellowled]

Do you have differing experiences?

Can't say I have ever seen what you describe.

YL

[garvinhicking]

Hi!

The XML of a server is also cached on your client side! It is not fetched on every request. I believe the timeout could even be a config option of the spartaus plugin. This could cause a difference in the XML of a maximum of 2 days in the worst case!

Regards,
Garvin

[Timbalu]

The XML of a server is also cached on your client side!

but it gets erased and newly created when changing the fetching server, which I did before, so this can't be. And todays check is simply the same.
Were you happy to see any sidebar plugin updates in the 'new sidebar plugin button' context (ever)?
I immediately shut up, if you tell me this is normally working in any of my explained two case scenarios.

[garvinhicking]

Hi!

I do not use the spartacus plugin, so I am not able to tell you if that works or not. Also - I do not understand your problem then. Maybe describe it in german.

Best regards,
Garvin

[Timbalu]

That should not be a language problem.... (hopefully!)

Button: Neue Versionen von Seitenleisten-Plugins Button: Neue Versionen von Ereignis-Plugins

A print_r($eventData) in Spartacus gives me :

Code: Select all

[2] => Array
    (
        [0] => /var/www/test/serendipity/plugins/serendipity_event_staticpage/serendipity_event_staticpage.php
        [plugin_file] => /var/www/test/serendipity/plugins/serendipity_event_staticpage/serendipity_event_staticpage.php
        [1] => serendipity_event_staticpage
        [class_name] => serendipity_event_staticpage
        [2] => serendipity_event_staticpage
        [plugin_class] => serendipity_event_staticpage
        [3] => serendipity_event_staticpage
        [pluginPath] => serendipity_event_staticpage
        [4] => Statische Seiten
        [name] => Statische Seiten
        [5] => Verwaltet beliebige statische Seiten innerhalb des Blogs mit dem Blog-Design und allen Formatierungen. Fügt einen neuen Menüpunkt in der Admin-Oberfläche hinzu!
        [description] => Verwaltet beliebige statische Seiten innerhalb des Blogs mit dem Blog-Design und allen Formatierungen. Fügt einen neuen Menüpunkt in der Admin-Oberfläche hinzu!
        [6] => 3.91
        [version] => 3.91
        [7] => 3.92
        [upgrade_version] => 3.92
        [8] => event
        [plugintype] => event
        [9] => local
        [pluginlocation] => local
        [10] => 0
        [stackable] => 
        [11] => Marco Rinck, Garvin Hicking, David Rolston, Falk Doering, Stephan Manske, Pascal Uhlmann, Ian
        [author] => Marco Rinck, Garvin Hicking, David Rolston, Falk Doering, Stephan Manske, Pascal Uhlmann, Ian
        [12] => a:3:{s:11:"serendipity";s:3:"1.3";s:6:"smarty";s:5:"2.6.7";s:3:"php";s:5:"4.1.0";}
        [requirements] => Array
(
    [serendipity] => 1.3
    [smarty] => 2.6.7
    [php] => 4.1.0
)

        [13] => http://board.s9y.org
        [website] => http://board.s9y.org
        [14] => 1335083682
        [last_modified] => 1335083682
        [15] => BACKEND_FEATURES
        [category] => BACKEND_FEATURES
        [groups] => Array
(
    [0] => BACKEND_FEATURES
    [1] => BACKEND_EDITOR
)

        [upgradable] => 1
        [customURI] => &serendipity[spartacus_fetch]=event&serendipity[spartacus_upgrade]=true
        [installable] => 
        [local_documentation] => plugins/serendipity_event_staticpage/documentation_en.html
    )

[/size]
inside 'new versions of event-plugins' and

Code: Select all

[16] => Array
    (
        [0] => /var/www/test/serendipity/plugins/serendipity_event_staticpage/serendipity_plugin_staticpage.php
        [plugin_file] => /var/www/test/serendipity/plugins/serendipity_event_staticpage/serendipity_plugin_staticpage.php
        [1] => serendipity_plugin_staticpage
        [class_name] => serendipity_plugin_staticpage
        [2] => serendipity_plugin_staticpage
        [plugin_class] => serendipity_plugin_staticpage
        [3] => serendipity_event_staticpage
        [pluginPath] => serendipity_event_staticpage
        [4] => Liste der statischen Seiten
        [name] => Liste der statischen Seiten
        [5] => Dieses Plugin zeigt eine konfigurierbare Liste der statischen Seiten. Das StaticPage-Plugin benötigt Version 1.22 oder höher.
        [description] => Dieses Plugin zeigt eine konfigurierbare Liste der statischen Seiten. Das StaticPage-Plugin benötigt Version 1.22 oder höher.
        [6] => 1.18
        [version] => 1.18
        [7] => 1.18
        [upgrade_version] => 1.18
        [8] => 
        [plugintype] => 
        [9] => local
        [pluginlocation] => local
        [10] => 1
        [stackable] => 1
        [11] => Rob Antonishen, Falk Doering, Ian (Timbalu)
        [author] => Rob Antonishen, Falk Doering, Ian (Timbalu)
        [12] => a:3:{s:11:"serendipity";s:3:"1.3";s:6:"smarty";s:5:"2.6.7";s:3:"php";s:5:"4.1.0";}
        [requirements] => Array
(
    [serendipity] => 1.3
    [smarty] => 2.6.7
    [php] => 4.1.0
)

        [13] => 
        [website] => 
        [14] => 1341333581
        [last_modified] => 1341333581
        [15] => FRONTEND_VIEWS
        [category] => FRONTEND_VIEWS
        [groups] => Array
(
    [0] => FRONTEND_VIEWS
)

        [installable] => 1
        [local_documentation] => plugins/serendipity_event_staticpage/documentation_en.html
    )

[/size]
inside 'new versions of sidebar-plugins', which you can see is missing the part [upgrade_version] - > 1.19, [upgradable] => 1 etc.

The first is inside an

Code: Select all

[UPGRADE] => Array(...

, the second not, as in

Code: Select all

[FRONTEND_VIEWS] => Array(...

which practically clears, why it doesn't get announced as upgradable.

Perhaps this is more clear. Maybe its even not a problem of the Spartacus script itself and has to be searched in some include/*plugin*.php files...

[blog.brockha.us]

If I understand your problem right, I can tell you what's the reason (it's an old and nasty problem I trapped in often before):

If I understood it right how Spartacus is working, "Update Event Plugins" will check for all event plugins lying in a serendipity_event_* directory, "Update Sidebar Plugins" does the same for sidebar plugins lying in a serendipity_plugin_* directory. If it finds a changed version it will update the whole directory (both plugin versions, if there are two).

So this does mean: If you update the version only of a serendipity_plugin_* file lying in a serendipity_event_* directory, Spartacus won't notice the version change (as it checks the serendipity_event_* file in that case). You have to update the version of the serendipity_event_* plugin in that directory, too.

For that reason (and because I don't know what this different version of the same plugin should mean anyways) I never use different versions for a sidebar and event plugin lying in the same directory. In fact I produce a version.inc.php file, that is referenced from both and update this file. (You can see it in the twitter plugin i.e.).

[Timbalu]

If I understand your problem right, I can tell you what's the reason (it's an old and nasty problem I trapped in often before):

Its not my problem. I think its a problem of unaspected behaviour until a Newbie gets used to it.
Well, it is a problem for developers too, like you said.

... Spartacus ..., "Update Event Plugins" will check for all event plugins lying in a serendipity_event_* directory, "Update Sidebar Plugins" does the same for sidebar plugins lying in a serendipity_plugin_* directory. If it finds a changed version it will update the whole directory (both plugin versions, if there are two).

Yes that is exactly how it is working and leads to the main problem.

So this does mean: If you update the version only of a serendipity_plugin_* file lying in a serendipity_event_* directory, Spartacus won't notice the version change (as it checks the serendipity_event_* file in that case). You have to update the version of the serendipity_event_* plugin in that directory, too.

That is why I asked to get rid of the 'new sidebar plugins available' button (in this case only!).

For the moment, these buttons just pop up, if a user is_admin. I would like to have a small and specific check first, if there are

• single plugin updates available (in serendipity_plugin_* directory)
• single event updates available (in serendipity_event_* directory) - ["plugins == events"]
• both
• none

For these cases show single, double or no buttons [with text]. The last could also have a "opacity:.x " button.

It seems to be a historical question, why these buttons appear like they do. I think they were used to be the (cloned or original) install *plugin links, this is why they appeared as "Check for new [*] plugins[/i]" not long ago, until someone coudn't find the updater buttons last Autumn. Then the name content got precised. Now, I think, the event_hook creating these buttons should follow.

[blog.brockha.us]

Well in my case I only need "check for plugin updates". I don't care personally, if they are sidebar or event. If they are new: Update them!