Answers.Body: <p>It seems your host configuration is the problem, as it forces redirection from https to http and somehow lost the parameters in the convertion</p>
  
  <p>Can you try to access the https version with the parameters?</p>
  
  <p><a href="https://mysite.org/sites/all/modules/civicrm/extern/url.php?u=193&amp;qid=52" rel="nofollow">https://mysite.org/sites/all/modules/civicrm/extern/url.php?u=193&amp;qid=52</a></p>
  
  <p>In any case, if you want to use https, be sure your configuration is set with https (CIVICRM_UF_BASEURL in your civicrm.settings.php), so it directly creates the right url and avoid a redirect</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-06-17T15:42:31.743Z
Answers.Text: Thank you, I changed `CIVICRM_UF_BASEURL` to https:// but the links are still being created as http:// in the CiviMail body. However, now when I manually modify the CiviMail links to https and paste them in the browser, all is working fine! So I just need to figure out how to tell CiviMail to use https:// when constructing the tracked URLs.
Answers.UserDisplayName: LunkRat
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-06-17T16:24:00.387Z
Answers.Text: check the resource url configuration page too, just to be sure it's with https too.
Answers.UserDisplayName: Xavier
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-06-17T17:51:41.550Z
Answers.Text: double-checked that resource URLs all have https:// and even switched on "Force Secure URLs (SSL) "—still CiviMail writes them all as http://
Answers.UserDisplayName: LunkRat
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-06-17T20:32:49.930Z
Answers.Text: Does that happen for the `/extern/url.php` URLs, or for the ones that are translated? I'm looking int TrackableURL.php and it runs this: `$redirect = $config->userFrameworkResourceURL . "extern/url.php?u=$id";` It also does some caching here, so maybe Civi cache is involved.
Answers.UserDisplayName: Nicholai
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-06-17T20:54:24.727Z
Answers.Text: @Nicholai and @Xavier thanks for all of your very helpful insights. I discovered that my `CIVICRM_UF_BASEURL` was being overwritten by Aegir, of course. So I prevented that (temporarily) and everything works now. I just need to figure out how to protect my customizations to `civicrm.settings.php` from being dominated by Aegir ... any ideas there (off-topic)
Answers.UserDisplayName: LunkRat
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-06-17T21:04:51.547Z
Answers.Text: That may be a question for omega8.cc, but didn't civi used to have a local.settings.php or something similar that could override?
Answers.UserDisplayName: Nicholai
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-06-17T07:46:53.443Z
Answers.LastActivityDate: 2015-06-17T07:46:53.443Z
Answers.UserDisplayName: Xavier
Body: <p>Any mailing that I send through CiviMail converts URLs to links in the form of: </p>
  
  <p><code>http://mysite.org/sites/all/modules/civicrm/extern/url.php?u=193&amp;qid=52</code></p>
  
  <p>But when I visit this URL I get a white page with "Missing input parameters" and the address is <code>http://mysite.org/sites/all/modules/civicrm/extern/url.php</code></p>
  
  <p>Curiously I looked at some old CiviMail mailings and those URLs still work! </p>
  
  <p>I don't think this is related to <a href="https://civicrm.stackexchange.com/questions/363/missing-input-parameters-error">Missing Input Parameters Error</a></p>
  
  <p>I'm running 4.6.3. Thanks for your expert insight and helpful suggestions. </p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-06-16T17:54:09.647Z
