Why are admin and installer still distinct from themes?

[Andrew da Silva]

Clutter in AdminHandler got me thinking...

Since admin and installer are themes, why are they still in
independent folders?

Sure, admin and installer in system/themes could be troublesome, but
would it?
We control what goes in system/themes... no risk of overwriting.
Only problem I can foresee is user/themes/admin and installer...

In the end, I think we should remove those two folders from system, it
makes no sense anymore.

If installer is considered "administration" material, maybe we could
create...

system/themes/admin/installer
system/themes/admin/default
system/themes/user/k2
system/themes/user/mzingi
system/themes/user/charcoal

And replicate in the user folder..

user/themes/admin/...
user/themes/user/...

This way Habari would mainly be an API completely customizable from A
to Z...

[Arthus Erea]

I don't like the idea of reducing unnecessary complication, especially
when it comes to the user themes directory.

I don't know about you, but the URL 'user/themes/user/foo' seems ripe
for confusion...

My question is: why? What practical aim does this serve to users to
justify this added confusion?

What would be the problem with simply putting the admin and installer
themes in system/themes/admin – I think we can safely assume nobody is
going to name a theme "admin" – and if they do we should probably
assume it is meant as a replacement for the admin interface.

[Andrew da Silva]

I was going to suggest not touching the user/ ... but then devs might
get confused?

[Arthus Erea]

Andrew and I talked about this on IRC and came to this suggestion:

1. Move admin and installer to /system/themes.
2. Rename admin to 'monolith' and installer to some code-name we
decide upon.
3. Introduce a new <type> field into theme.xml, which accepts 3 values
a. 'site' – used for public display; default
b. 'installer' – used for the installer
c. 'admin' – used for the admin
4. Create theme.xml for our themes and update accordingly.

This serves a couple of useful aims:
A) Ensures consistency of structure across /user and /system – all
themes are in */themes
B) Allows for the ultimate plug-ability of alternative admin (or even
installer!) themes. – eventually
C) Potentially allows for the controlled activation of different admin
themes – you could switch between different themes for the admin at
will, just like for the public site.

[Ali B.]

On Tue, Sep 30, 2008 at 4:53 AM, Arthus Erea <arthu...@gmail.com> wrote:

Andrew and I talked about this on IRC and came to this suggestion:

1. Move admin and installer to /system/themes.
2. Rename admin to 'monolith' and installer to some code-name we
decide upon.
3. Introduce a new <type> field into theme.xml, which accepts 3 values
       a. 'site' – used for public display; default
       b. 'installer' – used for the installer
       c. 'admin' – used for the admin
4. Create theme.xml for our themes and update accordingly.

This serves a couple of useful aims:
A) Ensures consistency of structure across /user and /system – all
themes are in */themes

 

The suggestions are based on the assumption that the admin and the installer are themes. Which, IMHO, is not correct.
The term 'themes' is given what controls the look and feel for the front end. The admin and installer are sites, not themes. Thus, having system front-end themes and the admin/installer sites in the same place would result in an inconsistency, rather. This perspective also tells me that having a "type" field in the xml would not make any sense either.

 

B) Allows for the ultimate plug-ability of alternative admin (or even
installer!) themes. – eventually

 

On the top of my head, I can't see why you can't accomplish that --if that that feature is implemented in core-- without moving these sites along.

 

C) Potentially allows for the controlled activation of different admin
themes – you could switch between different themes for the admin at
will, just like for the public site.

Also can be implemented in core without moving the sites (see my previous notes).

Not only admin and installer are sites, but they are obviously 2 seperate, different sites actually. And it makes perfect sense to me that they are both in seperate folders, in /system.


--
Ali B / dmondark
http://www.awhitebox.com

[Arthus Erea]

On Sep 29, 2008, at 10:06 PM, Ali B. wrote:

On Tue, Sep 30, 2008 at 4:53 AM, Arthus Erea <arthu...@gmail.com> wrote:

Andrew and I talked about this on IRC and came to this suggestion:

1. Move admin and installer to /system/themes.
2. Rename admin to 'monolith' and installer to some code-name we
decide upon.
3. Introduce a new <type> field into theme.xml, which accepts 3 values
       a. 'site' – used for public display; default
       b. 'installer' – used for the installer
       c. 'admin' – used for the admin
4. Create theme.xml for our themes and update accordingly.

This serves a couple of useful aims:
A) Ensures consistency of structure across /user and /system – all
themes are in */themes

 

The suggestions are based on the assumption that the admin and the installer are themes. Which, IMHO, is not correct.
The term 'themes' is given what controls the look and feel for the front end. The admin and installer are sites, not themes. Thus, having system front-end themes and the admin/installer sites in the same place would result in an inconsistency, rather. This perspective also tells me that having a "type" field in the xml would not make any sense either.

 

I'm afraid you're incorrect there. They _are_ themes.

