1. 09 Oct, 2015 8 commits
    • David Mudrák's avatar
      MDL-49329 admin: Introduce new \core\update\api client class · 48900324
      David Mudrák authored
      The purpose of this class is to provide a general client for all APIs
      available at https://download.moodle.org/api/ (e.g. available updates,
      plugin info, plugins list etc). Currently, fetching data from this API
      is done separately at several places. This leads to code duplication and
      harder maintenance (I know it well).
      
      Additionally, the existing client was implemented as
      tool_installaddon_pluginfo_client in the admin/tool/installaddon/ scope.
      I will soon need to use the same functionality in the
      core_plugin_manager and it would hurt my karma if the core was depending
      on a class provided by a admin tool plugin (even if it is standard one).
      
      So, there is new \core\update\api client implementing the version 1.3 of
      the pluginfo API. There is a TODO note left for remaining services.
      48900324
    • David Mudrák's avatar
      MDL-49329 admin: Move requirements resolving to the plugin manager · 7eb87eff
      David Mudrák authored
      The patch moves the resolving logic from the renderer (where it should
      not really be) to the plugin manager (controller). This is needed
      because we will need the very same logic to be used at other places.
      7eb87eff
    • David Mudrák's avatar
      MDL-49329 admin: Improve loading of available updates info · c44bbe35
      David Mudrák authored
      The actual loading of available updates info objects is moved back to
      the plugin manager class. As we can now mockup the manager in unit
      tests, this allows us to bypass the real \core\update\checker and have
      unit tests for \core\plugininfo\base::available_updates().
      c44bbe35
    • David Mudrák's avatar
      MDL-49329 admin: Keep reference to plugin manager in plugininfo objects · 2d488c8f
      David Mudrák authored
      Plugin info objects are owned by the plugin manager (composition
      pattern). Even if the plugin manager is a singleton, we need to keep
      explicit reference to the plugin manager that owns the plugin info so
      that we can mock up things in unit tests.
      
      Therefore this patch introduces a new property of plugin info objects
      that holds the reference to the instance of the plugin manager that made
      (and hence owns) the given info instance.
      
      The only trouble here is with static methods of plugin info classes such
      as \core\plugininfo\base::get_enabled_plugins(). In these cases, the
      code keeps using the core_plugin_manager singleton. The solution would
      be to pass the plugin manager instance as a parameter but that is not
      worth of change for now, IMHO.
      2d488c8f
    • David Mudrák's avatar
      MDL-49329 admin: Make core_plugin_manager better suited for unit testing · 361feecd
      David Mudrák authored
      We can now override the plugin manager's methods in the testable
      subclass while still keeping the singleton behaviour of it. The change
      makes use of late static binding.
      361feecd
    • David Mudrák's avatar
      MDL-49329 admin: Do not always load info about available updates · 30d8bc5f
      David Mudrák authored
      Before this patch, whenever core_plugin_manager::get_plugins() was
      called, it always attached info about available updates. But this is
      needed only in quite rare cases, such as when the admin is looking at
      the Plugins overview and Plugins check screens. There is no need to load
      this on other places and for non-admin users.
      
      The patch removes the loading from the method
      core_plugin_manager::get_plugins_of_type() and implements lazy loading
      directly in the plugininfo classes so that it is loaded only when
      \core\plugininfo\base::available_updates() is actually called.
      30d8bc5f
    • David Mudrák's avatar
      MDL-49329 admin: Fix \core\update\checker::enabled() logic · e9d3c212
      David Mudrák authored
      The method should check against $CFG->disableupdatenotifications and not
      $CFG->disableupdateautodeploy. This had to be a copy&paste mistake from
      the \core\update\deployer::enabled().
      
      While looking at it, I also fixed couple of places where this method
      should and could be used.
      e9d3c212
    • David Mudrák's avatar
      MDL-49329 admin: Improve the styling of the Plugins check screen · fd17898c
      David Mudrák authored
      The intention here is to make the table a little bit more compact (using
      less columns) and to make use of the bootstrap based label elements if
      available.
      fd17898c
  2. 08 Oct, 2015 12 commits
  3. 07 Oct, 2015 20 commits