Making blocks from some setting in Drupal 7?
Hey, On the quest to better format support in Drupal 7, I made a spreadsheet of how certain texts are filtered in Drupal as of now: http://groups.drupal.org/node/9072 The table shows some interesting bits, like the user signature format changing based on the actual format used for a comment, which is quite interesting; or some node details filter_xss()-ed in action implementations, when they would probably better filtered with their format. (Let's follow up about these on the node.) Anyway, one itch which shows up here is to add support for site settings like "footer message", "mission", etc. These are without format support now, so even if the whole of your site uses wiki formatting, you cannot use that here. Or if you have an input policy, it is not enforced here. There are basically two ways to solve this: - add format support for site variables (that would be a format column in the db, which is only used for some settings) - move these settings to an area which supports formats already (nodes, blocks come to mind) After thinking about this more and more, I came to the realization that making these blocks would be fun. The affected settings are: - site mission - site footer - user registration help - contact page help Some reasons for why this could be cool to be blocks: - provide these with format support instantly - give examples on things put in the footer region, content top region, etc - give examples on blocks limited to pages (mission to front page, helps limited to pages they provide help for) - get rid of special "theme feature" settings for displaying the mission, as it is a normal block (btw I'd get rid of the "search feature" provided by themes and let them use/theme the search block instead - those reading the Drupal 5 Themes book probably realized how awfully confusing are the various search input options) There is still one core setting left which cannot be made a block, the site offline message. And there are certainly other contrib use cases, where making blocks is not a good idea, so moving the above stuff to blocks would not solve the generic problem. The reason I am bringing it up regardless is that it would (IMHO) provide some more consistency and better features for these settings. What do you think? Ps. As far as easy theming of these go when moved to blocks, there is a DROP task to replace numeric block deltas with named deltas: http://drupal.org/node/216072 Which would result in block-system-mission.tpl.php and the like :) Gabor
After thinking about this more and more, I came to the realization that making these blocks would be fun.
That is an *awesome* idea, Gábor! One thing that crossed my mind: To automatically insert a site's title in the site mission/footer block then, we'd probably need Token (or parts of it) in core. Although a lightweight placeholder replacement function would also work out, IMO we do not need to re-invent the wheel. Daniel
On the quest to better format support in Drupal 7, I made a spreadsheet of how certain texts are filtered in Drupal as of now: http://groups.drupal.org/node/9072
quite an interesting table. at least none of them are unfiltered.
- site mission - site footer - user registration help - contact page help
The first two work as blocks, but the help texts do not IMO. We have hook_help(), and thats how those texts get added to the page. It would ugly to combine hook_help() texts and help texts that are each stored as blocks. I think the right solution for the help texts is to integrate an improved version of helptip module into core. That module provides a GUI for hook_help(). Admins can fill out a form and put help text onto any page that they desire. The storage of these texts can be done in several ways (i believe that helptip uses nodes), but any way we do it should also supprt an input format as Gabor suggests. The variable system is apparently not designed for long variable values (Dries asserts this at http://drupal.org/node/79008), so I don't think we should be putting help texts and email templates there anyway.
On Thu, Feb 21, 2008 at 2:13 PM, Moshe Weitzman <weitzman@tejasa.com> wrote:
On the quest to better format support in Drupal 7, I made a spreadsheet of how certain texts are filtered in Drupal as of now: http://groups.drupal.org/node/9072
quite an interesting table. at least none of them are unfiltered.
- site mission - site footer - user registration help - contact page help
The first two work as blocks, but the help texts do not IMO. We have hook_help(), and thats how those texts get added to the page. It would ugly to combine hook_help() texts and help texts that are each stored as blocks.
I think the right solution for the help texts is to integrate an improved version of helptip module into core. That module provides a GUI for hook_help(). Admins can fill out a form and put help text onto any page that they desire. The storage of these texts can be done in several ways (i believe that helptip uses nodes), but any way we do it should also supprt an input format as Gabor suggests.
Hm, so what do blocks do? They allow you to put some content into any selected region and limit to certain pages. What does helptip allow you to do? To put some text into one fixed region (the help region), and limit to certain pages. By making the help region a real theme region, you instantly get all of help tip into core, right? Then the system module can expose a "built-in help block" which would contain output of the help hook, and position it into the help region. Gabor
To add something else in. On one of the recent menu issues someone suggested making the primary and secondary links handling themed blocks rather than the special exception we have now. This'd fit nicely with the search block issue, and the mission etc. I'd really like to see all these things turned into blocks + regions - makes loads of sense.
Quoting catch <catch56@googlemail.com>:
To add something else in. On one of the recent menu issues someone suggested making the primary and secondary links handling themed blocks rather than the special exception we have now. This'd fit nicely with the search block issue, and the mission etc. I'd really like to see all these things turned into blocks + regions - makes loads of sense.
+1 from me. I had trouble adapting the Primary/Secondary menus into something meaningful when I first started with Drupal. I have longed for a block that displays the secondary menus when the primary menu item is clicked. Breaking the Administration menus into another block is something else I do. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
Gábor Hojtsy wrote:
What do you think?
My one concern here is that because the block system is push, not pull, all blocks in all regions are always generated, regardless of whether the page needs them. That means we run the risk of degrading performance by generating a whole bunch of material that we have no intention of displaying, unless we have some way for the theme to signal which regions it wishes to generate on any given template. And that's a tough thing to do in the current system. This is one of the reasons I like the panels approach, but that's still pretty far from being able to fully emulate the block system.
I thought blocks were only generated if they needed to be based on its "Page specific visibility settings"? In that case, they would just need to be defaulted with specific <front> or whatever settings to emulate current behavior. Earl Miles wrote:
Gábor Hojtsy wrote:
What do you think?
My one concern here is that because the block system is push, not pull, all blocks in all regions are always generated, regardless of whether the page needs them. That means we run the risk of degrading performance by generating a whole bunch of material that we have no intention of displaying, unless we have some way for the theme to signal which regions it wishes to generate on any given template. And that's a tough thing to do in the current system.
This is one of the reasons I like the panels approach, but that's still pretty far from being able to fully emulate the block system.
Ah, yes, if a page doesn't pull a region, it still generates blocks for it, unless those blocks think they aren't needed for the page. I'd like to see us make that a little smarter. Maybe each page request could have a list of regions it needs built? Not sure how that could work off the top of my head. The easiest way would be to have an admin/settings/regions page, similar to admin/settings/blocks, that allowed you to set a 'Region page specific visibility'. Another might be to have the menu store the regions a page needs. Probably half a dozen other approaches that could be explored as well. Aaron Winborn wrote:
I thought blocks were only generated if they needed to be based on its "Page specific visibility settings"? In that case, they would just need to be defaulted with specific <front> or whatever settings to emulate current behavior.
Earl Miles wrote:
Gábor Hojtsy wrote:
What do you think?
My one concern here is that because the block system is push, not pull, all blocks in all regions are always generated, regardless of whether the page needs them. That means we run the risk of degrading performance by generating a whole bunch of material that we have no intention of displaying, unless we have some way for the theme to signal which regions it wishes to generate on any given template. And that's a tough thing to do in the current system.
This is one of the reasons I like the panels approach, but that's still pretty far from being able to fully emulate the block system.
On Thu, Feb 21, 2008 at 8:20 PM, Earl Miles <merlin@logrus.com> wrote:
Gábor Hojtsy wrote:
What do you think?
My one concern here is that because the block system is push, not pull, all blocks in all regions are always generated, regardless of whether the page needs them. That means we run the risk of degrading performance by generating a whole bunch of material that we have no intention of displaying, unless we have some way for the theme to signal which regions it wishes to generate on any given template. And that's a tough thing to do in the current system.
This is one of the reasons I like the panels approach, but that's still pretty far from being able to fully emulate the block system.
Completely understood. I always disliked that PHPTemplate builds all block regions regardless of needs. I used to use lots of conditionals around block region bulilding in my pure PHP themes (before migrating over to PHPTemplate not long ago, due to its other advantages). So after all, a possible explosion of blocks / regions would require some (more) benchmarking and thinking about block performance. (Given that I am working primarily on better support for WYSIWYG right now, this is not my top priority unfortunately). Gabor
On 22 Feb 2008, at 3:20 PM, Gábor Hojtsy wrote:
Completely understood. I always disliked that PHPTemplate builds all block regions regardless of needs. I used to use lots of conditionals around block region bulilding in my pure PHP themes
This might not be a popular idea, but perhaps we should make the region calls pull. Instead of <?php print $region ?> have it be <?php print drupal_region ("region") ?>
That would be great in my opinion. Not only would it help performance, but it also makes it easier to see whats happening in the code and remove some of the things that tends to cause confusion - like $footer vs. $footer_message. Moshe Weitzman wrote:
works for me.
This might not be a popular idea, but perhaps we should make the region calls pull.
Instead of <?php print $region ?> have it be <?php print drupal_region("region") ?>
+1 for pull Folkert adrian rossouw wrote:
On 22 Feb 2008, at 3:20 PM, G�bor Hojtsy wrote:
Completely understood. I always disliked that PHPTemplate builds all
block regions regardless of needs. I used to use lots of conditionals
around block region bulilding in my pure PHP themes
This might not be a popular idea, but perhaps we should make the region calls pull.
Instead of <?php print $region ?> have it be <?php print drupal_region("region") ?>
Yep, I used something similar to this used to be possible in 4.7 and I used it to create a region and put it in into a panel using Panels so that I could still use block subscription and fole filtering logic etc within a panel. For some reason it quit working in 4.7 most likely because I was causing some system internal that shouldn't have been done. Love to see this supported. On Feb 22, 2008, at 5:20 AM, Gábor Hojtsy wrote:
On Thu, Feb 21, 2008 at 8:20 PM, Earl Miles <merlin@logrus.com> wrote:
Gábor Hojtsy wrote:
What do you think?
My one concern here is that because the block system is push, not pull, all blocks in all regions are always generated, regardless of whether the page needs them. That means we run the risk of degrading performance by generating a whole bunch of material that we have no intention of displaying, unless we have some way for the theme to signal which regions it wishes to generate on any given template. And that's a tough thing to do in the current system.
This is one of the reasons I like the panels approach, but that's still pretty far from being able to fully emulate the block system.
Completely understood. I always disliked that PHPTemplate builds all block regions regardless of needs. I used to use lots of conditionals around block region bulilding in my pure PHP themes (before migrating over to PHPTemplate not long ago, due to its other advantages). So after all, a possible explosion of blocks / regions would require some (more) benchmarking and thinking about block performance. (Given that I am working primarily on better support for WYSIWYG right now, this is not my top priority unfortunately).
Gabor
That's also the original logic behind the component module: http://drupal.org/project/component That said, -1 to putting function calls directly in the template. They're not portable to other template engines other than PHPTemplate. That's also putting too much logic into a template, where it belongs in a theme/template (preprocess) function. On Saturday 23 February 2008, David Metzler wrote:
Yep, I used something similar to this used to be possible in 4.7 and I used it to create a region and put it in into a panel using Panels so that I could still use block subscription and fole filtering logic etc within a panel.
For some reason it quit working in 4.7 most likely because I was causing some system internal that shouldn't have been done.
Love to see this supported.
On Feb 22, 2008, at 5:20 AM, Gábor Hojtsy wrote:
On Thu, Feb 21, 2008 at 8:20 PM, Earl Miles <merlin@logrus.com> wrote:
Gábor Hojtsy wrote:
What do you think?
My one concern here is that because the block system is push, not pull, all blocks in all regions are always generated, regardless of whether the page needs them. That means we run the risk of degrading performance by generating a whole bunch of material that we have no intention of displaying, unless we have some way for the theme to signal which regions it wishes to generate on any given template. And that's a tough thing to do in the current system.
This is one of the reasons I like the panels approach, but that's still pretty far from being able to fully emulate the block system.
Completely understood. I always disliked that PHPTemplate builds all block regions regardless of needs. I used to use lots of conditionals around block region bulilding in my pure PHP themes (before migrating over to PHPTemplate not long ago, due to its other advantages). So after all, a possible explosion of blocks / regions would require some (more) benchmarking and thinking about block performance. (Given that I am working primarily on better support for WYSIWYG right now, this is not my top priority unfortunately).
Gabor
-- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
Larry Garfield wrote:
That's also the original logic behind the component module:
http://drupal.org/project/component
That said, -1 to putting function calls directly in the template. They're not portable to other template engines other than PHPTemplate. That's also putting too much logic into a template, where it belongs in a theme/template (preprocess) function.
We already rely on templates being able to use the t() function and theme ('links') appears in the standard page.tpl.php as well.
Noone *likes* having function calls there. It is just a necessity if you don't want to render and query and do all kinds of work that will never be emitted on the page. So please try to come up with an alternative instead of voicing an aestetic objection that is shared by everyone. Theme engines that don't allow function calls in the template are free to organize themselves as they wish and thus just pass variables like we do today. On Sat, Feb 23, 2008 at 3:17 PM, Larry Garfield <larry@garfieldtech.com> wrote:
That's also the original logic behind the component module:
http://drupal.org/project/component
That said, -1 to putting function calls directly in the template. They're not portable to other template engines other than PHPTemplate. That's also putting too much logic into a template, where it belongs in a theme/template (preprocess) function.
On Saturday 23 February 2008, David Metzler wrote:
Yep, I used something similar to this used to be possible in 4.7 and I used it to create a region and put it in into a panel using Panels so that I could still use block subscription and fole filtering logic etc within a panel.
For some reason it quit working in 4.7 most likely because I was causing some system internal that shouldn't have been done.
Love to see this supported.
On Feb 22, 2008, at 5:20 AM, Gábor Hojtsy wrote:
On Thu, Feb 21, 2008 at 8:20 PM, Earl Miles <merlin@logrus.com> wrote:
Gábor Hojtsy wrote:
What do you think?
My one concern here is that because the block system is push, not pull, all blocks in all regions are always generated, regardless of whether the page needs them. That means we run the risk of degrading performance by generating a whole bunch of material that we have no intention of displaying, unless we have some way for the theme to signal which regions it wishes to generate on any given template. And that's a tough thing to do in the current system.
This is one of the reasons I like the panels approach, but that's still pretty far from being able to fully emulate the block system.
Completely understood. I always disliked that PHPTemplate builds all block regions regardless of needs. I used to use lots of conditionals around block region bulilding in my pure PHP themes (before migrating over to PHPTemplate not long ago, due to its other advantages). So after all, a possible explosion of blocks / regions would require some (more) benchmarking and thinking about block performance. (Given that I am working primarily on better support for WYSIWYG right now, this is not my top priority unfortunately).
Gabor
-- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012
"If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
What about putting block data in a $blocks variable, and then calling theme('region', $blocks['left']);? That would take the same approach as theme('links',...), whose approach I like (I might be the only one :D). Dmitri On Feb 23, 2008, at 12:59 PM, Moshe Weitzman wrote:
Noone *likes* having function calls there. It is just a necessity if you don't want to render and query and do all kinds of work that will never be emitted on the page. So please try to come up with an alternative instead of voicing an aestetic objection that is shared by everyone.
Theme engines that don't allow function calls in the template are free to organize themselves as they wish and thus just pass variables like we do today.
On Sat, Feb 23, 2008 at 3:17 PM, Larry Garfield <larry@garfieldtech.com
wrote: That's also the original logic behind the component module:
http://drupal.org/project/component
That said, -1 to putting function calls directly in the template. They're not portable to other template engines other than PHPTemplate. That's also putting too much logic into a template, where it belongs in a theme/ template (preprocess) function.
On Saturday 23 February 2008, David Metzler wrote:
Yep, I used something similar to this used to be possible in 4.7 and I used it to create a region and put it in into a panel using Panels so that I could still use block subscription and fole filtering logic etc within a panel.
For some reason it quit working in 4.7 most likely because I was causing some system internal that shouldn't have been done.
Love to see this supported.
On Feb 22, 2008, at 5:20 AM, Gábor Hojtsy wrote:
On Thu, Feb 21, 2008 at 8:20 PM, Earl Miles <merlin@logrus.com> wrote:
Gábor Hojtsy wrote:
What do you think?
My one concern here is that because the block system is push, not pull, all blocks in all regions are always generated, regardless of whether the page needs them. That means we run the risk of degrading performance by generating a whole bunch of material that we have no intention of displaying, unless we have some way for the theme to signal which regions it wishes to generate on any given template. And that's a tough thing to do in the current system.
This is one of the reasons I like the panels approach, but that's still pretty far from being able to fully emulate the block system.
Completely understood. I always disliked that PHPTemplate builds all block regions regardless of needs. I used to use lots of conditionals around block region bulilding in my pure PHP themes (before migrating over to PHPTemplate not long ago, due to its other advantages). So after all, a possible explosion of blocks / regions would require some (more) benchmarking and thinking about block performance. (Given that I am working primarily on better support for WYSIWYG right now, this is not my top priority unfortunately).
Gabor
-- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012
"If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
Putting function calls in the themes page.tpl.php file would be a step backward for the theming system. For the page.tpl.php file the problem of only having the regions you want in the theme is solved in D5 with hook_regions and in D6 with the themes .info file. If we want to keep the separation of layers in drupals PAC like architecture and allow for any kind of plug-able presentation layer function calls in the page.tpl.php file isn't a good idea. The way we use theme('links', $primary_links) in the page.tpl.php files seems out of place. Shouldn't that be pushed to the preprocess function? Matt On Feb 23, 2008, at 3:17 PM, Larry Garfield wrote:
That's also the original logic behind the component module:
http://drupal.org/project/component
That said, -1 to putting function calls directly in the template. They're not portable to other template engines other than PHPTemplate. That's also putting too much logic into a template, where it belongs in a theme/ template (preprocess) function.
On Saturday 23 February 2008, David Metzler wrote:
Yep, I used something similar to this used to be possible in 4.7 and I used it to create a region and put it in into a panel using Panels so that I could still use block subscription and fole filtering logic etc within a panel.
For some reason it quit working in 4.7 most likely because I was causing some system internal that shouldn't have been done.
Love to see this supported.
On Feb 22, 2008, at 5:20 AM, Gábor Hojtsy wrote:
On Thu, Feb 21, 2008 at 8:20 PM, Earl Miles <merlin@logrus.com> wrote:
Gábor Hojtsy wrote:
What do you think?
My one concern here is that because the block system is push, not pull, all blocks in all regions are always generated, regardless of whether the page needs them. That means we run the risk of degrading performance by generating a whole bunch of material that we have no intention of displaying, unless we have some way for the theme to signal which regions it wishes to generate on any given template. And that's a tough thing to do in the current system.
This is one of the reasons I like the panels approach, but that's still pretty far from being able to fully emulate the block system.
Completely understood. I always disliked that PHPTemplate builds all block regions regardless of needs. I used to use lots of conditionals around block region bulilding in my pure PHP themes (before migrating over to PHPTemplate not long ago, due to its other advantages). So after all, a possible explosion of blocks / regions would require some (more) benchmarking and thinking about block performance. (Given that I am working primarily on better support for WYSIWYG right now, this is not my top priority unfortunately).
Gabor
-- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012
"If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
Seeing that there are many different opinions about this, would it be possible to make this configurable? Make the function-based thing and then have a setting like "CREATE_MAGICAL_REGION_VARS", either in template.php, settings.php or even the database. After all, if we have the functions already, creating the extra vars should be trivial. Matthew Farina wrote:
Putting function calls in the themes page.tpl.php file would be a step backward for the theming system.
For the page.tpl.php file the problem of only having the regions you want in the theme is solved in D5 with hook_regions and in D6 with the themes .info file.
If we want to keep the separation of layers in drupals PAC <http://www.dossier-andreas.net/software_architecture/pac.html> like architecture and allow for any kind of plug-able presentation layer function calls in the page.tpl.php file isn't a good idea.
The way we use theme('links', $primary_links) in the page.tpl.php files seems out of place. Shouldn't that be pushed to the preprocess function?
Matt
On Feb 23, 2008, at 3:17 PM, Larry Garfield wrote:
That's also the original logic behind the component module:
http://drupal.org/project/component
That said, -1 to putting function calls directly in the template. They're not portable to other template engines other than PHPTemplate. That's also putting too much logic into a template, where it belongs in a theme/template (preprocess) function.
On Saturday 23 February 2008, David Metzler wrote:
Yep, I used something similar to this used to be possible in 4.7 and I used it to create a region and put it in into a panel using Panels so that I could still use block subscription and fole filtering logic etc within a panel.
For some reason it quit working in 4.7 most likely because I was causing some system internal that shouldn't have been done.
Love to see this supported.
On Feb 22, 2008, at 5:20 AM, Gábor Hojtsy wrote:
On Thu, Feb 21, 2008 at 8:20 PM, Earl Miles <merlin@logrus.com> wrote:
Gábor Hojtsy wrote:
What do you think?
My one concern here is that because the block system is push, not pull, all blocks in all regions are always generated, regardless of whether the page needs them. That means we run the risk of degrading performance by generating a whole bunch of material that we have no intention of displaying, unless we have some way for the theme to signal which regions it wishes to generate on any given template. And that's a tough thing to do in the current system.
This is one of the reasons I like the panels approach, but that's still pretty far from being able to fully emulate the block system.
Completely understood. I always disliked that PHPTemplate builds all block regions regardless of needs. I used to use lots of conditionals around block region bulilding in my pure PHP themes (before migrating over to PHPTemplate not long ago, due to its other advantages). So after all, a possible explosion of blocks / regions would require some (more) benchmarking and thinking about block performance. (Given that I am working primarily on better support for WYSIWYG right now, this is not my top priority unfortunately).
Gabor
-- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012
"If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
Matthew Farina wrote:
Putting function calls in the themes page.tpl.php file would be a step backward for the theming system.
Again, I must disagree with this assertion. We *must* allow calling the t() function in templates. We generally allow calling the theme() function in templates. (Note that doing regions is currently done with theme('blocks', 'regionname'); This wouldn't be a step backward from our current setup; and the t() function itself poses a really special problem. It's difficult to put all text in preprocess functions, and if you put text in page.tpl.php then t() must be available for translation. Yes, this is a damned-if-you-do-damned-if-you-don't problem. Smarty and PHPTal are both capable of allowing function calls. Any templating system we use simply needs to be able to allow at least those 2 function calls
After a couple days thinking about this I have to agree and this fits the PAC and MVC paradigms. t() is used for translations which is part of the presentation layer. theme() calls are, also, part of the presentation layer. So, I can see both of these making perfect sense in .tpl.php files. And, now that I've started to use regions in more unconventional ways, like embedding the region in the node.tpl.php file[1], I can see not wanting to build all regions on every page load. [1] https://www.innovatingtomorrow.net/2007/12/11/how-embed-region-node Quoting Earl Miles <merlin@logrus.com>:
Matthew Farina wrote:
Putting function calls in the themes page.tpl.php file would be a step backward for the theming system.
Again, I must disagree with this assertion.
We *must* allow calling the t() function in templates.
We generally allow calling the theme() function in templates. (Note that doing regions is currently done with theme('blocks', 'regionname');
This wouldn't be a step backward from our current setup; and the t() function itself poses a really special problem. It's difficult to put all text in preprocess functions, and if you put text in page.tpl.php then t() must be available for translation. Yes, this is a damned-if-you-do-damned-if-you-don't problem.
Smarty and PHPTal are both capable of allowing function calls. Any templating system we use simply needs to be able to allow at least those 2 function calls
participants (15)
-
Aaron Winborn -
adrian rossouw -
catch -
Daniel F. Kudwien -
David Metzler -
Dmitri Gaskin -
Earl Miles -
Earnie Boyd -
Folkert Hielema -
Gábor Hojtsy -
Larry Garfield -
matt＠mattfarina.com -
Matthew Farina
-
Mikkel Høgh -
Moshe Weitzman