flop25 wrote:

Now to talk about "le fond du probleme" :
I don't think that the new system is bad because it does not take into account of local css : as it was said, we can do it with plugins or maybe a futur feature

That can be solve with a small code review. It is far from a blocker.
I will try some new php lines asap to integrate local css (global and/or specific changes).

;-)

rvelices, I've seen you [Subversion] r5177.

So I think you have studied the new architecture, and I suppose you feel concerned the same way about multiple "is_file" for finding the right template. I'll discuss with P@t about this issue.

rvelices wrote:

However I find the solution elegant and I think it will generate quite some themes (partial ones) on the PEM.

Happy to read this point of view :-)

rvelices wrote:

As for my site - I think I will just duplicate default+dark into "mytheme" so there will be no parent theme ...

mytheme will have "default" as parent.

rvelices wrote:

But still I find annoying the missing local-layout. My thumbs are 150x150 and they do not show up correctly in the user view nor in the admin theme -> I will have to make 2 changes ...

Two possibilities for the common local-layout.css:

- We can have the common local-layout.css at the root of themes directory.
- We can have a "Local layout" tab in themes admin pannel, with a big textarea (like LocalFiles Editor) where the user can write his own css rules (saved in config table)

For local-layout.css of each theme, we can keep them, but I don't like the idea...

PS: thanks for the corrections on template.class.php (I didn't understand why $theme could be empty... now I do!)

PS2: there is no performance issues with template modeling.
file_exists function is called only first time, after, cache files are used.
Example, select clear theme, and go on home page. Then, create template directory in clear theme, and create index.tpl file with modifications. Reload home page: changes are not effective until you purge compiled templates.

rvelices wrote:

I would rather have {$theme.id}/theme.css . $theme.id would be automatically generated from the directory name ...

You're right. As a consequence to grum's request, I've made a difference between the theme.id (the directory name) and the theme.name (whatever you want, it is displayed in the "select your interface theme" listbox), this way grum can have theme.id=gally-grum-dark-2 and theme.name = "Gally with the superb Grum Dark, release 2"

P@t wrote:

rvelices wrote:

But still I find annoying the missing local-layout. My thumbs are 150x150 and they do not show up correctly in the user view nor in the admin theme -> I will have to make 2 changes ...

Two possibilities for the common local-layout.css:

- We can have the common local-layout.css at the root of themes directory.
- We can have a "Local layout" tab in themes admin pannel, with a big textarea (like LocalFiles Editor) where the user can write his own css rules (saved in config table)

For local-layout.css of each theme, we can keep them, but I don't like the idea...

PS: thanks for the corrections on template.class.php (I didn't understand why $theme could be empty... now I do!)

PS2: there is no performance issues with template modeling.
file_exists function is called only first time, after, cache files are used.
Example, select clear theme, and go on home page. Then, create template directory in clear theme, and create index.tpl file with modifications. Reload home page: changes are not effective until you purge compiled templates.

May I suggest optional files:
local/rules.css (for all themes)
local/clear-rules.css
local/dark-rules.css
local/Sylvia-rules.css
...
This could be extended later to include languages, and all local files.

So they are in single directory out of all distributed packages.


On PS2: It's perfect!

Great idea VDigital...
There is only one problem:

- If css load is hard coded in header.tpl, this can make apache errors on servers.
- If we use file_exists to load css, there will be performance issues.

Here what I purpose: use prefilter.

if ( !empty($theme) )
{
  $this->set_theme($root, $theme, $path);
  $this->set_prefilter( 'header', array('Template', 'prefilter_local_css') );
}

static function prefilter_local_css($source, &$smarty)
{
  global $conf;

  $root = get_root_url();
  $css = array();

  foreach ($smarty->get_template_vars('themes') as $theme)
  {
    if (file_exists($root.$conf['local_dir'].'/'.$theme['id'].'-rules.css'))
    {
      array_push($css, '<link rel="stylesheet" type="text/css" href="{$ROOT_URL}'.$conf['local_dir'].'/'.$theme['id'].'-rules.css">');
    }
  }
  if (file_exists($root.$conf['local_dir'].'/rules.css'))
  {
    array_push($css, '<link rel="stylesheet" type="text/css" href="{$ROOT_URL}'.$conf['local_dir'].'/rules.css">');
  }

  if (!empty($css))
  {
    $source = str_replace("\n</head>", "\n".implode( "\n", $css )."\n</head>", $source);
  }

  return $source;
}

file_exists is used once with prefilter... what do you think about that?

P@t wrote:

During next upgrades, users will have to be careful with local directory only...
Upgrade will be much easier.

Thanks VDigital for this great idea...

+1