Mission statement is a setting in Drupal at least in the past half decade. It is configurable on a plain textarea on the site settings page (no input format selection) and is hardwired in themes to show on the front page of the site. Or not at all if the theme customization options have it unchecked.

If we go a bit farther, we see we have a way to put text into a region of the website on one specific page here. Except that it is not defined as a "region", so we cannot put different mission statements on different sections. We cannot place any other thing into the mission region (eg. a map) because there is no way to set the input format and the XSS filtering might not allow things we'd want to do (eg. styling of elements). Also, this whole mission setting and its visibility is hidden in the site settings and theme settings, while other blocks we put on the page are editable and their visibility can be set on the blocks admin.

All-in-all if you think this through, making the mission a region and letting people put arbitrary custom blocks in there can have several advantages:

- I can have a mission statement displayed on more then the front page (e.g also on the company team page).
- I can have the mission statement only displayed somewhere else, but not on the front page (eg. only on the company team page).
- I can set whatever input format I want so I can even display complex maps.
- I can put more then one block into that region, so dynamic data can be output there via module defined blocks.

There are two disadvantages:

- Setting up visibility rules for blocks is slightly more complex compared to the theme setting checkbox for the mission statement (but allows for a multitude more options - eg. I can have different missions for different roles).
- The mission statement was used in the sitewide node RSS feed as a description. I am not convinced that the site mission is an adequate description for that feed, so I don't consider this a considerable loss.

An update path should obviously be implemented if the concept is approved. That update path would see if there is a mission statement already and create a custom block for that region if there is one. Otherwise it would not do anything.

The attached patch *removes 26 lines* and *only adds 1* to implement my suggestion. (Yes, I have completely similar plans for the footer message, except it only has a region defined, so it would not have any new lines added except the update path :).

This is how a custom block is set in the region (no surprises):

This is how it is displayed on the same blocks admin page (no visibility is set yet for this block on my site):

Ps. some people said in similar issues that I should consider that blocks module is not required anymore for replacements like Panels to be able to do the whole page display. Well, Panels already exposes blocks, so getting rid of a special case for the site mission would help Panels as well, since it would just treat this as a regular block again.

Files: 
CommentFileSizeAuthor
#42 site-mission-with-fixed-upgrade.patch17.03 KBGábor Hojtsy
Passed: 11228 passes, 0 fails, 0 exceptions
[ View ]
#39 site-mission-with-fixed-upgrade.patch16.85 KBGábor Hojtsy
Failed: 11228 passes, 0 fails, 5 exceptions
[ View ]
#37 remove-mission.patch15.23 KBGábor Hojtsy
Passed: 11228 passes, 0 fails, 0 exceptions
[ View ]
#28 mission-with-site-description.patch15.19 KBGábor Hojtsy
Passed: 11228 passes, 0 fails, 0 exceptions
[ View ]
#26 remove-mission-reroll.patch11.6 KBGábor Hojtsy
Failed: 11164 passes, 0 fails, 8 exceptions
[ View ]
#20 highlight-region.patch11.33 KBGábor Hojtsy
Failed: Failed to apply patch.
[ View ]
#16 highlight-region1.patch9.21 KBBerdir
Failed: 10891 passes, 0 fails, 8 exceptions
[ View ]
#11 highlight-region.patch8.22 KBGábor Hojtsy
Failed: 10752 passes, 30 fails, 2349 exceptions
[ View ]
mission-blocks-admin.jpg47.66 KBGábor Hojtsy
blocks-mission.jpg82.94 KBGábor Hojtsy
remove-mission-statement-setting.patch6.1 KBGábor Hojtsy
Failed: 10791 passes, 0 fails, 8 exceptions
[ View ]

Comments

mfer’s picture

Issue tags:+Needs design review

Adding tag...

earnie’s picture

+1 - I've always been bothered that the mission statement is stuck to the front page only and really bothered that some themes don't even show it.

Zarabadoo’s picture

I think this is a very good move. Due to it's inflexibility, we fairly useless. This would also give the ability of test formatting that was not there previously.

Jacine’s picture

Good one +1

moshe weitzman’s picture

Why not a block that is at top of content region and shows only on [front] page (by default)?

I'd rather not add a Mission Statement region. We'd look at the Mission Statement region every time we visit block admin. Not sure it makes sense in this case.

JohnAlbin’s picture

I really, really like putting Mission Statement in a block. But I really, really don't like the idea of a mission statement region. It would need a different name.

Gábor Hojtsy’s picture

I totally agree that "mission statement" for a region name is dumb :) I'd name it "page highlight" or somesuch. Moshe, a block on the top of the content region is not doing it (without the region), since the "mission region" has its own styling as shown in Garland. Many themes have highly radical styling for the mission regions. Such as Acquia Marina or Acquia Slate to name themes I see often in my backyard. :) Eg. http://hojtsy.hu/ uses Acquia Marina as of now, and that has a page wide top region for the mission statement. We should be able to generalize on a name for this highlighted region, such as "page highlight" or something and run with that IMHO.

earnie’s picture

I not so bothered by the term "mission statement" but I agree that it is not high level enough. I don't think "page highlight" is descriptive enough but "site hightlight" might be. If we're bothered with always seeing it show up in the block management then maybe a module that one can activate for it would suffice. Then the block can be named "mission statement" and those that don't use it won't be bothered with it.

Gábor Hojtsy’s picture

There would obviously be no mission statement block in Drupal 7, unless you create one yourself manually. The mission statement block will be a custom block put into the appropriate region. The only thing "cluttering" up the UI would be the "page highlight" or "site highlight" region on the blocks page. I've seen many sites, where the footer or header regions are just the same "clutter", since we don't put blocks into them. Also, themes are not at all required to implement this site highlight region, as they were not required before to implement the mission statement display either.

So in other words, Drupal 7 installed out of the box will be totally clean of any mention of the mission statement. Sites upgraded from Drupal 6 will have a mission statement custom block migrated over from the setting, but only if they had something set up in that setting.

catch’s picture

Just 'highlight' or page highlight works for me - remember we're comparing this to 'mission statement' - everyone hates mission statements.

I love patches with net negative diffstate.

Gábor Hojtsy’s picture

Status:Active» Needs review
StatusFileSize
new8.22 KB
Failed: 10752 passes, 30 fails, 2349 exceptions
[ View ]

Ok, here is a patched version with a highlight region. Required updating the page tpl as well as the Garland CSS. I'd be happy to put in the update function if the concept is approved.

Status:Needs review» Needs work

The last submitted patch failed testing.

tstoeckler’s picture

+1 on the concept.
The cluttering of regions in the block admin UI (see also turning help into a region...) really calls for something like Block Class module in core. That's a different issue though. I think the deficits in the current user interface should not hold up the infinite flexibility this opens up.

Gábor Hojtsy’s picture

Status:Needs work» Needs review

Uhm, I fail to see how does this break so many tests. Failures include Boot and exit hook invocation, DBLog functionality, Page cache test, Session tests, etc. This is probably something with the testing system.

Dries’s picture

Issue tags:+Favorite-of-Dries

Tagging it. :)

Berdir’s picture

StatusFileSize
new9.21 KB
Failed: 10891 passes, 0 fails, 8 exceptions
[ View ]

page.tpl.php of garland hasn't been changed from mission to highlight, tests seem to pass fine now... (atleast those I tried).

Gábor Hojtsy’s picture

Thanks, I just found it out yesterday, but did not have the chance to reroll the patch. Looking at what the testbot has to say on it :)

Status:Needs review» Needs work

The last submitted patch failed testing.

David_Rothstein’s picture

Subscribing. Seems like the latest test failures/exceptions are just due to RSS feeds (presumably due to the missing feed description?), so hopefully that means they're easy to fix -- no time to look further at the moment, though :)

Gábor Hojtsy’s picture

StatusFileSize
new11.33 KB
Failed: Failed to apply patch.
[ View ]

Adding untested upgrade path based on experience from #428744: Make the main page content a real block and #240873: Move custom help settings to blocks:

- If the site had a mission variable, create a custom block with that text.
- Notify the user that the format might have changed from the original HTML based format.
- Go through all themes and add this block to each theme which had at least one block.
- Put into the highlight region. For those themes which do not support this, the user will see a warning when he goes to the blocks admin page for this theme emitted by Drupal already, which tells them there were blocks in unsupported regions.
- Always remove this site mission variable, since we migrate it.

Still does not include any treatment for the RSS description issue. Should we include some default RSS description or make that a setting on the feed settings page (that would set a mandatory, non-modifiable description for all node feeds emitted by Drupal by default - not sure that is a good thing?).

Would love to see more reviews, also on the migration path. And obviously more testing.

earnie’s picture

Still does not include any treatment for the RSS description issue. Should we include some default RSS description or make that a setting on the feed settings page (that would set a mandatory, non-modifiable description for all node feeds emitted by Drupal by default - not sure that is a good thing?).

Maybe ask for a node for the description on the feed settings page?

Dries’s picture

The RSS problem brings up an interesting point. I think the best solution is to create a "Site description" option on the "RSS publishing" settings page. (I'd rename it from "Site mission" to "Site description" and provide a small upgrade path for that.) It would actually be an improvement because it provides more context to the user, provides more flexibility, and it also enables us to clean up some loose ends. For example, I believe the RSS specification states that the site description can't be longer than 500 characters -- something Drupal never really validated. (Let's _not_ go down the road of using a node for the site description.)

Dries’s picture

By the way, should we kill the "footer message" too?

Gábor Hojtsy’s picture

Assigned:Unassigned» Gábor Hojtsy

Ok, site description makes sense. The footer message and other special theming items are on the plan (blogged at http://hojtsy.hu/blog/2009-apr-09/mission-improve-page-regions-drupal-7), but it is already hard to juggle three parallel patches :)

Going to work on adding the site description RSS setting.

Gábor Hojtsy’s picture

Status:Needs work» Postponed

I was called on #428744: Make the main page content a real block to DBTNG-ify the new and changed database related code (ie. upgrade path and install code). Since my three active patches around this area touch the same install code, I am going to attempt the DBTNG-ification in #240873: Move custom help settings to blocks first and get back to rerolling this patch once that is committed.

Gábor Hojtsy’s picture

Status:Postponed» Needs work
StatusFileSize
new11.6 KB
Failed: 11164 passes, 0 fails, 8 exceptions
[ View ]

Now that #240873: Move custom help settings to blocks is committed, I brought on some of the DBNTG-ification to this patch. Still missing tested upgrade path (the code there is still untested).

Question: wince we are going to have a bunch of these update functions where custom site settings are moved to blocks and entered for all themes, we need to repeat this same pattern in many update functions. Should we keep updating the same update function (ie. mid-DRUPAL-7 upgrade paths are considered required) or should we go back and add to the existing function instead. Given that I've seen some renamed and reorganized update functions, I assume we should be fine moving code into the existing function (which would simplify this patch a lot). Still, would be good to get a go.

catch’s picture

HEAD-HEAD updates aren't supported, so if it makes sense to patch the existing update that sounds good. Also I don't think anyone running HEAD gives a crap about their mission statement.

Gábor Hojtsy’s picture

Status:Needs work» Needs review
StatusFileSize
new15.19 KB
Passed: 11228 passes, 0 fails, 0 exceptions
[ View ]

Worked on this patch more. The attached patch includes the following changes:

- upgrade path rolled into the previously committed help upgrade function (same wrapper code is required, so we avoid some copy-paste + avoid rerunning some queries)
- added site_description variable for RSS feeds (used that the same was the site_mission was used for RSS descriptions)
- migration path for site_mission -> site description as well as the custom block

All done here is compliant to the RSS 2.0 spec (Drupal 7 supports RSS 2.0): http://cyber.law.harvard.edu/rss/rss.html

- description field is required, so this patch adds it back with a setting to modify it
- contrary to what Dries remembered, description does not have any length constraints: "In RSS 0.91, various elements are restricted to 500 or 100 characters. [...] There are no string-length or XML-level limits in RSS 0.92 and greater." therefore we don't need length validation
- as per the spec, the description is a phrase or sentence, and no formatting features are specified; the site mission was overloaded as an RSS description and a special region text before this patch; now you have your block for any kind of formatting and your description for the bare-bones text

I've re-run tests which were marked failing above and all seems to work now (expected due to the added-back description).

I DID NOT test the upgrade path yet though. Reviews are welcome!

Gábor Hojtsy’s picture

BTW alternatively we could print the site slogan as the RSS description. That might overload that setting unnecessarily, but that is more fitting to what RSS specifies ("Phrase or sentence describing the channel.").

Gábor Hojtsy’s picture

Re @Dries' suggestion in #23, footer message elimination issue posted at #453080: Eliminate footer message.

catch’s picture

Don't have time to do an in-depth review but just to say using site slogan makes sense to me (and means we remove one more setting from core which is usually a good thing).

Dries’s picture

In my case, on buytaert.net, there is a significant difference between my site slogan and my site description. I don't feel strong about it though.

ckng’s picture

+1 for this patch
+1 for #13 also, Block Class could be in core

catch’s picture

Status:Needs review» Needs work

After running the update I get undefined variable $highlight in page.tpl.php - looks like _system_theme_data() isn't doing what it needs do. This means the block isn't enabled.

Gábor Hojtsy’s picture

Well, system_theme_data() did the trick for the help region, but then it was modified to _system_theme_date() due to some concerns on disabled blocks (which I could not reproduce on my upgrade testing). Looks like we need to test this area a bit more.

catch’s picture

NB I did this as a HEAD-HEAD upgrade but I don't think that changes anything. Also forgot to mention that my site was put into maintenance mode by the update as well.

Gábor Hojtsy’s picture

Status:Needs work» Needs review
StatusFileSize
new15.23 KB
Passed: 11228 passes, 0 fails, 0 exceptions
[ View ]

@catch: ok, looking at _system_theme_data() and system_theme_data(), calling _system_theme_data() does not help in rebuilding any .info file data indeed. In fact, it does not seem to have any lasting effect. The lasting effect is in system_theme_data(). Looking at that, it does alter the data from _system_theme_data() with system_get_files_database(), which restores data from the database for resaving the data.

So let's take a look at using system_theme_data() instead. Careful inspection of the code on my end did not reveal any issue with disabling themes as sun originally suspected.

Dries’s picture

Status:Needs review» Needs work

I reviewed this patch. I don't think there is an issue with system_theme_data().

I would however rename site_description to feed_description so it is consistent with the other feed settings. This should be a trivial change.

Gábor Hojtsy’s picture

Status:Needs work» Needs review
StatusFileSize
new16.85 KB
Failed: 11228 passes, 0 fails, 5 exceptions
[ View ]

Ok, looked into testing the upgrade path. Fixed a few issues which I found there, and now found that a 6.11 to 7.0-dev upgrade works. I've tested with different combinations of the existing block upgrades and found more errors even :)

Attached patch is tested for upgrade path and works as advertised. Fixes since previous patch:

- Per Dries' request, used feed_description variable name and modified description of setting accordingly.
- Modified suggested CHANGELOG.txt entry accordingly.
- Fixed upgrade path code to not assume each block is migrated (instead of counting with $bid_max +1, +2, +3, etc. we increase $bid_max when we actually save a block). This fixes a bug even in the existing upgrade path (previously if you did not have the contact form help, it did not save the user help properly).
- Fixed use of $theme in the mission update ($theme is the theme name, not an object in this function).

I think this should be ready to go.

Gábor Hojtsy’s picture

BTW did not mention, but also tested that the RSS feed description setting was properly migrated from the site mission too.

Damien Tournoud’s picture

Status:Needs review» Needs work
<?php
// Migrate user help setting.
  
if ($user_help = variable_get('user_registration_help', '')) {
    
db_insert('box')->fields(array('body' => $user_help, 'info' => 'User registration guidelines', 'format' => FILTER_FORMAT_DEFAULT))->execute();
+   
$bid_max++;
     foreach (
$themes_with_blocks as $theme) {
      
// Add user registration help block for themes, which had blocks.
-      $ret[] = update_sql("INSERT INTO {block} (module, delta, theme, status, weight, region, visibility, pages, cache) VALUES ('block', '" . ($bid_max + 2) . "', '" . $theme . "', 1, 5, 'help', 1, 'user/register', -1)");
+     
$ret[] = update_sql("INSERT INTO {block} (module, delta, theme, status, weight, region, visibility, pages, cache) VALUES ('block', '" . $bid_max . "', '" . $theme . "', 1, 5, 'help', 1, 'user/register', -1)");
+    }
[...]
+  }
?>

box.bid is a serial column, so this needs to become:

<?php
  
// Migrate user help setting.
  
if ($user_help = variable_get('user_registration_help', '')) {
    
$bid = db_insert('box')->fields(array('body' => $user_help, 'info' => 'User registration guidelines', 'format' => FILTER_FORMAT_DEFAULT))->execute();
     foreach (
$themes_with_blocks as $theme) {
      
$ret[] = update_sql("INSERT INTO {block} (module, delta, theme, status, weight, region, visibility, pages, cache) VALUES ('block', '" . $bid . "', '" . $theme . "', 1, 5, 'help', 1, 'user/register', -1)");
     }
     [...]
  }
?>
Gábor Hojtsy’s picture

Status:Needs work» Needs review
StatusFileSize
new17.03 KB
Passed: 11228 passes, 0 fails, 0 exceptions
[ View ]

@Damien: you are perfectly right. It was foolish to use $bid_max and then count from there, since the DB might not use sequential numbering. Ok, used the return value of db_insert() instead as I should have had :) Rerolled and retested with the upgrade path still working for the existing and the newly added upgrade code.

Status:Needs review» Needs work

The last submitted patch failed testing.

tstoeckler’s picture

hmmm..... can't reproduce the test failures

catch’s picture

Status:Needs work» Needs review
Gábor Hojtsy’s picture

On #42, it did say it passed testing. Is the bot cross-posting? (given that the previous patch was submitted 15 minutes earlier).

Dries’s picture

Status:Needs review» Fixed

Reviewed and everything looks good to me. Committed to CVS HEAD. The test failure was due to a glitch in the test bot -- that was fixed last night.

Gábor Hojtsy’s picture

Added theme upgrade docs:

http://drupal.org/node/254940#highlight-region :

Mission statement removed, 'highlight' region suggested

In Drupal 6, the page template received a special variable called $mission, which contained the mission statement setting of the website when on the front page. Drupal 6 themes also had an option on the theme settings page to toggle this functionality. Drupal 7 removes the mission setting and the option toggle in favor of the more general custom block placement in regions.

Drupal 7 core themes now include a region named 'highlight' which uses the same display as the mission statement area in Drupal 6. Whether this region has content now depends on administrators setting block placement, and is not limited to the front page only. Content in the highlight region will be surrounded by the block.tpl.php template’s <div> tags and classes, so the CSS used to style this area might need changing.

If your theme ships without a highlight region, you should override the list of regions in your .info file. Such as if you only support content, help and left regions:

regions[content] = Content
regions[left] = Left sidebar
regions[help] = Help

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

naught101’s picture

Yay! Thanks Gábor (and others)!

sangue’s picture

I like this idea, but I know nothing about coding. How do I implement this in my drupal?

mlncn’s picture

#822054: site_mission cruft in system.test and possibly in system.token.inc? identifies leftovers that should be removed / updated? Could someone who worked on this issue verify? Thanks!

@sangue - you do not have to code, in Drupal 7 you simply go to Structure » Blocks (admin/structure/block) and Add block (admin/structure/block/add). Make the Block description Mission statement (or anything that makes sense to you), probably leave the Block title blank, and in the Block body write the mission statement! Under Region settings the recommended region for themes to provide for things like the mission statement is Highlighted content, so go ahead and select that. To replicate Drupal 4.0 to 6 mission statement behavior, under Visibility settings, Pages, Show block on specific pages select Only the listed pages and put <front> in the textarea. Save block and you're done. Did i say simply? Well, maybe not super-simple, but this way is far more flexible...

benjamin, agaric