@mattab opened this issue on April 8th 2008

It should be possible to create themes for . piwik to customize its design without modifiying core files. ## Proposal for Piwik Themes V1

Proposal November 2011, based from all comments and feedback: - Themes are implemented as "plugins" - The theme feature in Piwik is a basic concept: CSS override - A new hook allows a plugin to add extra CSS file (or simply return $css;). This CSS file would be loaded after all other CSS. This should allow for most theme desired changes? ie. margins, padding, float, colors, fonts, positions, can be changed. - Some work / refactoring might be required on some CSS to make them all themable friendly? - Building this feature would mostly involve building a custom CSS file override and modify existing Piwik CSS to make it possible / easier than current. - See comments for other interesting concepts: - Allow modifying colors of Javascript charts? - Allow modifying colors of Charts in Email reports/Mobile app? - Allow override of chosen TPL files? ALlow override of CSS files? Of whole JS files? I would say that it's best not to allow any override in V1 to keep things simple... thoughts? - Should we use a property definition mechanism to define all colors? See #comment:23

@robocoder commented on November 18th 2009

The Piwik "logo" is actually stylized text. While this is very low bandwidth, it means: - changing the default font affects the "logo" - re-branding Piwik requires changes to various templates

A common footer and meta tags should be added: "Powered by Piwik" with link to piwik.org (and possibly also the GPL)

@mattab commented on November 19th 2009

Adding the footer is not desired, as it would only show on the dashboard, and the dashboard has variable height (because of widgets) which looks dodgy (I tried a long time ago).

It would indeed be nice to rebrand Piwik easily, currently it requires a change to the templates.

@robocoder commented on November 24th 2009

Thanks Kay. I recently looked at various CMS packages, so I'll comment while this is somewhat fresh in my mind. 1. Refactoring the CSS. - generally agree that this is a good idea; the jQueryUI CSS framework takes a similar approach to separate widget-specific classes (dimensions, visibility, positioning, margins, padding) from theme-specific classes (text colors, backgrounds, fonts, icons) - being able to add custom CSS files (and javascript files) will be addressed in #660 - a CMS may allow themes to replace the "template" used by a module; in Piwik, we must take into consideration that a module may have multiple views; my thought would be to add a hook in Piwik_View::factory(), or look in the current theme's folder for a corresponding custom view (or perhaps a controller, if themes are installed as plugins) - wordpress's add_action() is very similar to Piwik's template_css_import and template_js_import hooks, but more granular, e.g., admin_head, admin_footer, ... 1. Tango icon theme. - Assuming the icon size isn't an issue, someone would have to see what Piwik icons are missing from the base set. Missing icons are an issue if the goal is to have a uniform icon theme. It may be necessary to enlist an icon designer as it appears the Tango project hasn't been active since 2007 (although one of the contributors appears to be working on Mango, aka Tango-NG). - The icon naming specification could be used as the css class name when defining a css sprite, but doesn't offer guidance wrt naming the css sprite file (see #965); perhaps, "sprite-{category}.png", e.g., sprite-flags.png 1. We already adopted jQueryUI and the 'base' theme, and replaced the jquery calendar widget with the jQueryUI datepicker widget. (To be released in Piwik 0.5.) - There is some functional overlap between Tango and jQueryUI's framework icons. They differ in image size -- a choice should be made depending on the size of neighboring text. 1. Menus. - To be addressed in #1028.

@robocoder commented on December 7th 2009

Right, that would be an example of "... if themes are installed as plugins" that I mentioned in comment:9.

That said, those hooks may be deprecated by #660.

@robocoder commented on December 13th 2009

In [1642], the layout was moved from Dashboard/templates/index.tpl to Dashboard/Controller.php.

In a theme-able environment, it might make sense to move the layout into a separate view file (e.g., layout.tpl). This depends on whether the View factory hook idea will fly. Otherwise, we could always add a getDefaultLayout hook.

@mattab commented on December 14th 2009

I agree with the general ideas proposed in the thread: - Focus on CSS refactoring: CSS defining layout (dimensions, visibility, positioning, margins, padding) and presentation (text colors, backgrounds, fonts, icons) are in specific CSS classes. This requires significant CSS refactoring work on Piwik, as well as modifications of JS scripts. - Have the theme be limited in scope at first: possible to add CSS, modify the layout file, add JS files. As themes are built, we can increase the scope of themes and accomodate theme designers - Build themes as plugins at first, as this makes sense and reduces complexity. If this is a limitation later, we can re-assess.


