…sion into its own class. This is very experimental right now. More experimental stuff will follow

…dimensions which is still not 100% working and needs more work

…y. Many people might link directly to this url in their widgets. Will have a look at this later again

…not translate the category. The reportMetadata wants it translated but widgetslist wants the translation key. So we translate it only for the reportMetadata. Best solution would be to always accept either translated or the key but one problem after another

… not. fixes some tests

…ations. looks like a hack to me... need to make this use case easier

…the default translations again

…mes set to 0 when false was returned

Conflicts:
	core/FrontController.php
	core/Log.php
	plugins/API/API.php
	tests/PHPUnit/Fixture.php
	tests/PHPUnit/UI

…er db is dropped at some point

…uses it

…ker is used

… ui test as it will then execute the update

…re there is a space and it is possible to wrap the content to avoid horizontal scollbars

…to 2.5.0-b1 the updater wanted to update all dimensions (meaning alter all columns in log_visit, link_action and conversion) to the same column type. This was happening because the system did not know those dimensions were already installed from a previous Piwik version. There was an update script that was supposed to tell Piwik those components are actually already installed since we only moved them from core to plugins but it cannot work as it is an update as well and therefore not executed before the actual update check. I tried many solutions to overcome this issue including reverting all the columns to the initial MySql Schema but even then there are problems as some plugins like DevicesDetection are not defined in MySql Schema but in the plugin. It is especially complicated since users might update from 2.4 to a future version where the column type of one of those dimension changes and we need to make sure to actually execute an alter update if one of those dimension changes. In such a case we cannot directly mark the component as successfully recorded. The conclusion was for me it is only possible to solve this problem by listing all dimensions that were moved from core to plugins including their version at that time hard coded...

…n_refactoring

…er in c01d57b, this might work... basically the idea was ok but we should check for this only if the column actually already exists. If the column does not exist yet we need to make sure it will be installed

…ld make sure they are getting installed

…will break the UI tests

…n_refactoring

Conflicts:
	core/Updates/0.4.2.php
	core/Updates/0.6.3.php
	core/Updates/1.2-rc1.php
	core/Updates/1.9-b9.php
	core/Version.php
	tests/PHPUnit/Fixture.php
	tests/PHPUnit/Fixtures/UITestFixture.php
	tests/PHPUnit/Integration/Core/JsProxyTest.php

… during merge

… but the tracker cache does not get noticed. So make sure to clear tracker cache before running an update on the database to make sure it will always compare all dimension columns and check whether they need to be installed