Am I in "Sub directories not supported" territory?

Are you sure your group admin has the correct permissions set to be able to create these node types?

Which modules are these (news / images)? I need to load them to test them.

Do you know if they are OG group compatible modules?

Do you see "create news", "create images" links in group menu?

If you do see these in group menu, what is the URL you see in your browser when you click on these links? (i.e.,

If you don't see these links in group menu, what is the URL you see when you click on these from main navigation menu?

Thanks.

The problem is that some time ago, in the early stages of putting this module together, I noticed that the arg() function did not always work during the access verification process. To resolve this, I instead used

$uri_request_id = $_SERVER['REQUEST_URI'];

This, of course, requires that the base url not have a subdirectory so that we always know what the array values (0, 1, 2, etc...) are supposed to be.

At this stage of the game, this appears to be a requirement we have to live with for now.

Thanks for bringing it up. This is very important and people should be well aware of this fact before downloading the module. I've added an additional note in the README file and the project description.

I apparently got og_user_roles to work on a subdomain changing the $uri_request_id and $arg variables this way:

static $arguments, $q;

 if (empty($arguments) || $q != $_GET['q']) {
    	$arguments = explode('/', $_GET['q']);
    	$q = $_GET['q'];
} 

$uri_request_id = '/'.$q;
$arg = $arguments;

and then reworking the subsequent searches for the group node. For example, when viewing a node:

if ($arg[0] == 'node' && is_numeric($arg[1]) && is_null($arg[2])) {
 $location = 1;
 $nodeID = (int)$arg[1];
 $gid = getgid($nodeID, $uid);
}

I don't know if this could cause problems in other places, but it might be useful.

This method of finding a group node using arguments, though, works with blocks and views only when a group context is defined, which is not always the case.

"The problem is that some time ago, in the early stages of putting this module together, I noticed that the arg() function did not always work during the access verification process."

Why did arg()-function fail earlier? Was it because arg() wasn't defined (which can occur at times during cacheing). I posted earlier an issue ("Fatal error: Call to undefined function arg() - problem with cache" at http://drupal.org/node/149469) which was solved. The new code included:

		// Bootstrap if arg() doesn't exist
	    if (!function_exists('arg') && $user->uid > 0){
			drupal_bootstrap(DRUPAL_BOOTSTRAP_PATH); // added as per this issue: http://drupal.org/node/149469
	    }

And as that was in the function og_user_roles_init() ( http://api.drupal.org/api/5/function/hook_init ), this means it will load everytime the module is invoked, and thereby make sure that arg() is always available. So, if I understood the _init-hook correctly, you could use arg() at any place in the code. This of course only matters if the problem with arg() was related to the function not always being loaded.

In any case, I think it would be pretty important to get this working with arg(), since a custom function does not only prevent using of the module in subdirectories, but would cause problems with many other important modules, like "i18n" (Internationalizer, http://drupal.org/project/i18n). i18n adds the language code to the start of the url, as the first argument, in this format: http://somesite.com/en/node/add , instead of http://somesite.com/node/add .

According to this page: http://drupal.org/node/134003 :

The language prefix is removed at the beginning of the request and is added again for internal links to be displayed. Thus, all paths will work the same as before for all the modules enabled.

Afaik that means it'll work with arg(), but I don't think custom functions/variables like the "$_SERVER['REQUEST_URI']", would work like that. Or maybe it will, dunno.

So, do you think it'll be possible to get og_user_roles to work only with arg() for url-arguments at some point?

Why did arg()-function fail earlier? Was it because arg() wasn't defined (which can occur at times during cacheing). I posted earlier an issue ("Fatal error: Call to undefined function arg() - problem with cache" at http://drupal.org/node/149469) which was solved.

arg() didn't fail with an error as it did in the issue you reported (thanks!). What I noticed when trying to track down why node_access would not honor the permissions returned by og_user_roles was that arg() would sometimes not return *anything*. I wrote debug functions to show me what the variable values were, and I have printouts that show nothing returned by arg(). That's why I switched to $uri_request_id in certain cases.

Now, since I use ognodeadd to instead of node_access to check permissions on node creation, I theoretically shouldn't have that problem anymore.

However, I believe there is really only one place now in the entire code where you are affected with this issue:

		// og create nodes (custom node/20 aliased to node/ognodeadd)
		//				  0		  1	  2			      3
		// http://clients.brixrealtyinc.com/node/ognodeadd?type=document&gids[]=12
		//
			if ($arg[1] == 'node') {
			  if (strpos($arg[2], 'ognodeadd') !== false ) {

Do me a favor? I would submit a patch for this, but I already have a patch pending review on another issue. Could you simply change the above to the following and see if that solves everyone's problem? If so, I'll modify the code immediately.

		// og create nodes (custom node/20 aliased to node/ognodeadd)
		//				  0		  1	  2			      3
		// http://clients.brixrealtyinc.com/node/ognodeadd?type=document&gids[]=12
		//
			if (arg(0) == 'node') {
			  if (arg(1) == 'ognodeadd')  {

My bad. What I advised you to do above will not work. Just apply this patch to the latest version of og_user_roles and see if this resolves the issue.

All references to $arg[] (from $uri_request_id) values in the code have been removed in version 5.x-1.3 and replaced with arg() references. The new og_user_roles version will be committed today. This should logically resolve the problem once and for all.

You rock

QFT!

Sorry btw SomebodySysop, I couldn't test the changes and report back in time (assuming the request to test the changes was directed to me).

I can't really test the module at the moment as I again got problems with my drupal development setup, and I haven't figured out why. A million modules and hacks, and I'm still a newb with drupal, not the best combination :D. So, I couldn't yet reliably find out if these changes worked or not.

If everything works with arg() now, that would be great. Also, great to see all this stuff fixed, and so fast too :)

I'm un-clear on this. Are subdirs still off-limits when using this module? I was hoping to setup a separate test environment to make sure I can get everything working as I need it to. But if I can't use a subdir I can't test.

You can use subdirectories.

http://drupal.org/node/183099

Good, because I have been for the last couple days ;)

BTW, Thanks IMMENSELY for making this module. I owe you a few hundred beverages of your choice. The problem this module solves was a major stumbling block for me and kept me from moving forward. Now I'm trying again.

Now if I can get the friggin OG_Forums to acually remain restricted to their groups, I'll be in business.

Please confirm whether this og_user_roles now supports sub-directories as the project bage still indicates it cannot.

Thanks

RIchard

No. They are not supported because of this:

      $ref = $_SERVER["HTTP_REFERER"];
      $ref_url = parse_url($ref);
      $ref_path = $ref_url[path];
      $ref_query = $ref_url[query];
      $ref_arg = explode('/', $ref_path);

This is used to get the group context when all else fails. We expect $ref_arg[0] to be "node". If you're using subdirectories, it will then be your subdirectory. That wouldn't be good.

Hi,

Thanks for the quick response. I would really like this to be rectified, surely there must be a simple way around this (like requesting as part of the config the base part of the URI).

I must not be the only person who is forced to administer the druapl installation into a subdirectory for legacy or other reasons. I have my main site in /a and a test site in /dev. there is also a historical site in another directory as well.

Thanks for your time and consideration.

Richard

This is the only reason that subdirectories are not supported at this time. If you have a patch that will address the issue, I'm willing to try it out.

Of course, you can always just use the application anyway, but anywhere this code is used to try and determine group context it will obviously fail.

As far as I can tell so far, it is currently only used in these situations:

• Allow group admins to approve users
• /upload and /filemanager/active (trying to determine group context)
• og_user_roles_oglogo (placing logo on printer-friendly page)
• og_user_roles_gid_from_referrer() (curently not really used)

Based on the last comment by SomebodySysop...

***********
Of course, you can always just use the application anyway, but anywhere this code is used to try and determine group context it will obviously fail.

As far as I can tell so far, it is currently only used in these situations:

* Allow group admins to approve users
* /upload and /filemanager/active (trying to determine group context)
* og_user_roles_oglogo (placing logo on printer-friendly page)
* og_user_roles_gid_from_referrer() (curently not really used)
*****************

I tried to load and configure OG User Roles to see if it might work in my use case. (I do have Drupal 5.7 loaded in a subdirectory for testing)

Havent gotten past the config ... tried to use the "general tab" of OG User Roles configuration at:

http://services.matrixleadership.com/drupaltest04/admin/og/og_user_roles

Got the following error...
Fatal error: Call to undefined function og_get_types() in /home/tikiwiki/public_html/drupaltest04/sites/all/modules/og_user_roles/og_user_roles.module on line 48

Somehow, I got the impression that it might be possible to use the module in spite of the directories issue. If I cant get past the initial configuration page, is it really possible to use this module under any circumstance in conjunction with a subdirectory installation of Drupal?

If so, what am I missing/misunderstanding/doing wrong?

Thanks

Please see: http://drupal.org/node/273289

Here's a thought. To determine the directory, we could parse $base_url to determine if we're in a subdirectory, something like (I haven't tested):

$ref = $_SERVER["HTTP_REFERER"];
$ref_url = parse_url($ref);
$ref_path = $ref_url[path];
$ref_query = $ref_url[query];
$ref_arg = explode('/', $ref_path);
//Added code
$b_url = parse_url($base_url);
$b_path = $b_url[path];
$b_dirs = explode(" ", $b_path);
foreach ($b_dirs as $b_dir) {
   array_shift($ref_arg);
}

I've just installed this module and may report back if this works, but I thought I'd post while I was thinking about it.

Yes, definately please report back if this works. Thanks!

SomebodySysop,

Thanks for #20
I am already using Organic Groups 5.x-7.2

Was there something else in http://drupal.org/node/273289 that I was supposed to see?

The point of http://drupal.org/node/273289 is to explain that this error:

Call to undefined function og_get_types()

Is resolved by using OG User Roles 5.x-3.2 and OG 5.x-5.7.2 or higher.

Ok,

Maybe I am really thick and I am simply not getting this.

I am using OG User Roles 5.x-3.2 and OG 5.x-5.7.2 and my error/bug

Fatal error: Call to undefined function og_get_types() in /home/tikiwiki/public_html/drupaltest04/sites/all/modules/og_user_roles/og_user_roles.module on line 48

Is not resolved.

FWIW, here is the rest of my config

Drupal 5.7
Configuration file Protected
Cron maintenance tasks Last run 6 weeks 6 days ago
You can run cron manually.
Database schema Up to date
File system Writable (public download method)
ImageAPI PHP
ImageAPI requires at least PHP 5.1.
ImageCache PHP Memory Limit
It is highly recommended that you set you PHP memory_limit to 96M to use imagecache. A 1600x1200 images consumes ~45M of memory when decompressed and there are instances where ImageCache is operating on two decompressed images at once.
JQuery Update Installed correctly
The current installed version of JQuery is 1.1.2
MySQL database 5.0.51a
Organic groups modules Organic groups works best when job_queue.module.module is enabled. See the Integration section of the README file.
PHP 5.0.5
PHP register globals Disabled
Unicode library PHP Mbstring Extension
Web server Apache/1.3.37 (Unix) mod_choke/0.07 mod_auth_passthrough/1.8 mod_log_bytes/1.2 mod_bwlimited/1.4 mod_ssl/2.8.28 OpenSSL/0.9.7a PHP-CGI/0.4mm

Probably nothing you're doing wrong. Just one of those wierd things. Try weighting OG User Roles higher than OG module. Use Module Weight module: http://drupal.org/project/moduleweight

You can see for yourself that the og_get_types() function exists in the OG module. Question is, why are we getting the undefined error when OGR calls it in hook_settings. We shouldn't.

SomebodySysop,

Thanks for the idea.
downloaded and installed moduleweight.

Not sure exactly what you meant by weighting "higher"

If I understand the weighting system
...higher priority is accomplished with lower, especially negative weights
...higher weightings (bigger positive numbers) yield lower execution priority.

I have tried:
OG weight -1
OGR weight -2

OG weight -2
OGR weight -1

OG weight 1
OGR weight 2

OG weight 2
OGR weight 1

Same result (same error as in previous posts) regardless of moduleweight setting

Could it be something else that you can think of?

Yes, weight higher means lower priority. Shot in the dark.

Try putting this line at beginning of hook_settings:

include_once(drupal_get_path('module', 'og'). 'og.module');

See if that makes a difference.

Ok, some news finally.

I have been trying the module in my dev site which is installed in a sub-directory (how this issue started in the first place)

In a fit of passion, I decided to try installing this module on my live (alpha) site and just see what would happen.

It seems to work. Actually, I don't know that yet. It installs successfully and I don't get the error that has been causing so much problem. I will continue to check it out. Will take a while. Probably will need to make a new dev site that more accurately reflects my current livesite configuration.

FWIW ... this site also is installed in a sub-directory. so that's the good news.

The bad news is that the live site has a much cleaner install with many fewer modules than the dev site. Also, minor difference in the version level of PHP and mySQL so discovering what is breaking OGR here would probably be a serious pain in the butt and probably not worth the time.

Thanks for all the attention and the speed of your response.

Jack

OK, but if it ever dawns on you what might have been the problem, please report for future reference. Thanks!

Definitely will.

And looks like I forgot to mention...

i did try your suggestion from #28.

I uninstalled module
Added line of code
Reinstalled the module

no difference in the offending og_get_types() error msg.

thanks

And, by the way, I so appreciate your work on this important module. If you have any other ideas that you want to try for better understanding or to help find a fix, I would be more than willing to test them out since I have the only current example of the consistantly broken installation. If I can help make this better I will be happy to do so.

My last post was mostly about saving you a headache or a wild goose chase.

Sorry if it's rude to re-open a closed request but wouldn't a possible solution be to add these few lines to handle all subdirectory configurations:

$base_path = explode('/', base_path());
// Take into account empty elements created by preceding and trailing slashes
if(count($base_path) > 2) {
// retain first empty element so as not to affect subsequent code
$ref_arg = array_merge(array_slice($ref_arg, 0, 1), array_slice($ref_arg, count($base_path) - 1));
}

So that the problematic code becomes:

$ref = $_SERVER["HTTP_REFERER"];
$ref_url = parse_url($ref);
$ref_path = $ref_url[path];
$ref_query = $ref_url[query];
$ref_arg = explode('/', $ref_path);
$base_path = explode('/', base_path());
if(count($base_path) > 2) {
$ref_arg = array_merge(array_slice($ref_arg, 0, 1), array_slice($ref_arg, count($base_path) - 1));
}

Better still to wrap all of this in a function called get_ref_arg() and call that whenever this code appears as it's the same every time.

I could probably roll a patch if you think this is a good idea although I've never done it before.

Cheers,
Darren.

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.