Compatible with FCK Editor settings?

I think I still need to create those links. I know I haven't sat down to see how these two modules work together.

With respect to FCK editor, I don't have it or use it. What are the URL's that are in question? That is, what are the urls where you should have group context but do not?

For example, like "node/366/fck"?

Thanks!

As a side note to that last thought in the preceding paragraph - have you had any discussions related to context-sensitive roles being added to core?

I was told by Gerhard that Drupal officially does not support permission changes "on-the-fly". http://drupal.org/node/170524#comment-597878

The problem is simply that FCK is "unaware" that while in the group, this editor should show the buttons corresponding to profile three for this particular user, the group owner, rather than the minimal buttons of the standard authenticated user.

I don't use the FCK editor so I can't talk about it specifically. However, I am familiar with this sort of problem. Most of the permission problems in OGR are caused by the Drupal core cache system. See this as well: http://drupal.org/node/165723

My solution has been to turn on the OGR cache setting and apply the patch referred to here: http://drupal.org/node/177948

If this doesn't work, then we need to look at the URL. I recently resolved a similar issue with IMCE. I resolved it using this code, which, as you see, is URL specific. It basically says that if we are at this URL, and can't get the group context normally, then get it from the og_last session code.

 // IMCE
if (arg(0) == 'imce' && (arg(1) == 'browse' || arg(1) == 'upload')) {
$location = 160;
if ($_SESSION['og_last']) {
$gid = $_SESSION['og_last']->nid;
// Set group context.
$group_node = node_load($gid);
og_set_group_context($group_node);
}
}

I've also resolved similar URL issues by getting the group context from the referrer.

So, if clearing the cache doesn't work, then we'll need to know what the URLs are that are being passed when FCK loses group context. You'll need to turn on the OGR debug: http://drupal.org/node/164038. This will show us what the group context is, where's it's being lost, and what the URL(s) are at that point. Attached is an example from the IMCE debug output I created which helped me to resolve that issue.

Since I don't have FCK editor, you'll need to do the footwork on this. I wouldn't lodge an issue until we have a better idea of exactly where we're losing group context.

Does OGR set the roles on the $user object? I think FCK looks to the $user object to determine the role of the user.

Yes. But, OGR can't modify the $user object if it doesn't have a group context.

If OGR is returning the correct group context, but the correct role isn't reflected in the application, then my guess would be that this is definately a cache issue.

Then again, because I don't know FCK, I could be totally off base. See what they say and let me know.

I actually looked into this and wrote some conclusions below. Then, when I finally located fckeditor_profile_load, I realized what the problem might be.

This basically the code which determines the correct editor profile:

 /**
 * Load all profiles. Just load one profile if $name is passed in.
 */
function fckeditor_profile_load($name = '') {
  static $profiles = array();

  if (!$profiles) {
    $roles = user_roles();
    $result = db_query('SELECT * FROM {fckeditor_settings}');
    ...

OG User Roles adds group roles to the user object. Because user_roles() is called directly here, OGR can't work it's magic.

If you could come up with a patch that works which will call $user->roles to get the roles here, that should theoretically resolve your problem.

Here are my original theories before I hit upon the above. Leaving just in case:
===========================================================

Looked into this a bit more. Have you reviewed this issue: http://drupal.org/node/203533

When "$user->roles" is called OGR adds group roles to whatever sitewide roles a user has.

So, if this problem has been fixed, then the next issue is: What is the group context when "$user->roles" is called? If OGR has none, and can't determine the group otherwise, then you'll get the problem you're getting. Using the OGR test option I suggested earlier would help you determine this.

The final question I had was: where is fckeditor_profile_load() in the code? I couldn't find it.

Finally, I noticed that this appears to be the code that determines the profile elements to use:

  // Since fckeditor_profile_load() makes a db hit, only call it when we're pretty sure
  // we're gonna render fckeditor.
  if (!$profile_name) {
    $profile_name = db_result(db_query('SELECT s.name FROM {fckeditor_settings} s INNER JOIN {fckeditor_role} r ON r.name = s.name WHERE r.rid IN (%s)', implode(',', array_keys($user->roles))));
    if (!$profile_name) {
      return $element;
    }
  }

If OGR is returning the correct group context, but you're still not getting the correct results, then it's a cache issue, and the solution would be the one I suggested about clearing the cache.

If it wasn't so big and complicated, I'd try to install it myself. But, I did download and look at the code search around a bit. This is as much as I could come up with for now.

Well, it gets even better. There are 3 places in fckeditor.module where "user_roles" is called. Search for it and you'll see. The first two should be easily replacable with $user->roles. But, the third looks like a problem:

/**
 * Return an HTML form for profile configuration.
 */
function fckeditor_profile_form_build($edit) {
  $edit = (object) $edit;

  $toolbar_options = fckeditor_load_toolbar_options();
  $skin_options = fckeditor_load_skin_options();
  $lang_options = fckeditor_load_lang_options();

  // Only display the roles that currently don't have a fckeditor profile. One
  // profile per role.
  $orig_roles = user_roles(FALSE, 'access fckeditor');
  $roles = $orig_roles;
  if (arg(3) == 'add') {

This could be replaced with $user->roles and user_access('access fckeditor') code. However, the FCKEditor maintainer is going to have to want to make this module compatible with OGR for this change to happen.

Anyway, hopefully this gives you something to work with.

After the rise of the rewritten OGUR 4.x for Drupal 6, in which many unrelated features of OGUR were removed, and nearing a release of Drupal 7, I'm closing down old issues.