Explode openpublic_defaults

Here's patch one of the process; moving wysiwyg, anything with formats, imce into openpublic formats. Could manage it further by splitting into 3 (wysiwyg, formats, imce), but not sure whether that's worth it. Level of detail and usability to layman vs. developer, etc.

branch is 7.x-2060595

After thinking it through more, it made sense to seperate wysiwyg/imce from text format as depedency issue; need filtered html/full for various exports including node and default content

forgot to move make file

With the latest features, undefined permissions are caught and warned about then ignored, but otherwise the feature is installed as normal.

So this patch combines the ^ and removes the dependencies (via features exclude), then adds them back into the profile .info. This way things like search can be disabled without loosing the rest of the default config.

Messed up rolling patch

missed adding the wysiwyg make file

Ignoring previous patches

Current state of openpublic defaults

api.inc = contains openpublic_defaults_requirements_api, which is only hook implementing openpublic_api's hook_requirments_api. Move to openpublic.profile?

context.inc = contextes -- move to module just about layout?

theme.inc = lot of theme overrides; shouldn't this be in the theme? why are they seperate?

strongarm.inc = some default variables.

theme.inc

block themeing

It overrides the default block themeing to make these changes

+<div id="<?php print $block_html_id; ?>" class="<?php print $classes; ?> section-content"<?php print $attributes; ?>>
 
   <?php print render($title_prefix); ?>
 <?php if ($block->subject): ?>
-  <h2<?php print $title_attributes; ?>><?php print $block->subject ?></h2>
+  <h3
+  <?php print $title_attributes; ?>><?php print $block->subject ?>
+  <?php print !empty($rss) ? $rss : ''; ?>
+  </h3>

So, addition of section-content, which is only referenced in the old openpublic_theme and changing blocks to use h3 instead of h2 and adding the rss link. This should likely be done on the theme layer, though $rss

RSS is set via

function openpublic_defaults_preprocess_block(&$variables) {
  if ($variables['elements']['#block']->module == 'views') {
    $explode = explode("-", $variables['elements']['#block']->delta);
    $view = views_get_view($explode[0]);
    if ($view) {
      foreach ($view->display as $display_name => $display) {
        if ($display_name == 'feed_1') {
        $variables['rss'] = l(theme('image', array('path' => drupal_get_path('module', 'openpublic_defaults') . '/theme/icon-rss.png', 'alt' => "RSS icon", 'title' => 'RSS icon')), $display->display_options['path'], array('html' => TRUE));
        }
      }
    }
  }
}

It's looking for a hard coded feed named feed_1 (default display id for first feed) and adding a link to it based on that. IMO that really should be refactored -- views have a feed setting -- use it. Harder to get into the title of the block (since block title is seperate from block content), but likely can position it similar to current (if really needed), and the theme really should be one handling this.

press release, event (new), and blog have feeds.

However, it looks like openomega is using it's own block theme (or it's parent theme) so this theme override isn't even taking effect with default openpublic install (which also means link to blog/press release rss isn't there).

block-follow

Changes to
This again likely should be on the theme layer -- purely css and sprites (well and configuring the block subject), not a theme override likely unless it's an accessibility thing.

Addthis

/**
 * Implements hook_preprocess_page().
 * This is used to invoke the addthis block and set a template variable to the
 * contents of that block.
 */
function openpublic_defaults_preprocess_page(&$vars) {
  if (module_exists('addthis')) {
    $block = module_invoke('addthis', 'block_view', 'addthis');
    $vars['addthis'] = $block['content'];
  }
}

This is only used in openpublic_theme.

Search term addition

function openpublic_defaults_form_search_form_alter(&$form, &$form_state) {
  $form['#prefix'] = '<div id="search-box"><div id="search-box-inner">';
  $form['#prefix'] .= '<h3>Search: <span class="search-term">' . check_plain(arg(2)) . '</span></h3>';
  $form['#suffix'] = '</div></div>';
}

It adds the term the user searched for to the page.. but that terms already in the search box -- really needed?

Search result author

function openpublic_defaults_process_search_result(&$vars) {
  $lang = 'und';

  // Get the author link based on how "author" is determined, either a node reference or a Drupal user
  if (!empty($vars['result']['node']->field_blog_author)) {
    $author_node = $vars['result']['node']->field_blog_author[$lang][0];
    $vars['author'] = l($author_node['node']->title, 'node/' . $author_node['nid']);
  }
  else {
    $vars['author'] = $vars['result']['user'];
  }

  $vars['type'] = $vars['result']['type'];
  $vars['timestamp'] = format_date($vars['result']['date']);

}

Adds some variables that are again only used in openpublic_theme

function openpublic_defaults_preprocess_search_results(&$vars) {
  $vars['classes_array'][] = 'list-page';
}

A class that only exists in openpublic_theme

At bottom of file is actually not "theme" but blocks that are placed via contextes (in openpublic_default). They display menus. then there's a few more misc things like max 5 lines each

so summery of theme.inc

• Stuff for depracted? openpublic_theme
• Follow block theme override
• blocks
• Misc.

Contextes:
* move to a layout module,
* move stuff like media to associated module

nav_breadcrumb_title -- do we need this?

Fix the media_room nodeblock missing issue

nav_leader/nav_staff -- merge to one for staff-directory (field removed)

no_sidebars -- kill it (just for projects app)

open_government -- where page 'open' went

See if can set context weights via context (https://www.drupal.org/node/1605186) and mere side wide after/before

Move: share stuff to a share configuration feature

It's dead