Support from Acquia helps fund testing for Drupal Acquia logo

Comments

ezra-g’s picture

Note, this screenshot provided by UTest.

david.moore.ipg’s picture

My experience is that the group buttons show up in the BOTTOM right corner of the row, with an extra line feed that places them below the rest of the content (even on commons.acquia.com). I went into the view (subgroups_main_listing) and reordered the fields, putting "Organic groups: Group: Join link" and "Organic groups: OG: Leave group link" at the top of the list, before "Node: Nid" and now they are in the TOP right corner in a much more logical place and without the extra linefeed.

If this is the best approach to fix this, then I suggest the fields in the view be reordered for the next release of commons.

From the above image it looks like there is an attempt to add post and member counts to this view, which is a most excellent idea. The date created seems less relevant. Also, I would exclude them from the display and rewrite them in with the description like is done now to put them in a list next to the image.

lightsurge’s picture

@david.moore.ipg think this is the new version of the groups directory from #1302984: Evaluate and refactor exposed sorts on /groups listing

From the horizontal rule underneath the links it appears as if they're being formatted as with the 'links inline' css class... so they could do with being floated to the right in this context (and the HR removed).

lightsurge’s picture

Small patch enclosed to fix the 'placed' part of this. The inconsistent size I don't really see as much of a problem?

lightsurge’s picture

Botched that last patch, here's a better one.

lightsurge’s picture

*sigh* once more

ay13’s picture

Status: Active » Needs review
FileSize
15.5 KB

Attached is a patch that correct the issue.

I changed the view to output join and leave fields into the same field so the buttons are always in the same column. Since each group can either be joined or left, there will never be both options at the same time.

lightsurge’s picture

Why not just put them in the same column as I did in #6?

ay13’s picture

Looks like both of our patches have a similar result, just go about it in different ways.

Guess it is up to the maintainers to decide which one to use.

ezra-g’s picture

Status: Needs review » Needs work
FileSize
1.05 KB

I prefer the targeted change to the View export in #6 over the one in #7, however we definitely need some CSS love to finish this issue off as started in #7.

With the changes to CSS selectors in #7, the logout link incorrectly inherits some of the styling from the OG actions links, as in this screenshot:

and the group action links are still somewhat inconsistent as in this screenshot:

I combined the View definition change from #6 with the text-align: center from #7, and added a width of 80px for all of the links, which makes them look more consistent:

I think all that's left to do here is remove the awkward dotted lines below the buttons.

lightsurge’s picture

Here's a patch that addresses this, makes the subscribe buttons go in the middle, and shifts some of the columns around a bit that seemed a bit wonky to me
group directory

lightsurge’s picture

Added ezra-g's changes and made the title link to node

lightsurge’s picture

fixed a typo.. also rewrote the group tags text to look a bit more like it's separate from the title... and now I'm going to leave it alone!

lightsurge’s picture

Status: Needs work » Needs review
ezra-g’s picture

Status: Needs review » Fixed

This is committed. Thanks for the teamwork!

http://drupalcode.org/project/commons.git/commit/38a5909

david.moore.ipg’s picture

Status: Fixed » Needs work

The groups_main_listing Page display in dev does not display any groups (after adding some). Under fields it says it has a missing/broken handler. Removing that does not fix it. Removing all filters does not fix it. The Feed display DOES return the records. Same result in all themes including fusion core (so not a theming issue). Stumped. Groups do show up in My Groups blocks and elsewhere.

lightsurge’s picture

Just built a fresh test site with drush make in branch 2.x and couldn't replicate this. Could this be related to #1350056: git how ?

Although I believe it's git fetch you'd use to update your local copy of a remote branch, I'm not sure if that would pull in updates for the whole Commons installation (including contrib mods etc), just the core Commons profile, or just mess things up for you..

I've not really used git long and I'm not sure how you'd use it to selectively update all the contrib modules that are in drupal_commons.make so that what your're seeing is the entire Commons 2.x dev.

So far I've been using drush make to grab an entire installation each time, until somebody posts a better way of doing so to your issue.

david.moore.ipg’s picture