@mattab commented on July 29th 2010

Increasing priority, one of the most requested features.

@gka commented on August 2nd 2010

I just wanted to note that the non-html plugins like the charts or maps also are affected by theming. They're displaying labels and tooltips, and it should be able to customize those to the themes fonts and colors. Since flash widgets can't be styled via CSS in most cases, we have to think about some common properties for each theme, that can be inserted into PHP or templates.

Possible properties are: - page background color - text color - base font + size - tooltip colors (bg, border, text) - chart element colors (pie,bar,line), color scale (map)

This reminds me a bit of the theming of operating systems like windows.

To me, there are three options in dealing with these theme properties: - property definition in css that follows a special semantics which can be parsed via PHP and then be used in controllers and templates if necessary. for instance we define a css class .piwik-tooltip-layout that contains the colors and fonts used in chart tooltips - property definition in the main css-file, but inside a block comment on top of the file, like /* @tooltip-background #F4F0F0 */ - property definition in some kind of config.php that lays inside the theme directory

@mattab commented on August 3rd 2010

kaystrobach, please take a look at piwik codebase. Moving to something like extjs is not something we will consider in the near future considering the large amount of code that would have to be rewritten.

greg, good points. Also one must have customization is the logo (replace Piwik logo in header + PDF reports).

@robocoder commented on August 5th 2010

I propose we add an ExampleTheme plugin, and add the following hooks: - theme-specific layout - see comment:18; this provides a theme with the general ability to substitute their own .tpl files at runtime - Piwik_View::factory - Smarty function replacement for {include} tags - theme-specific AssetManager - see #1527; this provides a theme with the general ability to replace .css and .js files, order them in a specific manner, etc.

If we then create a logo.tpl that other .tpl files can include, then a theme can substitute its own logo.tpl at runtime.

(PluginsManager.php already triggers the deletion of assets and compiled templates when plugins are activated/deactivated.)

@robocoder commented on August 28th 2010

Kay: The number of columns in the dashboard is intertwined with the default dashboard layout. Changing the logic behind it isn't something I plan to (nor do I think we should) change via theming.

In your case, the site selector/creator takes up a lot of screen real estate as a static pane. I would make it slide out when needed.

@robocoder commented on August 28th 2010

I'll create a new ticket for the dashboard enhancements.

@robocoder commented on August 28th 2010

Ticket already exists #1559.

@robocoder commented on October 2nd 2010

Moving this to 1.2.

@mattab commented on November 24th 2010

Maybe, to implement theming, we will have to reorganize assets in consistent folders: #1385

@robocoder commented on April 28th 2011

Ok, let's roll #1385 into this ticket. If we implements themes as plugins: - Move contents of themes/default/ into plugins/CoreHome/ (or CoreTheme) - Reorganize static assets for consistency: - plugins/X/css - plugins/X/js - plugins/X/images - plugins/X/templates

@mattab commented on November 8th 2011

Updating ticket description with proposed implementation plan for the THEME feature in Piwik.

If you are a CSS designer, please post a comment here. we plan to build Themes as simple plugins that would return extra CSS to change colors and positions. Comment here if you'd like to build such a theme!

@robocoder commented on January 6th 2012

For discussion once the ball starts rolling on this feature: - clarify "are themes GPL too?" (Depends on the theme) - how to determine theme compatibility? - what happens if core css and/or templates change? (Eg graceful degradation)

@mattab commented on July 15th 2013

We are implementing Theming for Piwik 2.0! to achieve this, we have migrated to Twig, we are improving the CSS and templates, and making Theming the easiest possible (while allow full customization including graphs colors etc.). we also migrated to LESS #4052

@mattab commented on July 15th 2013

The new ticket for Theming is #3942

@mattab commented on August 28th 2013

Piwik 2 supports theming. Please use Piwik from GIT. Then go to Settings>Themes> and try enable PleineLune theme.

For help on how to create themes, see: https://github.com/piwik/piwik/tree/master/plugins/PleineLune#create-a-theme-for-piwik

We are looking forward to seeing your themes!

@mattab commented on November 22nd 2013

see follow up ticket (VERY exciting!!) #4127 New Default Theme for Piwik

This issue was closed on November 22nd 2013
Powered by GitHub Issue Mirror