As discussed with Berdir in IRC, we want to improve how relationship type names are displayed. Here are some of the things we need to do:

a) Allow the site admin to specify capitalized versions of both the singular and plural relationship types. Then we would use these capitalized versions at places like the tabs for each relationship type and the relationship types admin page.

b) Allow for one-way types to be branded differently per direction. For instance, for a "follow" relationship type, "followers" could be used for one direction and "following" could be used for the other. This would replace the current "You to Them" and "Them to You" syntax.

c) Add a "Branding" vertical tab on the relationship type where all of this would be configured. This would be similar to what is done for Userpoints module.

Anything else I left out?

--ben

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

PI_Ron’s picture

Hi Ben,

Is it possible to get rid of the 'Relationship/s' wording from the front end?

I have one relationship type - 'Mate/s'

In the user menu I have disabled the default 'My Relationships' item, and added a custom 'Mates' item, that points to site.com/relationships/1 . This works great as (aside from the url), it removes the 'relationships' wording.
However there are other areas where its not so simple, and I'm wondering if there are any plans to incorporate features to accomplish the following:

  • Remove 'Current' tab from /relationships screen.
  • Set a relationship type as the default selected tab, and furthest left tab on the /relationships screen. eg. 'Mates' 'Received Requests' ' Sent Requests'
  • User Account Screen, either of the following points:
    • Option to remove 'Relationships' tab from User account screen (global not per user).
    • Option to replace the 'Relationships' tab text with a chosen default relationship type. eg.At user/id the tabs would be: 'View' 'Edit' 'Mates'
  • When viewing another users account, remove the 'Relationships' heading, the 'Relationship actions' heading, and just have a 'Send mate request' link.

Thanks for the great module.

Berdir’s picture

Please open a separate issue for that.

This issue is just about *how* a relationship type name is displayed and to improve that both in the UI (with some new options) and in the code (with a new API function instead of duplicating the code all over the place).

We're working hard on improving the module and bringing it up to speed but we need to take one step after another. Trying to do everything at once usually leads nowhere.

PI_Ron’s picture

Hi Berdir,

Thanks for both of your work on this module.

Do you think what Ive mentioned should be in a single issue, or one for each point?

Berdir’s picture

Start with a single issue, we can still split it up later.

Berdir’s picture

Status: Active » Needs review
FileSize
17.25 KB

I've started with this. The general problem is that a) and b) combined give us in total 8 different names (6 new) that need to be configured. We need to solve two issues now:

- We need to find a good way to display them. Right now, it's just one long vertical tab and it's the default one (becaus it's the only fieldset added by user_relationships.module).Maybe split it up somehow? (non-capitalized and capitalized)

- We need to find and also properly explain the fallback strategy when one of these fields is empty. Example: The longest one is 'Capitalized Plural reversed name'. If that is empty, we check 'Reversed plural name' first, then 'Reversed name' (or plural?) and finally name. Actually, we probably want to check the capitalized version first for each of the fallbacks.

Note that this patch is incomplete but I thought it makes sense for a first review (to clear the two above points before I invest more time). So, what this patch does:
1. Update the database schema for the new names. Only additions, so you can (and must..) run the update already.
2. Added an API function to return the correct name according to the flags: plural, reversed, capitalized
3. Added a new "Branding" vertical tab with all these options. Note: I haven't updated the descriptions yet. You're welcome to provide those.
4. Some unrelated refactoring for saving/updating relationship types. If you notice an issues, report them too.

BenK’s picture

Status: Needs review » Needs work

Hey Berdir,

I took a look at the patch and I think it's a nice start. I like your general approach. A few thoughts:

a) I think we should divide up the "Branding" vertical tab into "Forward Branding" and "Reverse Branding" or something like that. Or maybe the regular direction could be "Name variations" and the reverse could be "Reverse branding". To me, the logical split is between forward and reverse. Because if your looking at one vertical tab, you'll see slight variations of the same word (as opposed to jumping around between words). Also, dividing up the forward and reverse tabs would simplify the individual field labels... We wouldn't need a "Capitalized Plural Reverse Name"--since it's already on the reverse branding tab, we'd just write "Capitalized and plural".

b) I'm still trying to wrap my head around the term "reverse." Because when you're setting up a relationship type, it's confusing to keep track of which direction is which. For example, let's say I want to have "followers" and "followees". Which should be the name and which should be the reverse name? We just need some way to make this more intuitive. Is the "forward" name always "You to Them" and the reverse always "Them to You". Should we put that in the help text?

c) Maybe all of the "reverse" stuff should have it's own checkbox to enable reverse branding? This way, all of those fields could be hidden by default using #states. If you checked the box, then they would appear. Because perhaps some content types wouldn't need this at all.

d) I like your fallback strategy, but I'm wondering if that adds a lot of complexity. It just seems difficult to explain. What if we just required the capitalized and plural versions (in the forward direction)? We could even fill those fields in by default by taking the relationship name and capitalizing the first name and adding a "s" to the plural (which could be changed by the admin). And then if the reverse checkbox was enabled, only then would those reverse fields be taken into account.

e) As I understand it, none of the forward and reverse branding is actually implemented yet. At least, I don't see any of it actually used yet.

Thoughts?

--Ben

Berdir’s picture

a) Hm yes, we can do that. Only problem is that I'm not sure if #states can deal with whole fieldsets (especially if they're vertical tabs), I will have to try that out.

b) Not sure about using the You to them etc. stuff. However, I'm sure we can better explain it. Here are the facts:

- Reverse only applies to one-way relationships
- Reverse is from the requestee to the requester
- requester is the user that initiated the relationship

I'm counting on you to come up with a useful description that takes the above points into account :)

c) As said above, we already have that checkbox, the one-way one. Because reverse only applies to one-way relationships.

d) The problem with requiring them is that then these settings wouldn't belong into a vertical tab according to the UI Patterns talk (only optional stuff that can be ignored belongs there). But yes, we could, instead of having a "runtime fallback strategy", pre-fil them with some sane defaults. I see two problems there, however:

- Your suggestions (add "s" suffix and capitalize first character) might not work for other languages ( For example in german, the 's' would only work for some terms and for example in russian, it wouldn't help at all). So I'm not sure about that.

- When should these defaults be added? It could for example even be done in directly in the form, with JS. However, my suggestion would be during submit. And if there were any defaults added, we could inform the user with a warning message, display what has been done and display a link to the edit form if he wants to change it.

What do you think?

e) Correct, nothing implemented yet.

BenK’s picture

For those following this issue thread, Berdir and I had a discussion about this in IRC and he'll be implementing a new patch that incorporates our changes.

Berdir’s picture

a) Ok, I've split it up. I've named it 'One-way reversed branding' for now. The idea is to make it obvious that it only applies then.

b) Added a description, not perfect yet...

c) As we discussed, these settings can be tied to the existing one way checkbox. However, it doesn't work completely yet. Specifically, the vertical tab can't be hidden completely right. I wrote a patch, see #1148950: Applying #states to a vertical tab does not update the vertical tabs menu.

Will continue here later but I thought I post an updated patch so that you check it out in the meantime.

Berdir’s picture

Status: Needs work » Needs review
Berdir’s picture

Updated patch because I commited another one with an update function.

Note that if you had this patch applied already, the easiest way is to reset the schema_version for user_relationships to 7001, remove all new name columns from the user_relationship table (everything with name in it except name and plural_name). Then, re-run the updates.

Berdir’s picture

And now with patch...

mrf’s picture

Applied the latest patch and everything seems to be working correctly.

I'm wondering if there really is a need to have capitalized labels stored separately. In my experience CSS's text transform has always been able to handle all the different strange capitalization requirements I've ever run across for this kind of label, we'd just need to make sure that everything was themed in a way that made using CSS a possibility.

mrf’s picture

Status: Needs review » Needs work

Also, just noticed that when I first visit the branding vertical tab both the standard fields and the one way fields appear together until I click through to one of the other tabs. Not sure if this is somehow related to #9, but wanted to call attention to it.

Berdir’s picture

That is probably because you're missing the core patch linked in #9.

Berdir’s picture

Status: Needs work » Needs review
FileSize
67.01 KB

I continued to work on this patch. It is not yet finished but I started to convert *all* places where the relationship name is displayed.

It is not finished yet, and I'm sure not all places are using the correct replacement yet (for example capitalized/reverse) but it's a start and since I'm at the i18n sprint in Berlin, It is now properly integrated into i18n.module according to the new UI guidelines, which means that there is a Translate tab when you edit a relationship type that allows you to easily translate all of that relationship type on a single page.

Patch is huge and most likely conflicts with the permission patch in the other issue...

BenK’s picture

Berdir, can you remind me how to "reset the schema_version for user_relationships to 7001". I remember doing this a few times in phpmyadmin, but I'm trying to remember the query.

--Ben

BenK’s picture

Just making a note on this thread that I should update the schema like this:

UPDATE system SET schema_version = xx WHERE name = 'module_name';

So in this case it would be:

UPDATE system SET schema_version = 7001 WHERE name = 'user_relationships';

BenK’s picture

Hey Berdir,

I followed your instructions to reset the schema and delete the added columns. But now I've got the following error reported after running update.php:

Update #7002
Failed: PDOException: SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'DEFAULT NULL' at line 1: ALTER TABLE {user_relationships} CHANGE `rid` `Array` DEFAULT NULL; Array ( ) in db_change_field() (line 2888 of /Users/benkaplan/git/drupal-7.0b/includes/database/database.inc).

What should I do next?

--Ben

BenK’s picture

And now I'm getting a WSOD on the site. Looking in my PHP logs, the error is:

PHP Fatal error: Call to undefined function ur_tt() in /Users/benkaplan/git/drupal-7.0b/sites/all/modules/user_relationships/user_relationship_blocks/templates/user_relationships-block.tpl.php on line 11

--Ben

Berdir’s picture

FileSize
68.23 KB

Re-rolled against the latest -dev version. I've fixed the reported fatal error but haven't done any other testing.

It is *very* likely that this will not work anymore with i18n because the API probably changed, but please test and report anything you can find.

Berdir’s picture

Re-roll against latest HEAD.

Note that the update function has been renumbered...

Still requires lots and lots of testing...

Berdir’s picture

#22: 1115956_revival_the_second.patch queued for re-testing.

Status: Needs review » Needs work

The last submitted patch, 1115956_revival_the_second.patch, failed testing.

Berdir’s picture

Status: Needs work » Needs review
FileSize
66.44 KB

And, yet another re-roll and yet another update function number ;)

sw3b’s picture

Status: Needs review » Needs work

I test on my side and i'm getting this error when i'm cliking on the translation tab...

Fatal error: Call to undefined function i18n_string_translate_page() in /home/sw3b/www/www/sites/all/modules/user_relationships/user_relationships.admin.inc on line 546

For what i can see, the new interface is looking very good !! Nice work...

Berdir’s picture

Status: Needs work » Needs review
FileSize
64.71 KB

Updated i18n integration. Did get quite nice.

sw3b’s picture

Ok now the interface to translate work but the string like "become name relation" does not translate. Also I notice that in the page http://mywebsite.com/relationships the term friend is not translate.... is the integration of the tranlation is suppose to be done or only the engine to translate ?!?

Berdir’s picture

Try this patch.

Completely untested, not sure if this works.

sw3b’s picture

Status: Needs review » Needs work

I'm getting this error after applying the patch to Dev version....

Fatal error: Cannot use object of type stdClass as array in /home/sw3b/www/www/sites/all/modules/user_relationships/user_relationships.module on line 1068

Berdir’s picture

Status: Needs work » Needs review

Ok, enough is enough, sorry about that :)

Added basic test coverage for translating type names, please try this patch.

It's very likely that not everything will use the proper version of the name or correctly be translated, I just added two very basic test assertions. Once this stuff is basically working, I plan on commiting it and then deal with the (hopefully) smaller follow-up issues in separate issues.

Berdir’s picture

FileSize
69.87 KB

Erm, now with patch.

sw3b’s picture

Status: Needs review » Reviewed & tested by the community

Right on the money with this pacth ! I put it on latest dev (march 6) version and everything look super great !

Nice work !!!

Berdir’s picture

Status: Reviewed & tested by the community » Fixed

Ok, thanks for testing, commited!

Status: Fixed » Closed (fixed)

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

hedley’s picture

If you're updating an existing site to latest dev, or applying this patch you should be aware that 'Custom screen messages' placeholders will need to be updated from '%relationship_name' to '@rel_name'

bbu23’s picture

Issue summary: View changes

Hello,

Por the patch about relationship types translations, you should have considered to add the option for locale too.
I mean, if i18n is not enable, at least you can translate the string with locale.

here are few lines from user_relationships.module (line 1064)

<?php
// Attemt to translate the name.
if (module_exists('i18n_string')) {
    $string_object = i18n_string_object_translate('user_relationships_type', $type);
    $name_value = !empty($string_object->$name) ? $string_object->$name : $string_object->name;
  }
  else {
    $name_value = !empty($type->$name) ? $type->$name : $type->name;
  }
?>

it should be something like :

<?php
// Attempt to translate the name.
if (module_exists('i18n_string')) {
    $string_object = i18n_string_object_translate('user_relationships_type', $type);
    $name_value = !empty($string_object->$name) ? $string_object->$name : $string_object->name;
  }
  elseif (module_exists('locale')) {
    $name_value = !empty($type->$name) ? locale($type->$name) : locale($type->name);
  }
  else {
    $name_value = !empty($type->$name) ? $type->$name : $type->name;
  }
?>