+1

VDigital wrote:

At least one theme must be activated, don't you think so?

yes

VDigital wrote:

Pending questions:
What will happen to user profile with a recent deactivated theme? They switch to default theme?
What will happen to the default profile with a recent deactivated theme? It will switch to next available theme?

Define a theme by défault.
Every user who isn't on dispo theme seesaw on the theme by défault.

Possibility of reimposing a theme to all the users

This topic comes in the right place at the right time :-) In my opinion, the theme selector needs a serious refresh and we also need to make Piwigo communicate with the Piwigo community through http://piwigo.org/ext

The ability to activate/deactivate installed themes is nice.

1. Theme Selector

We still have an old listbox with all installed themes. I'm sure we can do much much better now. For example, I've taken screenshots of Gmail theme selector and WordPress theme manager. Each theme is represented as a thumbnail and either clicking on the thumbnail changes the current theme (Gmail behavior) or clicking on the thumbnail show a lightbox-like popup preview.

This feature can be used on admin side an on public side if the admin has allowed users to choose another theme.

2. Theme Manager, install from Extensions

Plugins have the "Plugin Manager", with the ability to connect to piwigo.org/ext and see live updates of the most useful plugins. Themes deserve just the same! As themes are more graphical than plugins, a more graphical presentation of available themes would suit best to themes.

Personnaly, I think that a WordPress-like Theme manager + ability to install new theme from piwigo.org/ext would be nice!

Repie38,

I don't know if you are aware of Swift Theme Creator.
It is ongoing project, I will come back later on that plugin.

;-)

Yep!


[STC: Swift Theme Creator will just change colors, [maybe some graphs] but not the code.]

How do you imagine interactions between STC and a theme manager?

First results

On my local copy, I have made some ugly changes in the plugins management class to handle themes and templates.

1) add a parameter to the get_server_plugins method to list plugins OR styles (it's just a numeric id in the URL for HTTP on PEM)

2) a false admin page [Configuration > Themes] that is in fact plugins_new with a $page['ext_type'] == "style" instead of "plugin".

3) heavy modification on extract_plugin_files to handle templates and themes. This is the main point.

The algorithm is the following:

* if the ext_type equals "plugin", then we look for main.inc.php
* if the ext_type equals "style", it can be either a template (with at least 1 mandatory theme) or pack of themes (at least 1 theme)

A template is a directory with a sub-directory "theme"... couldn't find anything better :-/
A theme is a directory with a file themeconf.inc.php inside

The themeconf.inc.php is parsed, but not executed (to avoid security issues, I wonder if it's really that important as we're going to execute later). I look for "*template*foo*" and "*theme*bar*".

The template is extracted in ./template/foo
A theme is extracted in ./template/foo/theme/bar

My heavy modification of extract_plugin_files is not a good idea. A cleaner way would be to have an extensions.class.php and 2 children : themes.class.php + plugins.class.php.

Anyway, this ugly hack already greatly improves themes installation :-)

Discussion with flop25

We've had a discussion on Jabber with flop25 mainly about how to manage dependencies and so on. I haven't solved the issue yet of course. Piwigo doesn't know which revision of each template or theme is installed. We have also talked about packaging of themes and templates in piwigo.org/ext, with the conclusions:

1) 1 style extension = 1 theme (take Simple/White as an example)
2) 1 style extension may be packaged with its template (Simple/Grey)
3) 1 extension may require another extension (Simple/White requires Simple/Grey)
4) 1 revision may require a specific revision (Simple/White 1.3a requires Simple/Grey 1.3)

Dependencies are managed at piwigo.org/ext level, not inside the zip archive.

plg wrote:

Code:

/*
Themes Name:
Version:
Template:
Description:
Themes URI: http://piwigo.org/ext/extension_view.php?eid=1234
Author: Piwigo team
Author URI: http://piwigo.org
*/

Why using that comment syntax difficult to parse and error prone ? I think an ini file will be better and easier to write for contributors, and easier to analyze for us.

I propose

Themes Name =
Version =
Template =
Description =
Themes URI = http://piwigo.org/ext/extension_view.php?eid=1234
Author = Piwigo team
Author URI = http://piwigo.org

We don't have to care of space and tabs, they will be trim !
We can also make sections :

[Theme]
Name =
Version =
Template =
Description =
URI = http://piwigo.org/ext/extension_view.php?eid=1234

[Author]
Name = Piwigo team
URI = http://piwigo.org