Comments.Text: Do your old mailings use `q=123` instead of `qid=123` by chance? Are you doing any URL rewriting via .htaccess files or your CMS?
Comments.UserDisplayName: Nicholai
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-06-16T21:58:01.380Z
Comments.Text: No URL rewriting via `.htaccess`; I'm using nginx on default BOA. Both the working and non-working mailings use `qid=123`
Comments.UserDisplayName: LunkRat
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-06-16T23:51:40.450Z
Comments.Text: Ah. I run some sites on that stack as well (coincidentally, I reported the original bug to get Civi click tracking working on BOA). Given that both your examples are HTTP; is there any chance it's trying to switch to HTTPS and losing the variables? Can you try hitting the link using `http://dev.mysite.org/sites/all/modules/civicrm/extern/url.php?u=193&qid=52` to see if caching could be involved?
Comments.UserDisplayName: Nicholai
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-06-17T01:03:20.170Z
Comments.Text: Hey! You're on to something there! Yes, the site is running under a BOA forced https redirect. When I use the site's dev URL I get `Could not load the settings file at: /path/to/sites/all/modules/civicrm/../../../default/civicrm.settings.php` and when I add https to the URL, it just redirects to the root home page, but doesn't give the Missing parameters error. Hmmm ..
Comments.UserDisplayName: LunkRat
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-06-17T02:17:02.153Z
Comments.Text: Has your BOA been upgraded lately? Their changelog for May has a generic "fixed CiviCRM issues and regressions" mention. Maybe instead of the .dev. url you could try adding `noredis=1&nocache=1` to the end of the request?
Comments.UserDisplayName: Nicholai
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-06-17T19:43:08.913Z
Comments.Text: So here's where it's at: Everything works now when I manually add https:// to the URL. BUT I can't seem to get CiviMail to add https:// even though I have Force Secure URL and https:// on everything in Resource URLS and in `CIVICRM_UF_BASEURL` ... any ideas?
Comments.UserDisplayName: LunkRat
Tags: <civimail><issues>
Title: CiviMail tracked URLs give "Missing input parameters" from /extern/url.php
ThreadText: # CiviMail tracked URLs give "Missing input parameters" from /extern/url.php
  
  (Asked by: username_0 on 2015-06-16)
  
  Any mailing that I send through CiviMail converts URLs to links in the form of:
  
  `http://mysite.org/sites/all/modules/civicrm/extern/url.php?u=193&qid=52`
  
  But when I visit this URL I get a white page with "Missing input parameters" and the address is `http://mysite.org/sites/all/modules/civicrm/extern/url.php`
  
  Curiously I looked at some old CiviMail mailings and those URLs still work!
  
  I don't think this is related to [Missing Input Parameters Error](https://civicrm.stackexchange.com/questions/363/missing-input-parameters-error)
  
  I'm running 4.6.3. Thanks for your expert insight and helpful suggestions.
  
  **Tags:** civimail, issues
  
  > **Comments:**
  > **username_1**: Do your old mailings use `q=123` instead of `qid=123` by chance? Are you doing any URL rewriting via .htaccess files or your CMS?  
  > **username_0**: No URL rewriting via `.htaccess`; I'm using nginx on default BOA. Both the working and non-working mailings use `qid=123`  
  > **username_1**: Ah. I run some sites on that stack as well (coincidentally, I reported the original bug to get Civi click tracking working on BOA). Given that both your examples are HTTP; is there any chance it's trying to switch to HTTPS and losing the variables? Can you try hitting the link using `http://dev.mysite.org/sites/all/modules/civicrm/extern/url.php?u=193&qid=52` to see if caching could be involved?  
  > **username_0**: Hey! You're on to something there! Yes, the site is running under a BOA forced https redirect. When I use the site's dev URL I get `Could not load the settings file at: /path/to/sites/all/modules/civicrm/../../../default/civicrm.settings.php` and when I add https to the URL, it just redirects to the root home page, but doesn't give the Missing parameters error. Hmmm ..  
  > **username_1**: Has your BOA been upgraded lately? Their changelog for May has a generic "fixed CiviCRM issues and regressions" mention. Maybe instead of the .dev. url you could try adding `noredis=1&nocache=1` to the end of the request?  
  > **username_0**: So here's where it's at: Everything works now when I manually add https:// to the URL. BUT I can't seem to get CiviMail to add https:// even though I have Force Secure URL and https:// on everything in Resource URLS and in `CIVICRM_UF_BASEURL` ... any ideas?  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2015-06-17. Score: 3 | Accepted answer
  
  It seems your host configuration is the problem, as it forces redirection from https to http and somehow lost the parameters in the convertion
  
  Can you try to access the https version with the parameters?
  
  <https://mysite.org/sites/all/modules/civicrm/extern/url.php?u=193&qid=52>
  
  In any case, if you want to use https, be sure your configuration is set with https (CIVICRM\_UF\_BASEURL in your civicrm.settings.php), so it directly creates the right url and avoid a redirect
  
  > **Comments:**
  > **username_0**: Thank you, I changed `CIVICRM_UF_BASEURL` to https:// but the links are still being created as http:// in the CiviMail body. However, now when I manually modify the CiviMail links to https and paste them in the browser, all is working fine! So I just need to figure out how to tell CiviMail to use https:// when constructing the tracked URLs.  
  > **username_2**: check the resource url configuration page too, just to be sure it's with https too.  
  > **username_0**: double-checked that resource URLs all have https:// and even switched on "Force Secure URLs (SSL) "—still CiviMail writes them all as http://  
  > **username_1**: Does that happen for the `/extern/url.php` URLs, or for the ones that are translated? I'm looking int TrackableURL.php and it runs this: `$redirect = $config->userFrameworkResourceURL . "extern/url.php?u=$id";` It also does some caching here, so maybe Civi cache is involved.  
  > **username_0**: @username_1 and @username_2 thanks for all of your very helpful insights. I discovered that my `CIVICRM_UF_BASEURL` was being overwritten by Aegir, of course. So I prevented that (temporarily) and everything works now. I just need to figure out how to protect my customizations to `civicrm.settings.php` from being dominated by Aegir ... any ideas there (off-topic)  
  > **username_1**: That may be a question for omega8.cc, but didn't civi used to have a local.settings.php or something similar that could override?  
  
  ---
  
  