Hi Piwigo coders!
While wondering how to build the theme manager in [Forum, topic 14925] [evolution] Management of the template/theme, the discussions partly derived to the internal architecture of templates + themes. Shouldn't we put themes outside the template? shouldn't we distribute a template with no theme + a theme depending on the template? and so on.
Then saimon came.
I read with attention what he wrote in [Forum, post 112026 by saimon in topic 14925] [evolution] Management of the template/theme. In this post, saimon describes the theme architecture in Dotclear.
Then I said "Woaw". This is simpler than what we do and you can do more.
1) simpler: forget about template. They have themes, only 1 level. Their *.tpl files are in themes/default/tpl/*.tpl
2) do more: inheritance. All themes derives from themes/default. A theme may also have an explicit parent.
Example: you like theme/dark, but you would like it slightly darker. You create theme/darker and declare dark as its parent theme. In darker you only have 2 files : themeconf.inc.php + theme.css (with 3 CSS rules only, only what you want to overwrite)
Then I discussed with P@t to ask his opinion about the way Dotclear was working for themes. He was really impressed and started to write a proof of concept (POC). It was 22 hours ago.
Today P@t sent me the POC.zip. Have a look : http://piwigo.us/work_in_progress/notemplate
P@t moved many files for a new organization. template-common was emptied and deleted.
"theme" directory is at the root of Piwigo. The result is something like:
theme |-- Sylvia | |-- icon | | `-- mimetypes | `-- images |-- clear |-- dark | `-- images |-- default | |-- icon | | |-- admin | | `-- mimetypes | |-- js | | |-- plugins | | `-- ui | | |-- i18n | | |-- minified | | |-- packed | | `-- theme | |-- mail | | `-- text | | |-- html | | | `-- images | | `-- plain | `-- template | `-- include |-- p0w0 | `-- images `-- wipi `-- images
The work is not finished, but it is "working" as is. Changing the theme is working fine.
Why I find this new architecture very interesting: because it's simpler. No question about how to manage templates on piwigo.org/ext or in the future theme manager inside Piwigo administration. In addition to this, I think that simplicity will generate more various themes in the end.
Today we can compare the external contributions for themes versus plugins. I believe that the first thing a user will customize is the theme. BUT in the extension manager, we have 50 themes versus 115 plugins. Plugins is PHP code and we could suppose it's harder to write. I think that plugin architecture is better than theme architecture and it partly explains why we don't have many contributed themes.
What's your opinion?
Offline
hello
just to say at my first lecture my state of mind : it's a revolution ! I feel seduce by changing the way of using template and theme because of the over-complexicity of the current structure, but also a little scared of the management of the template. It's late and I have not thought about it deeply.
It will be easier for the theme manager ^^
Last edited by flop25 (2010-03-11 23:21:32)
Offline
It's interesting!
After template including theme and now theme including template. In fact, now, the difference between theme and template are natural.
It's surely more easy to understand and to modify!
Questions:
o inheritance for each kind of files? (tpl, js, img, ...)
o inheritance with several level?
o directory mail shoud not be on template directory (like include) / and mails/images in icon/mail or images/mail?
o directory on default theme and other must be the same?
With gives:
theme |-- Sylvia | |-- icon | | `-- mimetypes | `-- images |-- clear |-- dark | `-- images |-- default | |-- images | | |-- icon | | | |-- admin | | | `-- mimetypes | | |-- mails | |-- js | | |-- plugins | | `-- ui | | |-- i18n | | |-- minified | | |-- packed | | `-- theme | `-- template | | `-- include | |-- mail | | `-- text | | |-- html | | `-- plain |-- p0w0 | `-- images `-- wipi `-- images
Last edited by rub (2010-03-11 23:25:23)
Offline
To clarify:
1 - Template-extension
2 - Local-layout
3 - Themeconf.inc.php changes
4 - CSS consequences
5 - Impacts on migration
I have no idea on each point currently.
What will happen to 2.1 delivery?
Does that mean it will be postponed for a medium size period of release candidate?
I need to understand all of these events.
Offline
rub wrote:
Questions:
o inheritance for each kind of files? (tpl, js, img, ...)
tpl => yes (automatic)
js =>
./theme/default/template/header.tpl:<script type="text/javascript" src="{$ROOT_URL}{$themeconf.js_dir}/scripts.js"></script>
conclusion: all js files must be in the same directory. I think P@t introduced a new file, theme/Sylvia/local_head.tpl in which you may write something like:
{known_script id="jquery.tipTip" src=$ROOT_URL/$themeconf.js_dir|@cat:"jquery.tipTip.minified.js" }
P@t will tell more precisely.
About images:
$ cat Sylvia/themeconf.inc.php <?php $themeconf = array( 'theme' => 'Sylvia', 'parent' => 'default', 'icon_dir' => 'theme/Sylvia/icon', 'mime_icon_dir' => 'theme/Sylvia/icon/mimetypes/', ); ?>
o inheritance with several level?
P@t told me : no limit.
o directory mail shoud not be on template directory (like include) / and mails/images in icon/mail or images/mail?
P@t told me that mails are in the TODO list
o directory on default theme and other must be the same?
hum? what do you mean? I don't see the changes you made :-/
Offline
VDigital wrote:
1 - Template-extension
I wonder if it's really necessary to have template-extension + theme inheritance at the same time. It fills the same function, it may confuse users.
But we can keep template-extension the way they are today and decide later about theme.
VDigital wrote:
2 - Local-layout
There are several local-layout:
./template/yoga/local-layout.css
./template-common/local-layout.css
Adding a local theme is easier to understand in my opinion.
3 - Themeconf.inc.php changes
Sylvia/themeconf.inc.php before:
<?php $themeconf = array( 'template' => 'yoga', 'theme' => 'Sylvia', 'icon_dir' => 'template/yoga/theme/Sylvia/icon', 'admin_icon_dir' => 'template/yoga/icon/admin', 'mime_icon_dir' => 'template/yoga/theme/Sylvia/icon/mimetypes/', 'local_head' => ' <!--[if IE]> <link rel="stylesheet" href="template/yoga/theme/Sylvia/theme-ie.css" type="text/css"> <![endif]--> ', ); ?>
Sylvia/themeconf.inc.php after:
<?php $themeconf = array( 'theme' => 'Sylvia', 'parent' => 'default', 'icon_dir' => 'theme/Sylvia/icon', 'mime_icon_dir' => 'theme/Sylvia/icon/mimetypes/', ); ?>
+ Sylvia/local_head.tpl :
<!--[if IE]> <link rel="stylesheet" href="{$ROOT_URL}theme/Sylvia/theme-ie.css" type="text/css"> <![endif]-->
4 - CSS consequences
None I think. P@t will confirm.
5 - Impacts on migration
All existing themes will need to be reorganized for compatibility. But it's not a really hard task compared to the improvement. Considering the low number of existing themes, no probleme for me to help theme creators for new organization.
What will happen to 2.1 delivery?
What do you mean?
Does that mean it will be postponed for a medium size period of release candidate?
No real change. This new architecture will save time on the theme manager creation (+ piwigo.org/ext adaptation)
Offline
questions from P@t:
P@t wrote:
What should we do about local-layout.css files? I'm in favour of removing them...
I think we should remove them to avoid the "10 ways to do the same thing" effect.
I will write a documentation to explain how to convert a local-layout.css into a local theme.
Offline
plg wrote:
... to avoid the "10 ways to do the same thing" effect.
+1
Offline
Currently, the theme "default" looks like this.
I think it's a good thing "Sylvia" is not the default theme at architecture level (but we keep Sylvia as the default theme at user level).
The "default" theme is really "simple". What about using the content of "clear" instead? (then we remove "clear" of course)
Offline
I think it's a good idea if we can simplified the structure Piwigo
This can allow the release of more theme
Offline
I had a short reply from saimon (simple/* and montblanc themes developer) by email:
saimon wrote:
I gave a quick look to the forum yesterday, but I wanted to to take time for reading in depth before giving my opinion ;-). At first sight, it seems great!
On 11/03/2010 22:48, plg wrote :
> I'm not sure you would imagine such a consequence to your post about themes in Dotclear ;-)
absolutely not, and even more I didn't think you would go so fast!
Offline
I also had a short reply by grum (gally template developer, among other things)
grum wrote:
I read the forum topic very quickly this morning. Impacts are not that small, but without searching more deeply I have difficulties to see the consequences. The better is to commit now, then once done, it will be easier to see what may be wrong.
In the worst case, if the solution doesn't fit, we can also go back to the previous state.
Offline
Tonight, I'm working with P@t to commit all this new stuff.
Offline
really great ! (you already know that I am an adept of the KISS principle ;-)).
Offline
[Bugtracker] ticket 1502
[Subversion] r5123 => I made the commit, but P@t made all the preparation (I made the commit to make sure we don't lose the Subversion history of moved files, I was not sure TortoiseSVN would be as safe as SVN command line)
Offline