Changes to group browsing widget & user status updates

I closed #1930666: Support micro-blogging/status in Activity Stream as a duplicate of this one.

Looks good, not sure about the 'Go to full form', though. Do people really see these little UI widgets as forms, or is that more of a techy thing? If people don't see these as forms, then 'going to the full form' wouldn't make sense.

Also, it's pretty obscure.. not sure I'd see it unless I was looking for it.

Just a thought, perhaps, for the post type for example, you could rename the post button 'Quick post', and have another secondary button 'Advanced Post' which stuffs the content user has entered into the body field of the full node form and lets the user do all the advanced stuff?

Agreed, I think "Full screen" or "More posting options" makes more sense.

Overall, this is definitely the right direction. Great work. Any idea on the timeframe for this to go live in Commons?

• Add A settings on the field UI commons_bw_form_field_ui_field_edit_form_alter(), on group-content nodes - "Show in Tabbed widget"
• When displaying the tabs, we can field_attach_form() the node-type and include only the needed fields. We probably will need to take care of validate and submit.

Patch adds the node forms to the group browsing widget.
We still need to theme it and set some fields to be shown on the form by default.

Creating a post:

Revising the previous patch; Allowing the content modules to embed the "Partial form" in their tab.
Notice it's currently implemented only for commons_posts.

That looks really good. This makes perfect for posts and will be an amazing feature ... but is a little strange for Wikis.

The way my institution is currently using the Commons 2.x wikis, each group has a wiki main page and then content arranged under that main page. We have groups for each academic program/year and the tutors structure the content by course and lecture number from the main wiki page. We use notifications for time sensitive information (i.e. the printer is being fixed, special presentation on Friday, etc.) but wikis pages are treated as permanent pages.

If you look at the screen shot posted here: http://drupal.org/node/1932528#comment-7150668 that's a pretty big page to be typing into the box.

My suggestion:

• Add a "wiki main page" as a field on the group (via commons_wiki)
• If the field has a value: show the teaser for the wiki main page and the current create wiki page button
• If it doesn't exist yet show the partial node form (commons_bw_partial_node_form) and on save of the partial node form update the field "wiki main page" on the group (what hook would this be done in?)

If there's agreement on this approach I'd be willing to create a patch for commons_wikis once commons_bw stabilizes.

Updating the patch to the new design. Currently implemented only for posts.

Minor issues:

