[layingback]

Nano, Do you think we could have a switch on this? To enable/disable site/user theme when in Admin. I've put a lot of effort into Pro_News previews so that an Admin can edit their articles fully knowing exactly what the final result will look like.

That's not really going to work if the base theme is anything other than default. And worse they are actually going to have to log out to see the true result. Then log in again to adjust, etc.

Understand reason for making change for theme development reasons, but if Admin version of theme already exists ...

(A cms_config_custom setting w/o a ui would suffice.)

[InspectorClueNo]

Would pro_news's preview fail if a webmaster is only using the default theme?

[Eestlane]

The default theme (literally named "default") shouldn´t be touched as it then requires less effort to update Dragonfly itself.

layingback, you could put the preview part in module front-side code (for people with admin rights) (assuming the theme switches back), except if you have the preview on the same page as edit form.

[InspectorClueNo]

Eestlane wrote:

The default theme (literally named "default") shouldn´t be touched

Sorry guys I'm probably going off topic or totally outside to topic contest but I need to understand your problem since I don't see any issue with all the above ... might be coz I'm a newbie lol

I know that the system will fall back to themes/default if the current theme doesn't have the template required. So as module developer shouldn't you think to cover the default theme before anything else?

Also since pro_news it's an addon I presume it will be shipped with it's own template file themes/default/admin/pro_news.html or its own path themes/default/admin/pro_news/*.html

or themes/default/pro_news/admin/ ... don't remember the correct path now sorry ... but you got the idea.

Am I wrong?

[layingback]

I can preview Pro_News in default just as well as any other theme. But if the admin has created greatest_theme_yet and uses it exclusively on their site, then surely that admin wants to see the preview of his latest article in said greatest_theme_yet, and not against the background of a basic theme dating back to 8.0.

I'm not saying either model (same theme throughout or default when in admin) is right or wrong. Just why not give the admin a choice? Rather than throwing away a perfectly viable and currently working option.

[ Eestlane, I do have the preview on same page as edit, 'cos it wouldn't really be a preview otherwise would it? And it is already possible for an Admin to create an article on the user side, but it's not intuitive, and a lot more clicks, and requires more forethought. But that's back to my original point, why are we making things harder for the user, esp. by _removing_ features? ]

[NanoCaiordo]

One thing that stopped me many times to make changes to the ACP was the fear to break themes.
Lately I've done some changes and even after 18 months themes are not correctly updated yet giving hard time to users.

I made my decision to speed up development times as well freeing up themes developers from a lot of work. In the mean time I will ensure a more-then-ever stable ACP.

Can't make omelets without breaking eggs, sorry.

Hope you see my point.

[layingback]

Nano, I understand where you are coming from. And if it has to be, I'll figure out something.

But let me understand. As soon as I log on as an Admin (as well as a user) then my theme is going to switch to default? So short of having 2 browsers open, I'll not be able to view anything in the context of the user theme?

If that's so then the 2 browser mode (FF & Midori) is going to be normal mode of operation. (And in user mode I can see theme but not debug info.)

What about Forum moderators, will they see things in default or user theme? If the latter then I guess I may have to create a Pro_News moderator mode...

As I said, I see your point, but not all admins are super admins. I have several admins who are only admins to maintain/update Pro_News, that's all they have admin access to, and to them default theme is going to appear unique to say the least

[NanoCaiordo]

When you login as admin but you are visiting userland your theme will be based on your user preferences.

Heading back to admin pages will give you the default theme.

Few days ago I've fixed a bug, which will prevent admins to use the preferred theme in userland, caused by my first attempt to fix an old issue

[layingback]

I've just realised the full impact of this, it's not just the "theme" as in template per se, but all the CSS, images, included HTML, folder structure, ... So the preview page isn't just going to look wrong, in some cases it won't even display as a recognisable page. A simple case: main config, select template: How? I can't even display a pick list if I'm not in the right theme. A complex case, the entire page structure is multi column, done in CSS, with content pulled from folder structures held in theme folder, eg my latest template offerings. (I so very nearly took the design decision to place theme specific js in the theme, that would have capped it for sure! Even though that would have been the better design choice. And 1 that I was hoping to move to eventually.)

Sorry, but I can't really see how I'm going to make this work. I thought I'd built a module that the DF community appreciated because it offered so much capability and flexibility. But I think all this is trashed if my users move to 9.2.3.

[ I had been discussing with my beta testers just this last month as to whether Pro_News was done! So perhaps now is the time to just leave it at 9.2.1 compatible, at least for the DF Community version ... ]

I could understand this big a change for, say, DF9 to DF10 upgrade, with time to discuss and develop for it. But not for an 0.0.1 release which is classed as "100% compatible" (see earlier in this thread), and coming at us fast.

The whole edit & preview in Admin model is now irretrievably broken. It's not a case so much of "breaking eggs" as banning eggs. And if I move the Admin edit to user side, then the different abilities for Admins/Users is shot, and so is security, 'cos I can't rely on DF provided security of partitioning Admin and user, and I freely admit I don't have the skill set or inclination to write secure code without DF Core to handle the basics for me.

Given that you want DF Core to operate in default - and I can totally see the rationale for doing that, from Core Dev and Theme Dev viewpoints: is there, or can there be, some way within Pro_News to reset the theme just within Pro_News Admin?

And looking at the bigger picture, if you, us, collectively, want a more than ever stable ACP - which is a v. laudable goal - isn't the correct design to build a middle-ware between ACP and "userland" for addons? Ie. ACP is ACP as it ships with the release. It is always run in default theme, and only modules released by DF Core ever run in it. It is essentially locked down, with no additions or theme changes to potentially break it. But all non-Core modules run in a _logically_ separate Addon Control Panel. They can still both run from the same Admin menu system I think. A typical DF installation probably runs at about 7-9 admin top level menu items, not counting Home and Admin, so restructure into 4 top level menu entries for Core and 4 for Addons, and either let the admin decide up front whether his addonCP runs in user theme or default, or fix it at user, or most flexible of all let the addon itself control it.

What do you think? I know it's very late in the 9.2.3 development/release cycle, but I didn't get much notice...

[layingback]

* bump *

Any ideas, solutions, discussions, welcome.

[rosbif]

NanoCaiordo wrote:

One thing that stopped me many times to make changes to the ACP was the fear to break themes.
Lately I've done some changes and even after 18 months themes are not correctly updated yet giving hard time to users.

I made my decision to speed up development times as well freeing up themes developers from a lot of work. In the mean time I will ensure a more-then-ever stable ACP.

Can't make omelets without breaking eggs, sorry.

Hope you see my point.

Does the ACP not use a template for its display? Surely it is up to the Theme developer to ensure that the Admin pages display correctly; I for one would rather have a broken admin display than a broken module!

At the end of the day surely more choices should be given to module developers than to theme developers?

[layingback]

OK, a week's gone by with no response or discussion, but I've been thinking So I guess I'll have to carry on the discussion ...

It seems to me that if this change goes ahead, then any module which makes full use of the powerful DF template system is going to have problems running on DF 9.2.3. Using anything held in /themes/{your_Theme}/... from the Admin side is going to be tricky to impossible.

There is of course a simple fix: Copy /theme/{your_theme}/ over /theme/default/ but that is simply going to cost us in flexibility and gain us absolutely nothing. Arguably it is worse that where we are today, because at least we have a default theme to switch back to today.

But I do have an alternative suggestion, which meets the original requirements I believe, and costs us nothing.

So what was the original objective? To have a "Static" dependable theme for ACP (where ACP is the Admin Control Panel for the *CORE* functions). I presume benefits are dependable operation, easier support, ability to change anything in ACP without needing to pre-warn and coordinate with DF Theme developers. Plus theme developers will not be *required* to create ACP parts to their themes. All valid - no issue with any of those. But please note that it does not include an objective of forcing the developers of add-ons and modules to conform to the ACP method. It is surely the realm of the Addons/modules individual developers how they want to use themes, and to weigh user benefits against costs.

The Default theme consists of 5 parts (other themes may have more parts): template/ style/ images/ javascript/ theme.php. Currently on 9.2.1 if {your_theme} does not have any entries in template/ then those in Default are going to be used. This has always been this way. However style/ is not quite so clean, as some CSS classes are shared between admin and user side, so any such redefinitions in {your_theme} will have an effect, possibly dterimental, on ACP even if there are no ACP templates in {your_theme}.

But there is a very straightforward fix to this: the last style.css file loaded takes precedence, so why not simply force a 2nd load of theme/default/style/style.css when in ACP (rather than ACP forcing theme = Default), overwriting any style set in {your_theme}?

OK, that's the 2 big ones down, what about images/ javascript/ and theme.php? Well images/ I think is a non-problem, if a theme developer has not included ACP templates then they ought not to have included images to replace those in ACP templates. And javascript/, which incidentally was only introduced in 9.2.1, contains 1 file adminblocks.js would either have to be hard-coded into the calls in ACP to always get called regardless of theme, or, perhaps more correctly, moved somewhere else out of themes/ (the thought of any theme developer wanting to replace such complex, and specific, javascript code with their own version has to be in the 0.001 percentile at most!) This leaves theme.php which IMHO can and should be the only theme.php which ACP uses regardless of theme chosen. That can be achieved by hard-coding calls to it, but I'm sure more elegant alternatives exist, like creating a theme.inc which was used by ACP and which all theme developers had to include from within their theme.php.

And what about themes which do include replacement templates for ACP modules? I would advise including a clear statement in theme.php to the effect that any theme developer who develops replacement ACP templates will be expected to support those users of his/er themes in place of DF, and that s/he must included provided statements in his/er theme.php explaining that, and include instructions on how to revert back to and test under Default before seeking help from DF. Will this have the effect of scaring off theme developers from developing ACP templates in the future? Yes, quite probably, but wasn't that part of the original objective? To have only default available for ACP.

Summary: This new proposal will have the same benefits with respect to themes/template/ and themes/style/ as forcefully switching the theme as currently proposed. But it will also leave a few options that we have in DF today still available for use, that is the theme developer can theme ACP if they wish, eg. Eestlane's incredible reDesign series of themes, and Addon/module developers can use whatever theme they want in Admin mode. Plus DF 9.2.3 will be 100% compatible with all 9.2.1 add-ons and modules and not just some of them. (And Eestlane already has a beautiful admin theme in reDesign3 which I for one do not want to lose. Indeed I'd rather stay on 9.2.1 forever!)

[NanoCaiordo]

Changes reverted to normal theme behavior, my mistake to include such change within the same "minor" version number.

Download available already under 9.x CVS branch (9.2.3.1)

[layingback]

Thank you!

Can I suggest/request that we start a dialogue on the ACP theme issue, with view to creating a 10.0 solution which accommodates all parties to an equal, or at least similar, degree?

[NanoCaiordo]

We will try to change quite few things in 10.x lot of new code will be wrote and many things will be shifted. So as far I can tell there are not definitive solutions atm.
But we can talk about workarounds to maintain some kind of compatibility while shifting things around. Have lot of ideas and if I could type on my keyboard while I was at sleep I could lol. Running low of free time lately ...