Add support for custom footer per space

Solid. I think the only reservation I have with this (potentially) is where do we draw the line as to what is "theme" and what is site? It seems almost like there could potentially be a whole bunch of settings that could help isolate a space as a micro-site (at least in a spaces_og setup).

This would be things like
Site name
Front page path
theme
theme settings
footer
Source of primary / secondary links
Other stuff I'm forgetting I'm sure

Not disagreeing with the patch, almost wondering if something like a Spaces Mini-site type of project to accomplish all these kind of things.

Awesome! Are you at drupalcon? I'd love to kind of use this queue to hash out what all settings might make sense to have per space that are traditionally global in scope. The ones above should be debated a bit but in thinking about it a little more I almost wonder if there's a way of (more or less) cloning settings pages and dynamically rewriting them once they are in scope of a space.

This would be something like admin/settings/{anypage} is loaded at {spacename}/settings/{anypage}. Because of the way Strongarm naturally works I'm pretty sure doing a variable_set while inside a space naturally triggers that value to be stored and associated to the space. Then a settings page for the admin of the site could be made to basically just say what menu paths should be replicated / accessible via the space.

Thoughts? Ultimately that's the level of abstraction I'd like to take it too and then a feature could just include the global variable definition of what menu paths are supposed to be in scope of spaces and each organic group can essentially be a full-blown drupal site in terms of customization (if people wanted it to be)

In d6 at least, if using system_settings_form, spaces will remove the usual submit handler and ad it's own that does $space->.. set .. for the variables instead of variable_set. variable_set will always do variable_set (global).

I believe /features path does system settings form (or at least the submit handler), for example.

D6 at least, theme is irrelvent for spaces og has og already has a per theme (I'm on an outdated version of features atm).

What I'd consider vital for adding more settings is throwing them behind some sort of permission check so it's easy to say who and if that setting can be overridden so if someone doesn't want their footer customized, it won't be.

Also, currently it's just spaces_og; should probably be generalized. See how /features patch is handled in spaces_menu and spaces_menu_alter. Or just add it to form at /features (perhaps in a fieldset?).

edit: I followed link to this issue from a tweet so didn't realize it was not a spaces issue but spaces theme .
edit also: google analyics: if override site wide key, won't get any analyics for that space on site wide so not ideal.

@Tharna that article is actually a bit confusing if you are intending to use it in the context of the Google Analytics module.I have a module that got most if not all the way to spaces-integration for GA. I'll try to track it down and dust it off.

Overall, yeah, crazy scope shift! This looks like a sort of Spaces Site Information extension. That would be a fairly small module (as Fox said, would be, oh, 99% UI) so not sure where it should properly go...

yeah a bit of a scope shift, was just throwing the idea out there :)

A bit confusing but need to increase the base of web site.Here could potentially be a whole bunch of settings that could help isolate a space as a micro-site.
skin tag removal at home

tharna I have a need for your sandbox idea, would you be interested in collaborating on it? I could help get it to full project status/comaintain if you have it sandboxed for that reason

tharna I have a need for your sandbox idea, would you be interested in collaborating on it? I could help get it to full project status/comaintain if you have it sandboxed for that reason