* Removing properties related to IPublishedContentQuery, ITagQuery, ICultureDictionaryFactory, IUmbracoComponentRenderer from UmbracoHelper and using the corresponding private fields instead. Removing Media related methods
* Removed UmbracoHelper from UmbracoApiControllerBase
* Removed UmbracoHelper references
* Inject the needed Interfaces to classes that previously used UmbracoHelper to get the same functionality
* Fixed tests referencing UmbracoHelper
* Adding Media methods back
* Cleanup and moved UmbracoHelper from more base classes, when not used + simplified tests
* Reintroduced some methods..
* Reintroduced some methods..
* Reintroducing last missing bits
Co-authored-by: Bjarke Berg <mail@bergmania.dk>
an UmbracoHelper property to the PluginController class which will expose any methods needed by devs to retreive media or content.
Have updated UmbracoHelper with loads of new helpful methods and moved the Wrap methods to HtmlHelper extensions because this is purely to
do with rendering html (have written unit tests for it too).
Updated some 'library' methods to proxy calls to UmbracoHelper so we only have to maintain one set of code.
Added a convenience property to UmbracoContext to return the current NiceUrlProvider so you don't have to go through the RoutingContext to get it.
BeginUmbracoForm working for both local and plugin SurfaceControllers. SurfaceController class now inherits from PluginController which exposes all things a dev would
need including making IPublishedContentStore and IPublishedMediaStore public which can be accessed simply by properties on the controller.
Updated web.config for views to include Umbraco.Web namespace for all of our helper methods.
BeginUmbracoForm now has many more overrides for which you can specify a type or a generic type (we no longer require GUIDs :)
Instead (because we still want areas), we have an attribute called PluginControllerAttribute which allows a dev to assign an area name as a string. A package developer should always ensure that all of their plugin controllers are assigned to the same
area. This also lets us get rid of the GUID id part of the plugin (hopefully we can leave it out, just need to run some tests). Since we have areas, package devs can then put their views into
their own folders and not clutter up the local devs ~/Views folder. Perhaps we use App_Plugins/[PackageName] for the views like we did in v5 but need to ask on the mail list. Otherwise it will be the standard MVC:
~/Areas/[AreaName]/Views which will still also clutter up the local devs view folder if they are using Areas.
