I've got a Retry button at the top of my plugins page which does nothing (And no help text to explain what it's supposed to do).  It references change_release() which doesn't exist on the page source

The Retry button appears when it was not possible to retrieve the update information of one or more plugins.

 

And... you've found a bug (missing piece actually) the "change-release" function is missing (don't get confused by its name) 

3 minutes ago, bonienl said:

The Retry button appears when it was not possible to retrieve the update information of one or more plugins.

 

How about logging the offending plugin.  It seems to be permanently present on my system, and no real easy way to see what's going on.

I just manually compared /var/log/plugins to /tmp/plugins, and the .plg files all exist in each folder

 

Every .plg in /tmp/plugins returns a valid version on plugin version from a fresh boot, so I'm not quite sure what plugin would be triggering the retry to appear since it is downloaded every .plg correctly.

Edited June 22, 20179 yr by Squid

16 minutes ago, Squid said:

How about logging the offending plugin.  It seems to be permanently present on my system, and no real easy way to see what's going on.

 

Which plugin has status "unknown"?

 

Doh.  Missed that.  

I added more descriptive text to the Retry button.

 

When your internet connection is working okay, it should not happen that the Retry button appears. There is a quick ping test done to google DNS before downloading the actual file.

 

10 hours ago, bonienl said:

I added more descriptive text to the Retry button.

 

When your internet connection is working okay, it should not happen that the Retry button appears. There is a quick ping test done to google DNS before downloading the actual file.

 

There's an error in the code.  I gotta get some time to look at fixing it, but the net result is that the new code is assuming that the name of the plugin is the name of the .plg file.  The two should really have no basis to equate to each other.

 

Net result is that anyone who has the ransomware bait plugin installed is always going to see the "Retry" button pop up, not because of a failure to download, but rather because the name of the plg doesn't match the name of the plugin itself (this was done for a reason to differentiate the very original plugin, and the stable version).  (And this was perfectly acceptable on pre RC5 versions)

Edited June 22, 20179 yr by Squid

For some reason, I'm not finding 6.4 dynamix on github, but line 37 of dynamix.plugin.manager/include/ShowPlugins.php needs to be

 

  $checked = check_plugin(basename($plugin_file));

instead of

  $checked = check_plugin("$name.plg");

13 minutes ago, Squid said:

There's an error in the code.  I gotta get some time to look at fixing it, but the net result is that the new code is assuming that the name of the plugin is the name of the .plg file.  The two should really have no basis to equate to each other.

 

Net result is that anyone who has the ransomware bait plugin installed is always going to see the "Retry" button pop up, not because of a failure to download, but rather because the name of the plg doesn't match the name of the plugin itself (this was done for a reason to differentiate the very original plugin, and the stable version).  (And this was perfectly acceptable on pre RC5 versions)

 

Hmm, you are saying you have added other entries to /var/log/plugins? This folder should only hold legimite links to plugins aka PLG files. In rc5 a forced check is done on any reference found in this folder. Previously any "mismatch" would be silently suppressed, hence you didn't see it.

Can you avoid adding non-plugin entries to /var/log/plugins?

No I'm not.  The filename is newransomware.plg  The name of the plugin is ransomware  /var/log/plugins shows newransomware.plg, but you're checking for updates on ransomware.plg

 

The code above looks like it fixes it, but because of the fact that dynamix now checks for updates automatically, it's kinda hard to test (I can push an update if you want)

4 minutes ago, Squid said:

The code above looks like it fixes it, but because of the fact that dynamix now checks for updates automatically, it's kinda hard to test (I can push an update if you want)

 

Ah, I see what you mean!

 

Meanwhile a couple of things have been altered. Tom preferred a bit different approach. The result is that there is no more 'Retry' button and when no schedule is set for automatic update checks under notifications, then a manual "Check for Updates" button is made available on the plugin/update OS page.

 

You can find the latest versions under branch '6.4-wip', I have made a PR with your change included. Thanks.

3 minutes ago, bonienl said:

You can find the latest versions under branch '6.4-wip',

Thanks.  Finally found it in your repo.