Support ⇒ Themes ⇒ Moving PHP Code out of theme templates ⇒ Community Forums ⇒ CPG Dragonfly™ CMS
Forum IndexThemes

Moving PHP Code out of theme templates Reply to topic


Looking to reduce/remove PHP code from templates - reDesign theme.

I can reduce the amount of PHP quite easily to:
<!-- PHP -->
$username = $this->_tpldata['memberrow'][$this->_memberrow_i]['USERNAME'];

$avatar = get_user_avatar($username);

$cpgtpl->assign_vars(array(
      'S_AVATAR_IMG'      => $avatar,
));
<!-- ENDPHP -->

and then bury all the intervening logic in get_user_avatar() in theme.php.

Is there anyway to remove it completely? Ie. a function call I can define in theme.php will get executed for each $template->display('body') call? (In the same way that function OpenTable() in theme.php gets called for each new table declaration.)

TIA!

Pro_News CM™ - Content Management for Dragonfly CMS™

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Linux / 1.3.39 - 2.4.9 / 5.5.42 - 5.6.16 / 5.4.37 - 5.5.11 / 9.4


In a php script use
$array = getusrdata('id or username', 'user_avatar');

$cpgtpl->assign_vars(array(
      'S_AVATAR_IMG' => $array['user_avatar'],
));

.:: I met php the 03 December 2003 :: Unforgettable day! ::.

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
CloudLinux / Apache 2.4 LSAPI / MySQLi 5.6 / PHP 5.6 / DCVS


Thanks for the info, Nano.

I've reduced it now down to just 1 line of PHP. Can't see how to reduce it further. I still need to call my function in theme.php to get and assign the avatar template variable with the next member's username in the list.

Here's the latest code with a bit more to provide context - it's from memberlist.html:
<!-- BEGIN memberrow -->

<!-- PHP -->
get_user_avatar($this->_tpldata['memberrow'][$this->_memberrow_i]['USERNAME']);
<!-- ENDPHP -->

<div class="memberslist_user {memberrow.ROW_CLASS}">< ...


So unless there is a way to "hook" into the template process per user/memberrow template processing loop (from theme.php), I guess this is as good as it can get ...

Down from 25 lines of in-line PHP code originally spread over 2 blocks.

Pro_News CM™ - Content Management for Dragonfly CMS™

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Linux / 1.3.39 - 2.4.9 / 5.5.42 - 5.6.16 / 5.4.37 - 5.5.11 / 9.4


Ok, Member_List module.

{AVATAR_IMG} is already prepared by the module, any issues with using the pre-defined one?

.:: I met php the 03 December 2003 :: Unforgettable day! ::.

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
CloudLinux / Apache 2.4 LSAPI / MySQLi 5.6 / PHP 5.6 / DCVS


Embarassed So focussed on the technical issues of moving PHP code from templates to theme.php that I failed to check the underlying logic! Just picked memberlist at random as the test case! Rolling Eyes

So thanks much, will use what's available of course.

But in general, is there any way to "hook in" to the template processing on DF v9? I couldn't find any examples.

Pro_News CM™ - Content Management for Dragonfly CMS™

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Linux / 1.3.39 - 2.4.9 / 5.5.42 - 5.6.16 / 5.4.37 - 5.5.11 / 9.4


As far I see it could all be reduced to changing _tpldata from private to public, then use theme.php to interact with the data the same way it already happens in template files?

Care needs to be taken because theme.php will probably end-up running those "plug-ins" each and every request.
Maybe starting with a $module_name switch will get things started?

However, simple PHP code such as that is fine, abusing it becomes an issue.

I could make that change for v9 only, v10 instead provides an entirely new template engine, Zope's TAL, which will run along the existing SMARTY template engine.
Easily access predefined PHP functions, variables, database results etc etc directly from the template file which should eliminate many future hooks and other issues.

.:: I met php the 03 December 2003 :: Unforgettable day! ::.

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
CloudLinux / Apache 2.4 LSAPI / MySQLi 5.6 / PHP 5.6 / DCVS


NanoCaiordo wrote
However, simple PHP code such as that is fine, abusing it becomes an issue.


Appreciate the offer to change DF v9, but if 1-liner PHP like the above example is acceptable to you for reDesign, then that solutions works for me, and minimises dependencies.

I already have a procedure in place for the required functions to be housed in theme.php - or theme.inc for add-ons and changes.

So are we in agreement? Because if so I'll set about either: eliminating the PHP calls if they are unnecessary (by using existing Smile or by improving the <!-- IF conditionals); or replacing with 1-liner calls to unique theme.php functions.

Pro_News CM™ - Content Management for Dragonfly CMS™

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Linux / 1.3.39 - 2.4.9 / 5.5.42 - 5.6.16 / 5.4.37 - 5.5.11 / 9.4


layingback wrote
So are we in agreement? Because if so I'll set about either: eliminating the PHP calls if they are unnecessary (by using existing Smile or by improving the <!-- IF conditionals); or replacing with 1-liner calls to unique theme.php functions.


You lost me there ... what do you mean.

.:: I met php the 03 December 2003 :: Unforgettable day! ::.

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
CloudLinux / Apache 2.4 LSAPI / MySQLi 5.6 / PHP 5.6 / DCVS


I know that the DF Team have felt that reDesign3 was not a theme that you would recommend in large part because of the amount and scope of the embedded PHP code.

I'm happy to undertake the task of clearing out ALL the embedded PHP in reDesign3 templates. If I can eliminate PHP code entirely then fine. But if the best I can do - in places - is a 1-line PHP function call to theme.php, is that sufficient? Or will reDesign still be considered "2nd class" because of those (hopefully few) remaining PHP 1-liners?

In other words does the goal have to 0 lines of PHP in a theme or just the absolute minimum possible, to be considered an acceptably-implemented theme? All other things being equal of course. (I would just like to know ahead of time if I'm wasting my time Wink )

Pro_News CM™ - Content Management for Dragonfly CMS™

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Linux / 1.3.39 - 2.4.9 / 5.5.42 - 5.6.16 / 5.4.37 - 5.5.11 / 9.4


If reDesign is all the concerns you have, I believe you will find a version of the theme already stripped down from many sql queries and php code and also v9.3 compatible in the downloads section.

We discussed about this few times already, however if we never wanted php within templates we would have modified the template engine to ignore such tags.
Yes, php is allowed and welcome, abuses are not considered sane, specially when most of the php could be easily shifted to theme.php.

Worrying about the future, Zope's TAL change all of the above Smile

.:: I met php the 03 December 2003 :: Unforgettable day! ::.

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
CloudLinux / Apache 2.4 LSAPI / MySQLi 5.6 / PHP 5.6 / DCVS


Ok, thanks - we will forge ahead.

Understand about reDesigned, but we want to continue the enhancement of reDesign3, not just clean it up.

Already have lots of XHTML issues resolved, also widescreen version, improved text wrapping display for mobiles in Forums, separation of image width and text width in Forums (needs the extended BBCode with paragraph tags), and more, with much more to come.

Pro_News CM™ - Content Management for Dragonfly CMS™

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Linux / 1.3.39 - 2.4.9 / 5.5.42 - 5.6.16 / 5.4.37 - 5.5.11 / 9.4

All times are UTC


Jump to: