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.
Comment | File | Size | Author |
---|---|---|---|
#42 | site-mission-with-fixed-upgrade.patch | 17.03 KB | Gábor Hojtsy |
#39 | site-mission-with-fixed-upgrade.patch | 16.85 KB | Gábor Hojtsy |
#37 | remove-mission.patch | 15.23 KB | Gábor Hojtsy |
#28 | mission-with-site-description.patch | 15.19 KB | Gábor Hojtsy |
#26 | remove-mission-reroll.patch | 11.6 KB | Gábor Hojtsy |
Comments
Comment #1
mfer CreditAttribution: mfer commentedAdding tag...
Comment #2
Anonymous (not verified) CreditAttribution: Anonymous commented+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.
Comment #3
Zarabadoo CreditAttribution: Zarabadoo commentedI 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.
Comment #4
JacineGood one +1
Comment #5
moshe weitzman CreditAttribution: moshe weitzman commentedWhy 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.
Comment #6
JohnAlbinI 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.
Comment #7
Gábor HojtsyI 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.
Comment #8
Anonymous (not verified) CreditAttribution: Anonymous commentedI 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.
Comment #9
Gábor HojtsyThere 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.
Comment #10
catchJust '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.
Comment #11
Gábor HojtsyOk, 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.
Comment #13
tstoeckler+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.
Comment #14
Gábor HojtsyUhm, 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.
Comment #15
Dries CreditAttribution: Dries commentedTagging it. :)
Comment #16
Berdirpage.tpl.php of garland hasn't been changed from mission to highlight, tests seem to pass fine now... (atleast those I tried).
Comment #17
Gábor HojtsyThanks, 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 :)
Comment #19
David_Rothstein CreditAttribution: David_Rothstein commentedSubscribing. 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 :)
Comment #20
Gábor HojtsyAdding 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.
Comment #21
Anonymous (not verified) CreditAttribution: Anonymous commentedMaybe ask for a node for the description on the feed settings page?
Comment #22
Dries CreditAttribution: Dries commentedThe 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.)
Comment #23
Dries CreditAttribution: Dries commentedBy the way, should we kill the "footer message" too?
Comment #24
Gábor HojtsyOk, 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.
Comment #25
Gábor HojtsyI 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.
Comment #26
Gábor HojtsyNow 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.
Comment #27
catchHEAD-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.
Comment #28
Gábor HojtsyWorked 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!
Comment #29
Gábor HojtsyBTW 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.").
Comment #30
Gábor HojtsyRe @Dries' suggestion in #23, footer message elimination issue posted at #453080: Eliminate footer message.
Comment #31
catchDon'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).
Comment #32
Dries CreditAttribution: Dries commentedIn 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.
Comment #33
ckng+1 for this patch
+1 for #13 also, Block Class could be in core
Comment #34
catchAfter 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.
Comment #35
Gábor HojtsyWell, 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.
Comment #36
catchNB 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.
Comment #37
Gábor Hojtsy@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.
Comment #38
Dries CreditAttribution: Dries commentedI 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.
Comment #39
Gábor HojtsyOk, 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.
Comment #40
Gábor HojtsyBTW did not mention, but also tested that the RSS feed description setting was properly migrated from the site mission too.
Comment #41
Damien Tournoud CreditAttribution: Damien Tournoud commentedbox.bid
is a serial column, so this needs to become:Comment #42
Gábor Hojtsy@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.
Comment #44
tstoecklerhmmm..... can't reproduce the test failures
Comment #45
catchComment #46
Gábor HojtsyOn #42, it did say it passed testing. Is the bot cross-posting? (given that the previous patch was submitted 15 minutes earlier).
Comment #47
Dries CreditAttribution: Dries commentedReviewed 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.
Comment #48
Gábor HojtsyAdded theme upgrade docs:
http://drupal.org/node/254940#highlight-region :
Comment #50
naught101 CreditAttribution: naught101 commentedYay! Thanks Gábor (and others)!
Comment #51
sangue CreditAttribution: sangue commentedI like this idea, but I know nothing about coding. How do I implement this in my drupal?
Comment #52
mlncn CreditAttribution: mlncn commented#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