@wysija @khuss
Unfortunately, the patch is not the solution to the mentioned issue.
Why does the patch seem to work??
The comment in line 32, clearly states what it should do: remove within a string anything that starts with ?utm or /?utm.
The line 32 in the patch is:
$external_url = preg_replace('!/?\?utm.*!', ''. $external_url);
which doesn’t do that, but instead turns the variable $external_url to the empty string. This sets – as a side-effect – the first part of the test (IF at line 36) always to TRUE and the lines 38 and 39 are then executed, leading to the redirection to the (correct) links of the site pages, corresponding to “see newsletter in browser”, “unsubscribe” or “manage profile”.
Result: we think that it works correctly …
The correct line 32 is (comma instead of period):
$external_url = preg_replace('!/?\?utm.*!', '', $external_url);;
which turns the variable $external_url to a ‘neat’ URL without possible suffixes starting with ?utm or /?utm.
Why doesn’t the version of 2.6.18 release with the correct line 32 work for some people?
I don’t know for sure why the first part of the test (IF at line 36) is there. Can anyone tell me why?
What I know is that (in my case) this first part of the test is always FALSE. Which means that the second part of the test (IF at line 37) has to be TRUE. Otherwise lines 38 and 39 aren’t executed and the 404-message is displayed (lines 41, 42, 43).
Unfortunately for me (and some others), the second part of the test is also always FALSE.
Why does it work for some people?
Because for some people the second part of the test (IF at line 36) is TRUE.
This second part checks if the SITE_URL (meaning: something like: http://www.mysite.com) is the start of the string representing URL of redirection, i.e. the link to “see newsletter in browser”, “unsubscribe” or “manage profile”.
And there can be a difference in the settings of our sites.
In WordPress Settings (General settings), you can fill in a value for your home site (http://www.mysite.com) and a value for where you want your WordPress core files (e.g. http://www.mysite.com/wp).
See: https://codex.wordpress.org/Changing_The_Site_URL
The “Site Address (URL)” setting is the address you want people to type in their browser to reach your WordPress blog <– get_home_url()
get_home_url() addresses http://www.mysite.com (example)
The “WordPress Address (URL)” setting is the address where your WordPress core files reside <– get_site_url()
get_site_url() addresses http://www.mysite.com/wp (example)
*** THIS IS CONFUSING ***
People having this situation (I’m one of them), will have issues with the new release. People having both URLs set to the same value will have no problems with the new release.
The following lines are working fine for me:
=== replaced in line 33 ‘get_site_url()’ by ‘get_home_url()’ ===
$url = $this->encode_url($WJ_Stats->subscriber_clicked()); // line 30
$external_url = htmlentities($WJ_Stats->subscriber_clicked()); // line 31 escape HTML characters (that's how URLs are saved in the DB)
$external_url = preg_replace('!/?\?utm.*!', '', $external_url); // line 32 remove anything that starts with ?utm or /?utm
$internal_url = htmlentities(get_home_url()); // line 33
$model_email = WYSIJA::get('email', 'model'); // line 34
$email_object = $model_email->getOne(false,array('email_id' => $_REQUEST['email_id'])); // line 35
if (preg_match('/'. preg_quote($external_url, '/') .'/', $email_object['body']) || // line 36
preg_match('/^'. preg_quote($internal_url, '/') .'/', $url)) { // line 37
do_action('mpoet_click_stats', $WJ_Stats); // line 38
$this->redirect($url); // line 39
) // line 40
header('HTTP/1.0 404 Not Found'); // line 41
echo '<h1>404 Not Found</h1>'; // line 42
echo 'The page that you have requested could not be found.'; // line 43