It is possible. I did git fetch, which updated some files and then ran commons-dev.make to make a new build. Git changed a lot of files in the /commons/.git/objects and /commons/.git/refs/remotes/origin folders, but it did not change the commons-dev.make file in the /commons folder or any of the features in the /commons/modules/features folder (which were created when I initially ran (git clone --branch 6.x-2.x http://git.drupal.org/project/commons.git). When I ran drush make (drush make --working-copy commons-dev.make ./commons-2.x-dev20111205), it redownloaded everything and produced a working platform.

Should I be deleting it and cloning it every time?

david.moore.ipg’s picture

The meat of commons-dev.make is just the following and does not seem to try to get anything from the local git clone anyway. Is that last line right to get the current dev version?
-------------------------------------------------------------
projects[drupal][version] = "6.22"

projects[drupal_commons][type] = "profile"
projects[drupal_commons][download][type] = "git"
projects[drupal_commons][download][url] = "http://git.drupal.org/project/commons.git"
projects[drupal_commons][download][revision] = "6.x-2.x"
--------------------------------------------------------------
I just did a rebuild in a new directory (independent from the git and using the above make file) and got the same result for the groups_main_listing view Page display.

david.moore.ipg’s picture

Status: Needs work » Closed (fixed)

OK, probably something I am doing wrong building my dev site with drush. I dropped the --working-copy from my drush make command and the groups_main_listing view Page display no longer has the missing/broken handler problem but it still does not show new groups that I add (but the feeds display and blocks do). I'm probably just not getting a clean current dev version somehow.

I used
drush make commons-dev.make ./commons-2.x-dev20111206

the last line of my commons-dev.make is (as above)
projects[drupal_commons][download][revision] = "6.x-2.x"

Not sure how to tell from the drush make output where it might be going wrong.

Changing the issue status back to closed (fixed) unless someone can reproduce.

Sorry for the distraction--maybe the breadcrumbs will help somebody else from going wrong.

david.moore.ipg’s picture

Status: Closed (fixed) » Needs review

I may not have the most recent dev, but the problem (if others can reproduce it) appears to be in the sort criteria. Even though the sort criteria display box indicates that the sorting value is set to asc for some items, if you edit the sort criteria, you find that it is not set for the asc ones (neither radio button is selected). Selecting the ascending radio button for each sort criteria fixes it.

the SQL from the original view
ORDER BY node_created UNSORTED, node_title UNSORTED, og_statistics_members_count UNSORTED, og_statistics_posts_count DESC

does not work for MySQL 5.1.49-3
Maybe it works in other versions

lightsurge’s picture

FileSize
66.91 KB
51.82 KB

It sounds like you have a rather mixed up subgroups view.. see attached screengrabs for how it should look.

Are you installing into a blank database or using a pre-existing one? If pre-existing, have you run update.php, cleared your cache, reverted the subgroups view if you've made any changes that you're prepared to lose?

david.moore.ipg’s picture

It is a fresh install with a new database. In 2.3 the groups listing was subgroups_main_listing. But what I get with a drush make from commons-dev.make has groups_main_listing as the view. It also does not have the streams page and has the panels based dashboard back. I saw somewhere that ezra said they were going back to panels, so I assumed this was intentional. I must be getting the wrong branch somehow. This is the guts of the commons-dev.make that I got with git just yesterday. Should it be a different revision to get the current dev version? It almost looks like I am getting the 1.0 branch.

core = 6.x
api = 2

projects[drupal][version] = "6.22"

projects[drupal_commons][type] = "profile"
projects[drupal_commons][download][type] = "git"
projects[drupal_commons][download][url] = "http://git.drupal.org/project/commons.git"
projects[drupal_commons][download][revision] = "6.x-2.x"

ezra-g’s picture

@david.moore.ipg - Ill take a look at this as what you're describing is unexpected to me.

We have not added Panels back - That's likely to happen in the D7 version of Commons.

david.moore.ipg’s picture

OK, it looks like I should be pulling from
http://drupalcode.org/project/commons.git/
instead of
http://git.drupal.org/project/commons.git

Someone should update the "How to Contribute to Commons" page on commons.acquia.com if they really want people to contribute to commons.

ezra-g’s picture

http://git.drupal.org/project/commons.git is correct - Drupalcode.org is just the address of the web-friendly browser.

david.moore.ipg’s picture

http://drupal.org/node/1376248 addresses my issues (#16) with git above (actually a drush issue) and I think the missing sort criteria in groups_main_listing were addressed elsewhere also.

ezra-g’s picture

Status: Needs review » Closed (duplicate)

Marking as a duplicate based on #27.

ezra-g’s picture

Issue summary: View changes

Credit utest.