Piwigo Bugtracker

Viewing Issue Advanced Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0000429 [Piwigo] template feature always 2006.06.19 21:23 2006.06.28 23:37
Reporter chrisaga View Status public  
Assigned To rub
Priority high Resolution fixed Platform
Status closed   OS
Projection none   OS Version
ETA none Fixed in Version 1.6.0RC3 Product Version 1.6 branch
  Target Version Product Build
Summary 0000429: Don't force template author to create an admin template (step 1 : sitewise fixed admin layout)
Description This is step 1
Add a $conf['admin_layout'] variable used to fix template/theme to be used in admin section
Steps To Reproduce
Additional Information
Tags No tags attached.
browser any
Database engine and version
PHP version
Web server Apache 1.3.x
Attached Files

- Relationships
child of 0000430closedrub Don't force template author to create an admin template (step 2 : user fixed admin layout) 

-  Notes
(0001094)
chrisaga (developer)
2006.06.19 21:30

Done in branch 1.6 ([Subversion] r1370)
template authors have nothing special to do : they do not need admin.tpl nor admin/* any more.
Enjoy !
(0001095)
nikrou (developer)
2006.06.19 21:40

I think a better way to test that we are in admin is:
if (defined('IN_ADMIN') and IN_ADMIN)
instead of
if (basename($_SERVER['SCRIPT_FILENAME']) == 'admin.php')

You are in that new way independant of the script file name.
(0001096)
chrisaga (developer)
2006.06.19 21:57
edited on: 2006.06.19 22:00

You are right, I just copied the way z0rglub did this.

Plus I didn't know this variable.
My job is only the template, not php <;o)
But what do you say ? so simple isn't it ?

(0001097)
chrisaga (developer)
2006.06.19 22:04

use nikrou contribution (IN_ADMIN variable)
branch 1.6 ([Subversion] r1371)
(0001110)
chrisaga (developer)
2006.06.23 20:36

reporté en bsf par nikrou
(0001136)
rub (developer)
2006.06.27 12:30

When you public layout is not yoga/dark, it's strange to have, for exemple, yoga/clear on public and yoga/dark on admin.

It's perhaps best to not define $conf['admin_layout']) on config_default.inc.php but only on config_local.inc.php.
If $conf['admin_layout']) is not defined, $user['template'] is used!
With that, users will not have surprise of different layout (non desired).
(See too new comment on step2).


And why $conf['admin_layout']) and why not $conf['admin_template'])? (To be constant with $user['template']).

(chrisaga, if you are no time, assigned me this issue, I will do the modification).
(0001137)
chrisaga (developer)
2006.06.27 14:27
edited on: 2006.06.27 14:31

1)
   Right, it's strange
2)
> If $conf['admin_layout'] is not defined, $user['template'] is used!
   But what is used if the template in $user['template'] doesn't have an admin section and $conf['admin_layout'] is not defined in config_local.inc.php?
   I thought the one in config_default.inc.php would be used for this in step 2
2)
  Because the first $user['template'] retrieved from the stored user parameters is to be renamed $user['layout'] (see TODO in the php code). The idea is to split $user['layout']='yoga/dark' into
$user['template']='yoga'
$user['theme']='dark'

(anyway I let you lead step 1 final work according to your needs for step 2)

(0001138)
rub (developer)
2006.06.27 15:55

> But what is used if the template in $user['template'] doesn't have an admin section and $conf['admin_layout'] is not defined in config_local.inc.php?
> I thought the one in config_default.inc.php would be used for this in step 2
Yes, on step 2, an admin check will be added.
On step 1, the are not check, only a quicky possibility of have a admin template different of public template.
Default value will be used really on step 2.
$conf['admin_layout']) on step 1, it's a force value to admin layout.
$conf['admin_layout']) on step 2, will be a default value to admin layout. (if user layout is not admin, etc.)

> Because the first $user['template'] retrieved from the stored user parameters is to be renamed $user['layout'] (see TODO in the php code). The idea is to split $user['layout']='yoga/dark' into
Yes, I understand.
I didn't know... ;-)
(0001140)
rub (developer)
2006.06.27 23:15

Modifications done on [Subversion] r1410 and [Subversion] r1411
(0001141)
nikrou (developer)
2006.06.28 09:01

Line too long cf coding convention
(0001142)
rub (developer)
2006.06.28 11:54

> Line too long cf coding convention
Rub Again... ;-)
OK, I will do that quicky!
(0001148)
rub (developer)
2006.06.28 23:34

Fix on [Subversion] r1411 [Subversion] r1412

- Issue History
Date Modified Username Field Change
2006.06.19 21:23 chrisaga New Issue
2006.06.19 21:23 chrisaga Status new => assigned
2006.06.19 21:23 chrisaga Assigned To => chrisaga
2006.06.19 21:23 chrisaga browser => any
2006.06.19 21:23 chrisaga Web server => Apache 1.3.x
2006.06.19 21:27 chrisaga Fixed in Version => 1.6 branch
2006.06.19 21:30 chrisaga Status assigned => resolved
2006.06.19 21:30 chrisaga Resolution open => fixed
2006.06.19 21:30 chrisaga Note Added: 0001094
2006.06.19 21:40 nikrou Status resolved => feedback
2006.06.19 21:40 nikrou Resolution fixed => reopened
2006.06.19 21:40 nikrou Note Added: 0001095
2006.06.19 21:57 chrisaga Note Added: 0001096
2006.06.19 22:00 chrisaga Note Edited: 0001096
2006.06.19 22:04 chrisaga Status feedback => resolved
2006.06.19 22:04 chrisaga Resolution reopened => fixed
2006.06.19 22:04 chrisaga Note Added: 0001097
2006.06.19 22:05 chrisaga Relationship added child of 0000430
2006.06.23 20:36 chrisaga Status resolved => closed
2006.06.23 20:36 chrisaga Note Added: 0001110
2006.06.27 12:30 rub Status closed => feedback
2006.06.27 12:30 rub Resolution fixed => reopened
2006.06.27 12:30 rub Note Added: 0001136
2006.06.27 14:27 chrisaga Note Added: 0001137
2006.06.27 14:31 chrisaga Note Edited: 0001137
2006.06.27 14:32 chrisaga Status feedback => assigned
2006.06.27 14:32 chrisaga Assigned To chrisaga => rub
2006.06.27 15:55 rub Note Added: 0001138
2006.06.27 23:15 rub Status assigned => resolved
2006.06.27 23:15 rub Fixed in Version 1.6 branch => 1.6.0RC3
2006.06.27 23:15 rub Resolution reopened => fixed
2006.06.27 23:15 rub Note Added: 0001140
2006.06.28 09:01 nikrou Status resolved => feedback
2006.06.28 09:01 nikrou Resolution fixed => reopened
2006.06.28 09:01 nikrou Note Added: 0001141
2006.06.28 11:54 rub Note Added: 0001142
2006.06.28 23:34 rub Status feedback => resolved
2006.06.28 23:34 rub Resolution reopened => fixed
2006.06.28 23:34 rub Note Added: 0001148
2006.06.28 23:37 rub Status resolved => closed


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Contact
Powered by Mantis Bugtracker