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.drup
al.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.drup
al.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/7
9008), 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
<weitzmantejasa.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.drup
al.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

Quoting catch <catch56googlemail.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.
>

On Thu, Feb 21, 2008 at 8:20 PM, Earl Miles <merlinlogrus.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

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") ?>
>
>

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
<merlinlogrus.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