+++ b/commons_bw.moduleundefined
@@ -23,13 +23,155 @@ function commons_bw_form_alter(&$form, &$form_state, $form_id) {
+  // Map views shown on the BW to their bundle.
+  $views_bundles = array(
+    'commons_bw_posts' => 'post',
+    'commons_bw_q_a' => 'question',
+    'commons_bw_wikis' => 'wiki',
+    'commons_bw_polls' => 'poll',

This should be declared by each module.

+++ b/commons_bw.moduleundefined
@@ -23,13 +23,155 @@ function commons_bw_form_alter(&$form, &$form_state, $form_id) {
+    $view->attachment_before .= render($form);

Lets convert this to a "header" views handler. Less hacky.

+++ b/commons_bw.moduleundefined
@@ -23,13 +23,155 @@ function commons_bw_form_alter(&$form, &$form_state, $form_id) {
+  ¶

Spaces.

+++ b/commons_bw.moduleundefined
@@ -23,13 +23,155 @@ function commons_bw_form_alter(&$form, &$form_state, $form_id) {
+      'query' => array('og_group_ref' => $group_id),

GROUP_AUDIENCE_FIELD

Re-rolling;
- Adding the mini node form as a views area handler.
- Improving the theming.

Notice that the implementation is still only for posts.

Work in progress.
- Adding the post form to the all tab.
- Adding the questions form.

Both 1969088-commons_profile-partial_node_form-11.patch and 1969088-commons_origins-partial_node_form-13.patch are unchanged.

i'm looking to move my site to drupal commons - and one of the things our users do is post photos(multiple) and video (links) as posts in groups.. will that be possible with this "quick post" ?

Case is the events have "pre-event" posts and "post-event" posts - they went and want to share the things they saw... took photos etc - what you are describing here would be perfect!

Nice! How about "Longer post..." for the expand-form link title?

Will this work without depending on commons_wysiwyg? Current dc project is for a more technical user base and we're using Markdown. Seems like it will since one of the above is using the Filtered HTML text format.

- Adding the browsing widget to the homepage.
- Adding the partial form to all BW content types.
- Fixing problem described under #17.
- Updating the "created" text on nodes

off topic: ezra-g, let's talk in our scrum about the whole separation of modules, it makes it much harder to contribute and review.

+ if (!empty($node->{OG_AUDIENCE_FIELD}) && $wrapper->{OG_AUDIENCE_FIELD}->count() == 1) {

We can use og_is_group_content_type()

$variables['submitted'] = t('!type created @interval ago in the !group group by !user', $placeholders);

Let's always show the titles of all groups. make sure to entity_access('view'...) each title

+ if (!empty($node->{OG_AUDIENCE_FIELD}) && $wrapper->{OG_AUDIENCE_FIELD}->count() == 1) {

We can use og_is_group_content_type()

$variables['submitted'] = t('!type created @interval ago in the !group group by !user', $placeholders);

Let's always show the titles of all groups. make sure to entity_access('view'...) each title

+++ b/commons_bw.moduleundefined
@@ -20,16 +30,164 @@ function commons_bw_form_alter(&$form, &$form_state, $form_id) {
+  $form['#id'] = 'commons-bw-partial-' . $bundle . '-node-form';

drupal_css_id()

+++ b/commons_bw.moduleundefined
@@ -20,16 +30,164 @@ function commons_bw_form_alter(&$form, &$form_state, $form_id) {
+    '#path' => 'node/add/' . $bundle,

str_replace('_', '-', $bundle)

+++ b/commons_bw.moduleundefined
@@ -20,16 +30,164 @@ function commons_bw_form_alter(&$form, &$form_state, $form_id) {
+  array_unshift($form['#pre_render'], 'commons_bw_partial_node_form_after_build');

Explain why it needs to be first.

+++ b/commons_bw.moduleundefined
@@ -20,16 +30,164 @@ function commons_bw_form_alter(&$form, &$form_state, $form_id) {
+      $form[$field_name][LANGUAGE_NONE][0]['value']['#id'] .= '-' . $form['#bundle'];

hyphen in bundle, drupal_css_id()

+++ b/commons_bw.moduleundefined
@@ -20,16 +30,164 @@ function commons_bw_form_alter(&$form, &$form_state, $form_id) {
+ * Validation handler; Save the nodes.

Save => Validate.

+++ b/commons_bw.moduleundefined
@@ -112,3 +270,39 @@ function commons_bw_quicktabs_tabstyles() {
+  switch ($view->name) {
+    case 'commons_bw_posts':
+      $empty_message = t('No posts have been created.');
+      break;
+    case 'commons_bw_all':
+      $empty_message = t('Nobody has posted yet.');
+      break;
+    case 'commons_bw_q_a':
+      $empty_message = t('No questions have been asked.');
+      break;
+    case 'commons_bw_wikis':
+      $empty_message = t('No wikis have been added.');
+      break;
+    case 'commons_bw_polls':
+      $empty_message = t('No polls have been added.');

This should move into an info hook provided per module.

Fixing #23

There's a problem with the image ajax upload on the post field; Currently, when uploading an image with the Upload button on the "All" tab, it fails because for some reason file_ajax_upload() expects the form_build_id of the posts form instead of the all's form_build_id.

Fixing the ajax upload issue.
Avoiding rendering several copies of the same form, and instead, moving the form that needs to be duplicated from tab to tab with javascript.

Moving back to "needs work" for adding the "Refine by" checkboxes (Following/ Not following/ Featured).

Because the filters issue as not as trivial as I expected, I'm setting this as ready and opening a new issue for the filters.

+  // If the node has no title, try to create one from the body.
+  if (empty($node->title_field) && empty($node->title) && !empty($wrapper->body) && $wrapper->body->value()) {
+    $node->title = truncate_utf8(check_plain(strip_tags($wrapper->body->value->value())), 30, TRUE, TRUE);
+  }

check_plain() runs htmlspecialchars() which I thought wasn't good in terms of saving node title to database?

Maybe could use truncate_utf8(filter_var($wrapper->body->value->value(), FILTER_SANITIZE_STRING), 30, TRUE, TRUE);

Actually, auto_nodetitle.module does this $output = preg_replace('/[\t\n\r\0\x0B]/', '', strip_tags($output)); which is probably better.

http://drupalcode.org/project/auto_nodetitle.git/blob/refs/heads/7.x-1.x...

Re-rolling #26. and fixing the problem of htmlentities being left encoded on posts titles.

A) The content creation forms are being presented to anonymous users, as shown in this screenshot.

This issue should be resolved with #1984824: Anonymous users are able to create group content

Resolving issues B, C and D.

E:
It seems that it's not necessary to revert the views and panels; If they were not overridden, then applying the patch and clearing the cache will suffice to update them, and if they were overridden , then reverting them will delete the personal changes.
About the title module: I verified that when applying the patches on a 3.x installation and clearing the cache, I get the wanted title fields.

From 1969088-commons_bw-partial_node_form-36.patch:

+++ b/includes/views/handlers/commons_bw_handler_node_partial_form.incundefined
@@ -0,0 +1,42 @@
+    return render(drupal_get_form("commons_bw_partial_node_form__$bundle", $bundle, $group_id));

This gives me the following error. I am running PHP 5.4, so it may not be an issue, but I figured it does not hurt to mention it.

Only variables should be passed by reference in commons_bw_handler_node_partial_form->render()

That warning isn't dependent on a specific PHP version. It's because render() calls drupal_render(), which tries to set the #printed attribute on each element to be rendered, but is unable to since the array is just the return from drupal_get_form.

To get rid of the warning, it should be something like:

  $form = drupal_get_form("commons_bw_partial_node_form__$bundle", $bundle, $group_id);
  return render($form);

The source order of the form could use some love. I am in the process of theming and finding things are out of place without specific styling. The screens are annotated, but it mostly boils down to 3 items.

• The submit button should be consistently placed at the bottom of the form.
• The title should be consistently placed at the top. It may also make sens to avoid using #markup and instead use theme_html_tag() so that the theme can easily add attributes.
• The "Go to full form" link should come before the submit link. Semantically this makes sense as you would want to go to the full form before submitting the form.

The consistency will make things easier to theme without using absolute positioning and also allow for adding wrappers where needed.

To expand on the wiki title issues, they certainly do cause issues. If a wiki is created via the partial form, the title is missing from the teasers. If you go to the full form, there are 2 title fields.

Patch addresses point #42 A/B by moving the title_field base to commons_bw, and by creating there title instances for all content types. @ezra-g Please let me know if you find this a reasonable solution.

In addition, I included the suggestion in #40, and fixed the form elements ordering according to #41.

Notice that the problem described in #43 should not happen with the title module enabled.

Resolving issue #42 C.
I'm uploading again all relevant patches, for the sake of having them all in one comment.

The patch 1969088-commons_groups-partial_node_form-45.patch is wrong, and should be replaced with 1969088-commons_groups-partial_node_form-46.patch. The rest seem fine to me.

@ezra-g, both 42 A/B and 43 are addressed in the latest patches, see comment #44.

Alternatively, is there an API function or setting within Title module we could use instead to set the Title fields? The Commons content type modules currently mostly avoid dependencies on other parts of Commons, so it would be ideal to keep that pattern in place.

@ezra-g, @amitaibu
I believe we can use title_field_replacement_toggle('node', $bundle, 'title') in an hook_update in each of the content modules, without the need to define the title field in the "features". Would that be better?

Fixing a slight problem that arose when we enabled the title field on all content type.

+++ b/commons_bw.moduleundefined
@@ -20,16 +30,222 @@ function commons_bw_form_alter(&$form, &$form_state, $form_id) {
+  $classes = array(
+    'node',
+    'user-picture-available',
+    'commons-bw-partial-node-form',
+    "commons-bw-partial-node-form-$bundle",
+  );
+  $form['#prefix'] = '<div class="' . implode(' ', $classes) . '">';
+  $form['#suffix'] = '</div>';

'user-picture-available' is a class added by the theme for styling purposes and can be added in the theme. It is not critical to move it now, but it is something that I wanted to point out for future reference.

Update:

Something else that would need done here is to use

$form['#theme_wrappers'][] = 'container';
$form['#attributes']['class'] = $classes;

instead of #prefix and #suffix.

Addressing latest issues, except of #54:

$form['#theme_wrappers'][] = 'container';
$form['#attributes']['class'] = $classes;
instead of #prefix and #suffix.

It's not possible to add the class in the proper way because commons origins prints the form classes separately from its attributes array.

This time I verified that everything works as I expected not only on fresh install but also when applying the patches on an existing 3.x installation.

Adding one missing patch.

So glad to have this in, thanks a lot for all the work.
While we're at it; can we also tag users in status updates?

See #1993134: Add possibility to tag users in status updates

Can someone explain me how to get this working? I've tried using 7.x-3.x-dev but I don't see this appearing.

I'm working on a large Commons 3 project and the client really wants this in.
I'm not sure if we can wait for the next release of Commons? Can someone shine a light on this?

Coming here from a query on "drupal commons "what's going on"", and although the micro-tasks here are meant to be broken out into separate issues, the macro of this doesn't seem complete... so I'm wondering if anyone noticed that System automatically closed the issue. :)

Incidentally, I'm actually here looking for the right way to filter things out of the "what's going on" feed. Specifically, on filter criteria like content type or "publish to front page". I've found the "/activity" feed view, and that covers the home page block as well, but "what's going on" is a Panels pane that I'm not finding admin UI configuration for yet, if it exists.

No worries. I must have been tired anyway, to think this issue was related to "what's going on" just because Google said so.

#1919576: How to edit view of "What's going on" panel on homepage has already brought my #70 comment as a feature request. I'll add my related paragraph there.

Updated designs.