Posted by sambody on January 5, 2011 at 3:59am
6 followers
| Project: | Subscriptions |
| Version: | 6.x-1.3 |
| Component: | Miscellaneous |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
Hello, best wishes for the new year,
Subscriptions 6.x-1.3
Drupal 6.19
When the subscriber receive a notification, the urls inside the mail are not diplayed correctly.
Here some's examples :
http:///s/del/node/type/forum/-1/1/7f0e5bf8b98ed1b3b582aa6178ca0c97
http:///user/1/subscriptions
Any idea's ?
Thank you.
Comments
#1
Go to Subscription's configuration page. Are you not seeing a message there?
#2
oh sorry. You're right. There was a message about the taxonomy subscription module. Since i have no need to subscribe to taxonomy, i didn't activate this module. Wrong. It's now activated and no more mess in the notifications mail. Thank you for taking time to answer me.
#3
I have users getting the error and users who don't. Can't figure out why. Any idea?
#4
#5
See #1.
#6
I have no messages in my Subscriptions settings. I also have all the modules enabled and my links still look like the ones in the original post.
#7
I would expect you to see something like the attached screenshot on the admin/settings/subscriptions/settings page...
#3: I have no idea why different users might be getting different results. Apparently, some module causes the url() function to return different results for different users.
#8
I get no error message at all.
#9
I'm on the road and it may be a while before I can look into why you get no message, but in the meantime the information in the screenshot should help to to fix the problem.
#10
I am having the same problem. I have the taxonomy subscription module activated and the base url set.
#11
Ok, please install the Devel module, go to devel/php and run
dpm('[' . url('', array('absolute' => TRUE)). ']');What do you get?
#12
I get:
[http://windstoneeditions.com/]#13
That looks correct and explains why you don't get any message (as in #7). Now try this:
$base = 'user/'. 1;dpm('['. url($base .'/subscriptions', array('absolute' => TRUE)) .']');
That's the code that assembles the
!manage_urlvariable (for user 1).You are on D6, right?
#14
That gives me:
[http://windstoneeditions.com/user/1/subscriptions]Yes, I am using D6
#15
And when you put
!manage_urlinto your template you gethttp:///user/1/subscriptions
? That really puzzles me.
Have you tried the current -dev version?
#16
I'm not sure what you mean by "putting
!manage_urlinto my template." I haven't edited the templates at all, but they already contain!manage_url.I haven't tried the latest dev, but I am having the same broken link problem with a completely unrelated module that also sends out notification emails.
#17
Putting
!manage_urlinto my template or using it from the default template is the same.Please answer my other question in #15, too.
Hear, hear... What is that other module? Does it also use Mail Editor? What makes you think that this could be a Subscriptions issue, if a "completely unrelated module" exhibits the same misbehavior?
#18
!manage_urlin the template results in http:///./user/1/subscriptionsThe other module is Classified Ads. It does not use mail editor. When I posted reply #16, I had only just discovered that it has the same problem. I now doubt that the issue is with Subscriptions (however, UC Stock Notify emails, and emails sent by the module "privatemsg", both contain working links). You may close this issue, but I would like to report back if I find the solution.
#19
I'm still interested in finding a solution, but knowing where not to look definitely helps.
It seems like you have installed a module that attempts to optimize your links, turning external links into internal ones, in a buggy way.
It's not trivial to find the culprit. I see three feasible approaches:
1. You make an educated guess about which of your modules could be messing with your links, and you check your suspicion by disabling it and checking whether the problem perists.
2. You disable half of your modules and check whether the issue is still there. Then you know which half contains the culprit. You disable half of that half, and so on, until you're down to one.
3. You get someone with PHP skills and full access to your site to debug this for you.
#20
It's funny, just now there's a blog post on Drupal Planet that introduces the "External Links" module. I don't know whether you're using External Links, and I have no reason to think that it's anything but perfect. It's just that type of module that (if it's buggy) could have the effect that we're seeing.
#21
We do have the module External Links installed, but I'm not sure if it's the same one you are talking about (Description: "Adds icon next to external links on the site").
Searching drupal last night I found a post from someone who was having the same broken links problem, and it was due to an incorrectly configured crontab (http://drupal.org/node/816448). The broken links only happened with modules that relied on cron to send out notification. And indeed, both Subscriptions and Classified Ads use cron, but the unaffected modules (Stock Notify and privatemsg) do not. On Monday I will have the php guys take a look at that. If the problem persists, I will definitely take your advice and disable some modules to see if any of them are having an effect (we have a list of modules half-a-mile long, so it would not surprise me!).
#22
That's an interesting link.
Have you tried triggering cron interactively (either from the reports page or using Devel)? It would be interesting to see whether the notifications sent out this way will have correct links or not.
Right now, Subscriptions checks url() only interactively (#7), but maybe we should check during cron as well and try to log a helpful message (once we've solved this riddle).
#23
I had not tried running cron manually, but doing so does give correct urls. I will report back once I've had someone take a look at how our cron is configured.
#24
I've just committed an update to the D6 and D7 -dev versions to check for this issue during cron as well, and to provide a watchdog warning if necessary.
#25
Automatically closed -- issue fixed for 2 weeks with no activity.