A "type" could be a plugin that defines a type "Website" or "MobileApp". Different types need not only different reports and different naming of reports but also different fields in the Sites Manager. The Sites Manager might become at some point a Property Manager or something else. Naming is not important for now.
A mobile app would not define any URLs but an App-ID such as
We would maybe also allow to select an App store? Eg Google Play, ... Not needed by core actually but by a App Analytics plugin later. Not sure how to handle this!
Things to consider
sitetable all information would be in one place and we can easier return it in API calls of SitesManager but: it would be still slow since we'd have to check read permission for each type of each site and create many instances etc
coredoes not know anything about Tracking code. Therefore it would be maybe kinda wrong to have a tracking code link definition in
Typeclass? Same might apply for other things. In theory a developer would have to listen to an event on top for this, but that's complicated to do
SitesManager.getSiteUrlsFromId? Site URLs are not as much used in general. But we'd also need to remove
PluginName.SettingName(might be difficult or impossible)
postEvent(more flexible) or classes auto detection (one setting would always apply to all types)
configureSettingsmight get pretty long
Typecould be also named
So far we came to the following definition.
A property (eg
Piwik Mobile 2) has a name, a created timestamp, some other fields but also it has a type (eg
Some more of my thoughts:
In general we might differentiate between
action_title_category_reverseas it changes existing functionality. Eg it reverses the action titles but it doesn't provide the feature of
MobileApp) can define which attributes it consists of and which features make sense for this type.
Any plugin can extend any
type and define custom
features. For example the
Ecommerce plugin provides an
EcommerceFeature and the
Actions plugin provides a
SiteSearchFeature. If a plugin wants to access an attribute/feature/setting that it not defines itself, it needs to require the other plugin. For example an
Ecommerce plugin might require the
Goals plugin as it wants to use the
Currency attribute defined by the
It will be quite hard to differentiate between those 3 things (feature/attribute/setting) for some people and can be overwhelming. Also it is in general not really a good idea to have too many solutions for a problem. That's why we want to maybe simplify it. Eg we could merge
attribute. For example we could say a property has an attribute of reversed action title categories (actually it doesn't really make sense to say this is an attribute).
On the other side we need to think about what is actually used in which context. This means we might be actually able to use the different terms:
settingwould be usually only defined by a plugin that also defines and implements a
featuresince it changes existing behaviour. That means the
settingis bound to the
settingis most likely not defined by a
typerather defines attributes, such as "App-ID" or "Currency" and features that it supports, for example a "Site Search". Thinking more about it a
typemight rather not define whether it supports a certain feature as it can't know which features exist etc. Maybe a
typeshould mainly or only specify
feature(one feature might has one or more
settings) and that feature can be required by other plugins. Meaning ideally plugins should be able to require
plugin.json. It should not care by which plugins those
featuresare actually provided. This would be the ideal solution that we cannot really implement most likely since we can't tell which plugin defines which
features. The workaround would be to develop plugins that only define a
typeor only a
feature. Meaning "Site Search" should not be in the "Actions" plugin but it should be a plugin itself. Also "CoreHome" should not provide a "MobileApp" and "Website" type. Rather those should be independent plugins so they can be required.
PluginSettingsAPI supports currently
UserSetting. This needs to be extended by a
PropertySetting. We will pick those PropertySettings in
Sites Management(later Property Management) and display them there. This way we can still use the term Settings and it makes sense. Meaning the
Actionsplugin would define a
new PropertySetting('action_title_category_reverse'). If it can't be define in a plugin this way, then we're talking about an attribute which is defined by a
featureswe actually speak of
Ecommerceplugin. A plugin then defines the plugin settings as it can do already.
attributes. There will be for example a
configureAttributesAPI and any plugin will be able to enrich a certain type by adding more attributes. For example the type
MobileAppwill define an attribute
App-ID. Then another plugin could enrich this type and add two more attributes
App Store Loginand
App Store Password. They cannot really be a
Settingfor a feature since those attributes make only sense for the type
MobileApp. Otherwise it would be actually a setting! It is maybe too difficult to have both. What do you think? Update: We will not use the wording
To be decided
typedefine which feature it supports? By enabling/disabling entire plugins? Or would we always use
features? For me personally the natural step would be to say a type can disable features by disabling other plugins but the platform doesn't support this currently. For example we'd have to recreate
asset_manager_global.csswhenever one changes the property. Also caches assume that always the same plugins are loaded etc. Maybe we can somehow "ignore" plugins
If someone deactivates a plugin that configures a type, how shall we handle that? I'd say we assign the type
universal to them but we currently do not have that type yet.
website will be always activated so plan for now will be to always assign type
website if someone eg deactivates type
Update: Turns out it is not as easy to handle this. Instead we will default to a "universal" type if a specific type cannot be found. This also allows people to deactivate and activate a plugin again without losing any information
I wonder if developers want to create a "UserSetting" that is connected with a particular site/property. We currently have SystemSettings (global setting, can be usually configured only by a super user) and a UserSetting (can be changed by any user, affects only the user). Meaning at some point I reckon there might be the need to let users configure something per property (per website).
Imagine the LiveTab plugin. There we have a UserSetting which metric to show in the browser tab. The metric that you want to see might be different per website though. This means we might want to show regular users (not having admin permission) the Sites Manager and let them change some settings per website? (maybe not MVP but at some point). Any thoughts?
This means we might want to show regular users (not having admin permission) the Sites Manager and let them change some settings per website? (maybe not MVP but at some point).
My thoughts: good point, but it is not needed in MVP but maybe interesting later (likely we won't need this feature for a while, ie. until we have one or two use cases)
It will be pretty important for the code / design as it changes quite a lot. So I reckon we need to find a solution that will allow something like this at some point
Note: We might have to integrate this into the installation as well (once Mobile Apps plugin is enabled by default) as we currently always let users create a website during installation. TBD
@tsteur a lot of progress was made on this issue - what is the current status? what work is left for 2.15.0 or for 3.0.0?
We need to implement everything properly for 3.0.0. Especially the
Settings API needs a lot of refactoring and rethinking. Also we need to agree on final naming etc. We should talk about this stuff in Berlin/Poland maybe as well.
I've continued working on this one and been thinking about it a lot re changing our setting API's to make sure it's still possible to refactor, to understand it easily, to get easily values for these settings, easy to use via DI, performance, and been thinking about who wants to use it and now. Ideally it was possible to generate each individual setting etc. Problem is re Measurable settings we do not know enough about it yet and current way of doing things works kind of well so I came to conclusion I don't want to change too much.
Possibly I will move
$plugin/Settings/Plugin.php and also have a class
$plugin/Settings/Measurable.php. They will both work similar as before. Measurable Types will be able to define Measurable settings too.
I will try to expose all Settings via an API and try to render settings via Angular instead of Twig if possible. Otherwise we always have some kind of hidden requests like iframes in "Manage Measurables" when editing a "measurable" and many settings like "URL" would load very delayed after a measurable was already opened. In order to do this there might be some more changes to the API needed but will try to keep them to a minimum.
I might create a table
piwik_plugin_settings similar to
piwik_site_settings and no longer store plugin settings in Option table just for consistency with
piwik_site_settings and to be able to reuse code here maybe. Will see.
I will try to convert many of our existing measurable settings like URLs, exclude query parameters etc to settings but need to see how it goes. Main problem here is that we need some kind of different storage for these fields as they are stored in
piwik_site whereas new settings will be stored in
FYI: I also thought of just using
.json files to define settings. However, it's a bit problematic with refactoring and autocompletion in IDE and such stuff. Also some settings and whether someone has access to read or write a setting depends on access, sometimes one setting is only available after another one was enabled, often a custom validation of input values is needed etc and in many cases we would still need a solution in PHP. Last but not least it would be possible for anyone to open/read these json files (shouldn't be critical but can become a problem). It would be possible to allow to define validators etc via JSON but it would be a lot of effort to build and maybe not worth it for now as we do not really have problems with current settings API.