They implement the theme system and use theme logic. Not to mention, they really are themes in the technical sense. Themes are used to render presentational logic–which both the admin and installer are.

For the technical proof, please look to line 67 of http://trac.habariproject.org/habari/browser/trunk/htdocs/system/classes/adminhandler.php.

B) Allows for the ultimate plug-ability of alternative admin (or even
installer!) themes. – eventually

 

On the top of my head, I can't see why you can't accomplish that --if that that feature is implemented in core-- without moving these sites along.

I'm not sure how you would do that... presently the only ways are somewhat hacky and rely upon plugins.

By the way, what "sites" do you mean? We're not moving any sites....

C) Potentially allows for the controlled activation of different admin
themes – you could switch between different themes for the admin at
will, just like for the public site.

Also can be implemented in core without moving the sites (see my previous notes).

Not only admin and installer are sites, but they are obviously 2 seperate, different sites actually. And it makes perfect sense to me that they are both in seperate folders, in /system.

Different sites? I'm not really sure where you get that... they're both interfaces (along with the public front-end) to the same site.

[Ali B.]

On Tue, Sep 30, 2008 at 5:13 AM, Arthus Erea <arthu...@gmail.com> wrote:

On Sep 29, 2008, at 10:06 PM, Ali B. wrote:

On Tue, Sep 30, 2008 at 4:53 AM, Arthus Erea <arthu...@gmail.com> wrote:

Andrew and I talked about this on IRC and came to this suggestion:

1. Move admin and installer to /system/themes.
2. Rename admin to 'monolith' and installer to some code-name we
decide upon.
3. Introduce a new <type> field into theme.xml, which accepts 3 values
       a. 'site' – used for public display; default
       b. 'installer' – used for the installer
       c. 'admin' – used for the admin
4. Create theme.xml for our themes and update accordingly.

This serves a couple of useful aims:
A) Ensures consistency of structure across /user and /system – all
themes are in */themes

 

The suggestions are based on the assumption that the admin and the installer are themes. Which, IMHO, is not correct.
The term 'themes' is given what controls the look and feel for the front end. The admin and installer are sites, not themes. Thus, having system front-end themes and the admin/installer sites in the same place would result in an inconsistency, rather. This perspective also tells me that having a "type" field in the xml would not make any sense either.

 

I'm afraid you're incorrect there. They _are_ themes.

They implement the theme system and use theme logic. Not to mention, they really are themes in the technical sense. Themes are used to render presentational logic–which both the admin and installer are.

Admin does not "implement" the theme system. The theme system is not just the Theme class. So no.

For the technical proof, please look to line 67 of http://trac.habariproject.org/habari/browser/trunk/htdocs/system/classes/adminhandler.php.

B) Allows for the ultimate plug-ability of alternative admin (or even
installer!) themes. – eventually

 

On the top of my head, I can't see why you can't accomplish that --if that that feature is implemented in core-- without moving these sites along.

I'm not sure how you would do that... presently the only ways are somewhat hacky and rely upon plugins.

By the way, what "sites" do you mean? We're not moving any sites....

Admin and themes are. Or at least, this is how they're named. They have 2 different purpose, each is different from the front-end's.

[Owen Winkler]

I think this discussion is inappropriate at this time.

By allowing easy user-supplied admin themes we'd be encouraging a
situation where users could quite easily damage their overall install in
many ways, including making their admin inaccessible or causing discrete
components of the admin to fail.

In addition, nearly the entire admin "theme" relies on specific methods
with the adminhandler, the analog for the admin theme's theme.php.
Writing any supplemental admin theme would likely involve rewriting a
significant and impractical amount of the handler code.

There are so many other things to do right now to bring Habari into a
useful state with the admin that we have, I simply don't see any
compelling reason to make this change now, or even provide the rudiments
for it. It certainly doesn't simplify any other task currently in
queue. Is there some latent user request for this?

Owen

[Christian Mohn (h0bbel)]

Agreed.

I don't really see why we should spend any time on this, at least not now.
There are other more pressing issues that should be taken care of.

Christian

[Arthus Erea]

I don't think this needs to be high priority, but it should be
considered for eventual implementation.

As I understand it, no you wouldn't.

The same handler would be used for the new admin theme, it would
simply use different presentation files.

[Andrew da Silva]

Was trying to think of a way to finally organize the AdminHandler..
and had an AdminThemeHandler opened also...

Then it hit... callbacks.... we use them in rewrite rules, 'handler'
and 'action'...

We merge them array('class','function') and then make a parameter
'callback' accepting an array of arrays:

array(
'POST' => array('AdminHandler','post_comments'),
'GET' => array('AdminThemeHandler','display_comments'),
)

Anyhow, thought I'ld mention it hear to get the idea rolling!

[Andrew da Silva]

Could also be used by Atompub and surely other stuff...