David Mudrák authored Dec 06, 2012 and Dan Poltawski committed Dec 06, 2012

There is no need to move the root folder of a plugin during the update
deployment. We just need to operate with its contents. So the web server
process can have the write access for the plugin folder only.

David Mudrák authored Dec 06, 2012 and Dan Poltawski committed Dec 06, 2012

The additional parameter allows to use this method without actual
removing the root of the path. That is, it is now possible to remove
the content of a folder only.

David Mudrák authored Dec 06, 2012 and Dan Poltawski committed Dec 06, 2012

The additional parameter allows to use this method without actual
removing the root of the source location. That is, it is now possible to
move the content of a folder only.

Also, a small refactoring happened here as we will need a variant of
this method that does not throw exception if the target already exists.

David Mudrák authored Dec 06, 2012 and Eloy Lafuente committed Dec 06, 2012

There was a problem experienced after 2.4.0 release because the version
of the 2.4.0 release was the same as 2.5dev release. So the version
value matched twice in the loop and the line was repeated in the email.

David Mudrák authored Dec 05, 2012 and Eloy Lafuente committed Dec 06, 2012

Before this patch, the available_update_checker::cron_notifications()
method accessed the availableupdates property. But for plugins, that property
basically contains the most recent version available. So we were missing
the check against the actual version installed.

The fix was simple - obtain available updates via the available_updates()
method that performs the check.

The url_select class can optionally show a button (much like the non-JS
fallback). In this case, the autosubmit nature of the form shouldn't be
enforced and it should only submit on the button.