[development] more consistency in theme functions and output concepts.

[Bèr Kessels]

Op woensdag 10 mei 2006 12:30, schreef Gerhard Killesreiter:
> I think this is a pretty bad idea. This way every themer has a chance to
> remove our XSS checks.


Sounds fair. 

However, we now do *not* have a central place. Quite some of our 
checks/filters DO appear in theme functions!

So I agree that the theme layer might not be the best place, but fact remains 
that we need a *central* place, not?

IMO having it "all over the place" is worse then having it in a theme layer 
where we say "themes are the ones to filter/sanitize all output".

Too often do I now find that theme_a calls theme_b and that theme_b filters 
out stuff that theme_a wants to put in. MOre often even do I find that 
function_x filters code, and makes it a chunk of HTML, while theme_a wants to 
do something usefull to that chunk and therefore wishes to receive the 
original data. I tried to address these three issue (security, theme-power 
and overhead) in one "guideline".

> > * t(): on the same level. Only in the theme level do we output t()ed
> > strings. This makes it a lot simpler, because you know that functions and
> > methods pass the original strings along, and that they are only
> > translated in the VERY END. This should also make testing against strings
> > a lot easier. I even found a critical sec. issue that opened the "access
> > control open to the world" because I translated two string similar.

> I am not too thrilled about that either. Themers might decide to change
> strings and then we would need theme dependend translations.

Why would that be? You will not receive any new strings. Its only the place 
where strings are translated that will change. IMO the "place where the 
string is injected into the HTML" is by far the best place to translate that 
string.

Bèr