Re: [habari-users] Re: Theme calls

[Owen Winkler]

On Jan 13, 2008 8:41 PM, sfong15 <sfo...@gmail.com> wrote:
>
> I did change above to MyTheme->my_silly_function() last night which
> didn't work, may be as you said below it should have been $theme-
> >my_silly_function().

Yes, the call must be $theme->function_name() not MyTheme->function_name()

> There is also one other complication is that I have a few functions
> which are common building blocks for other custom theme functions,
> e.g. formatting output for time difference between 2 dates etc...
> what's best approach to change them?

Say you want a template function that lets you call this to show how
old a post is in days:

echo $theme->age($post);

You would implement a function in your theme class like this:

function filter_theme_call_age( $output, $theme, $post ) {
return $this->date_diff_days($post->pubdate, time());
}

Note that date_diff_days() is also a function you would include in
your theme. This function would not be exposed via the theme object;
in other words, this wouldn't work:

echo $theme->date_diff_days()

Unless you also included:

function filter_theme_call_date_diff_days( $output, $theme, $date1, $date2) {
return $this->date_dif_days( $date1, $date2 );
}

Note that I've completely left the implementation of the
date_diff_days() function to you. ;)

> I suggest there's some sort of announcement in user group for things
> like this to warn user before they hit return to 'svn update'. If I
> have not omitted this I would have tried/tested this in an development
> environement before updating.

Well, I was talking about this today, and it's my impression that:

1) We are still in kind of a pre-release mode, having not released a 1.0 yet.
2) The revision that includes this change is only available via SVN.
3) The commit logs include mention of this change.

I submit that it's reasonably fair to have done this without notice,
assuming that when 0.4 is released we'll make clear mention of this
change in the release notes.

> PS: funny enough after svn updating my theme broke and I saw one error
> message in a blank page. When I managed to fall back to the default
> K2 (removing the theme folder) and logged in there is no error message
> logged? What about the feature of falling back to the system
> defalut theme if custom theme has failed? This would be nice as
> everyone is experimenting here.

This could actually be a security risk. If your custom theme depends
on not displaying data that a core theme does display (for example, if
your theme omits posts with a certain tag from output if you are not a
registered user), then this could cause problems. So unfortunately, I
think you might have to live with this one. Still, you should be able
to get into the admin reasonably easy to change it manually if needed.

Owen

[sfong15]

Now this is similar, Theme::footer() has to be changed to $theme-
>footer() which I did and OK.

I used to do this, say within Class MyTheme extends Theme {}

function get_no( $what_num )
{
$total_time_query= 0;
$num_query= 0;
$no= '';
$profiles= DB::get_profiles();
foreach ( $profiles as $profile ) {
$this->num_query+= 1;
$this->total_time_querying+= $profile->total_time;
}
$this->total_time_querying= number_format( $this->total_time_querying,
4, '.', ',' );
switch( $what_num ) {
case 'query':
$no= $this->num_query;
break;
case 'totaltime':
$no= $this->total_time_querying;
break;
case 'ver':
$no= Version::get_habariversion();
break;
}
echo $no;
}

then display a few numbers in the footer by calling
MyTheme::get_no('totaltime')...etc

The latest revision broke this and returned no error and nothing.

Checked the latest default K2 theme which also returns 0 for
$total_time_querying with 'db_profiling.php included.

Something new with DB::get_profiles() ??

On Jan 14, 11:01 am, "Owen Winkler" <epit...@gmail.com> wrote: