URLs are all over and hardcoded

this makes sense. one more requirement is that we need to issue a permanent redirect to the new url for existing rss subscriptions.

this is going to break a lot of random links on people's sites. perhaps we should setup aliases for the old urls?

i'd like to see this tackled in 2 steps. first, remove hard coded paths from og and instead query the view as suggested by morbus. then, all the rest, including upgrade path.

I think this is a great idea, but yes we definitely need a way to alias the old URLs so it won't break pretty much everyone's hardcoded links.

I know I am one of those everyone's on some of the sites I'm responsible for, so I can help with testing the upgrade path once you guys get the first part done.

+1 on this.

I've audited 5.x-3.1 for hardcoded URLs. Attached is a file describing de-duplicated strings to search for to locate all (I hope) hardcoded refs along with filenames. Probably should have done this tedious task against CVS HEAD but I was an hour in before it occurred to me.

There is a good chance I will have time to tackle some work on removing this duplication over the coming weekend.

I don't feel confident to do all of "first, remove hard coded paths from og and instead query the view as suggested by morbus." but I do feel able to tackle the donkey-work of removing the hardcoded paths. If you want me to have a go at this, I need to know 2 things: (1) which version (3.1, HEAD, etc) you want me to work against and (2) where you want the paths hidden - I favour a new function:

function og_url($url_key, $substitution_values) {
  // ...
  return $url_with_substitutions;
}

Thanks for your support and the pointer to the code Morbus.

Though I haven't thought deeply about it I'm worried about how I will handle the argument substitution in the URL returned by views. So, I will try to get og_url() in place first and report back here with a patch before looking at querying views.

i'd like for dww to take a look at og_url() since he did he menu tab stuff for Views ... the new drupal_set_breadcrumb() is kind of a bummer. i worked for a while to get rid of those, because people sometimes put 'og' path under something else, that ought to show up in the breadcrumb.

i agree that menu_set_location() is a bit of voodoo.

Here's a very simple-minded trawl through the code turning hardcoded URLs into og_url() calls. I'm embarrassed to say I haven't even tested this, but with 80 constants to replace I've lost the will to live.

Search for + // TODO: in the patch as well.

Here's a couple of utilities which might be useful. You need GNU M4 with -P.

First, constantify by extracting all og_url('foo') -> define('OG_FOO', 'foo'):

m4_divert(-1)
dnl run this with $ m4 -P <THISFILE> <SOURCEFILES> | sort | uniq > og_url_constants.inc
dnl the resulting file will need a bit of combing by hand - search for literal $
m4_changequote(`[[[', `]]]')
m4_define([[[__constantify]]], [[[OG_[[[]]]m4_translit(m4_patsubst(m4_patsubst(m4_patsubst($1, [[[']]]), %), [[[^og/]]]), [[[a-z/]]], [[[A-Z_]]])_URL]]])
m4_define([[[og_url]]], [[[m4_divert(0)define('__constantify([[[$1]]])', $1);
m4_divert(-1)]]])
m4_divert(-1)

Next, rewrite source file to use references to constants:

m4_divert(-1)
dnl run this with $ m4 -P <THISFILE> <SOURCEFILE> > <NEWNAME.php>
m4_changequote(`[[[', `]]]')
m4_define([[[__constantify]]], [[[OG_[[[]]]m4_translit(m4_patsubst(m4_patsubst(m4_patsubst($1, [[[']]]), %), [[[^og/]]]), [[[a-z/]]], [[[A-Z_]]])_URL]]])
m4_define([[[og_url]]], [[[og_[[[]]]url(__constantify([[[$1]]])[[[]]]m4_ifelse($#,2,[[[, $2]]]))]]])
m4_divert(0)

+1 for this functionality...

Has there been any progress on this?

Not that I know of.

I imagine with all the changes that have gone in since I posted my patch it is going to be pretty stale. The original took the better part of 2 days, much of it a code audit that would need to be repeated. I'm unwilling to reroll the patch unless I'm 99% sure it's going to be used.

I hope it does progress though - this could unlock some nice features / changes in future.

Wow, this is an old issue! I just ran into the "hard coded" /og url issue on a site I am building. If a user tries to submit a content type that must be in a group, and the user is not a member of any group they get an error message that reads "You must [join a group] before posting a [content type]" where "[join a group]" is a link to /og.

I've changed the path to my /og view to "/groups" and thus the user gets a 404. The quick solution is to create a redirect or an alias, but the better solution would be for this not to be hard coded.

Subscribing.

By the way, in og.module, here is the line that is causing this:

<?php
//(on line 1730 in OG 6.x-2.0-rc3)
    form_set_error('title', t('You must <a href="@join">join a group</a> before posting a %type.', array('@join' => url('og'), '%type' => node_get_types('name', $node->type))));
?>

I'd love to be able to just change that url('og') to url('groups'), but I worry that there are other 'og'-related path issues that I am going to encounter in the future. Plus, I always hate hacking modules unless there's absolutely no other way.

Not sure whether this should go under HEAD or dev, but since I'm using 6.x-2.0-rc3 I figured applying some sort of version 2 label might be good.

subscribe

Just to update people on what I ended up doing as a temporary hack (until this is resolved in the og module itself): I installed the URL Redirects module and just did a 302 redirect from /og to /groups (for my site, I wanted it to be at the path /groups). This method is just fine for me temporarily, and allowed me to not have to hack into the og module.

Anyone looking into this ? It basically forbids one to move away from /og/ urls without using hacks (yeah, a redirect is a hack).
Wondering if it should be moved from 'feature request' to 'bug report' to attract eyes...

Subscribing.

subscribing

In my opinion, this could be a bug, because it forces you to modify the default views, and therefore have to load them from the db.

You may not want to edit the default views, so that you can then export your own ones into code, to keep things tidy (version control) and fast (loading from code). At the moment, you cannot do this because you need to edit the default ones or everything falls apart. IF you do, then the views are loading from the database.

The idea would be to clone the default ones, modify them, export them to code, and configure OG to use the cloned and modified views. We might want to place a disclaimer about this next to these configurations, reminding users that it would be then their responsibility.

I understand that the maintainers might be a little reluctant for this to happen, because it would mean that in future upgrades, well, the default views might change and the user custom ones might stop working, so this is why I suggest a disclaimer next to the configuration here, and remind them that if something happens, they should repeat the cloning process, and it would fall out of the support request queue, except for documenting what changed in the default view perhaps. This would not be different from having a modified view however, in terms of time, because you would stil need to restore the default and remodify it, so I guess it would not be that much of a deal...

Let's keep things as is in D6. In D7 everything should be og