Homepage activity stream teaser nodes "submitted by" formatting not working. Activity stream "all-site" very confusing when you do not know what group post is coming from.
Currently submit by reads: Submitted by Lisa Rex about 2 hours ago
Should be: Post created 2 hour ago in the Boston group by Lisa Rex

submit date format

Looks like the override code is in commons origins template.tpl.php file -- but is not overriding submitted format.
at Line 370...
// Replace the submitted text on nodes with something a bit more pertinent to
// the content type.
if (variable_get('node_submitted_' . $node->type, TRUE)) {
$node_type_info = node_type_get_type($variables['node']);
$placeholders = array(
'!type' => '' . check_plain($node_type_info->name) . '',
'!user' => $variables['name'],
'!date' => $variables['date'],
'@interval' => format_interval(REQUEST_TIME - $node->created),
);

if (!empty($node->{OG_AUDIENCE_FIELD}) && $wrapper->{OG_AUDIENCE_FIELD}->count() == 1) {
$placeholders['!group'] = l($wrapper->{OG_AUDIENCE_FIELD}->get(0)->label(), 'node/' . $wrapper->{OG_AUDIENCE_FIELD}->get(0)->getIdentifier());
$variables['submitted'] = t('!type created @interval ago in the !group group by !user', $placeholders);
}
else {
$variables['submitted'] = t('!type created @interval ago by !user', $placeholders);
}
}

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Devin Carlson’s picture

Version: 7.x-3.4 » 7.x-3.x-dev
Issue tags: +commons 7.x-3.6 radar

This is caused by the Timeago module which implements hook_process_node() in order to override $variables['submitted'] which takes precedence over hook_preprocess_node (implemented by Commons Origins in order to override $variables['submitted']).

Adding to the 3.6 radar to either remove the "unused" code in commons_origins_preprocess_node() or to fix the changes being overridden by moving the code to something like hook_process_node().

rosemeria’s picture

As far as usability goes, the teaser nodes on homepage activity stream should reference which group the content is coming from, if not on the "submitted" line, then a group ref field.
Thanks for addressing this UI issue.
Rose

japerry’s picture

Assigned: Unassigned » Devin Carlson
ezra-g’s picture

Assigned: Devin Carlson » Unassigned
Issue tags: -commons 7.x-3.6 radar +commons 7.x-3.7 radar

Let's tackle this in the next release.

Sumeet.Pareek’s picture

Status: Active » Needs review
Issue tags: +DrupalWorkParty
FileSize
4.39 KB

I do not think commons would be disabling or letting go of timeago module, it is already quite invested in it - https://drupal.org/project/issues/commons?text=timeago&status=All

So the best bet to address this seemed like adding `hook_process` to the theme's template.php with code for the desired submit string and clean the `hook_preprocess`.

I have tested the attached patch on my local instance and it works for me. Would be great to have it reviewed and get my first full meaningful commit into a public drupal project :-)

PS: I had started work on this yesterday as part of extended #DrupalWorkParty (from D8 to D7 too) and hence the tag.

rosemeria’s picture

Tested patch on local build - works great.

Thanks Sumeet!

ezra-g’s picture

Adding to our (somewhat large) 3.9 radar for review. Thank you for the patch here!

Zarabadoo’s picture

Status: Needs review » Needs work

This looks mostly good, and as much as it pains me to see hook_process used for this, there is really no way around it. One thing that should be done, though is to check the use of specific timeago functionality with a module_exists('timeago') check. I know it is part of the distro and we will likely not be pulling it any time soon, it is good to allow people to turn it off.

Zarabadoo’s picture

Assigned: Unassigned » Zarabadoo
Zarabadoo’s picture

Status: Needs work » Fixed

So I finally rolled back around to this to finish it off and noticed there was a module check. I am not sure if I completely missed it last time (this is not beyond the realm of speculation) or if somehow the patch was updated. Nonetheless, it satisfies me and has been committed. I now deem this issue "fixed".

Status: Fixed » Closed (fixed)

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