New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix Malformed URL in real-time-visitors module #15233
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This issue was created in WP Matomo so was investigating and could reproduce this eg by tracking ```js _paq.push(['trackLink', 'http://mydomain.co.uk/mailto/Agent', 'download']); ``` It adds the http:// prefix twice causing the links to not work. Maybe this was a regression from when refactoring things into visitorDetails? It's probably more a workaround since the actual issue might be that it shouldn't set the url prefix when it keeps the http url, or maybe it should remove the http in the action when it sets a url prefix... This might be a more proper fix but not sure if it would regress anything ```diff --- a/app/plugins/Actions/Actions/ActionDownloadUrl.php +++ b/app/plugins/Actions/Actions/ActionDownloadUrl.php @@ -34,7 +34,7 @@ class ActionDownloadUrl extends Action { return array( // Note: we do not normalize download URL - 'idaction_url' => array($this->getActionUrl(), $this->getActionType()) + 'idaction_url' => $this->getUrlAndType() ); } ``` (it would actually use the wrong type Page URL and would need to adjust this...) I reckon we better don't change this in a minor/patch release.
tsteur
added
not-in-changelog
For issues or pull requests that should not be included in our release changelog on matomo.org.
Needs Review
PRs that need a code review
labels
Dec 3, 2019
Should we create the original issue open or create a new one for matomo 4 to fix this in a different way later? |
@diosmosis created #15246 for now but not sure we actually need to schedule it just yet. Not sure if there's any issue with setting url_prefix and protocol. So far other things seem to work nicely. |
jonasgrilleres
pushed a commit
to 1024pix/pix-analytics
that referenced
this pull request
Sep 22, 2020
This issue was created in WP Matomo so was investigating and could reproduce this eg by tracking ```js _paq.push(['trackLink', 'http://mydomain.co.uk/mailto/Agent', 'download']); ``` It adds the http:// prefix twice causing the links to not work. Maybe this was a regression from when refactoring things into visitorDetails? It's probably more a workaround since the actual issue might be that it shouldn't set the url prefix when it keeps the http url, or maybe it should remove the http in the action when it sets a url prefix... This might be a more proper fix but not sure if it would regress anything ```diff --- a/app/plugins/Actions/Actions/ActionDownloadUrl.php +++ b/app/plugins/Actions/Actions/ActionDownloadUrl.php @@ -34,7 +34,7 @@ class ActionDownloadUrl extends Action { return array( // Note: we do not normalize download URL - 'idaction_url' => array($this->getActionUrl(), $this->getActionType()) + 'idaction_url' => $this->getUrlAndType() ); } ``` (it would actually use the wrong type Page URL and would need to adjust this...) I reckon we better don't change this in a minor/patch release.
jbuget
pushed a commit
to 1024pix/pix-analytics
that referenced
this pull request
Sep 26, 2020
This issue was created in WP Matomo so was investigating and could reproduce this eg by tracking ```js _paq.push(['trackLink', 'http://mydomain.co.uk/mailto/Agent', 'download']); ``` It adds the http:// prefix twice causing the links to not work. Maybe this was a regression from when refactoring things into visitorDetails? It's probably more a workaround since the actual issue might be that it shouldn't set the url prefix when it keeps the http url, or maybe it should remove the http in the action when it sets a url prefix... This might be a more proper fix but not sure if it would regress anything ```diff --- a/app/plugins/Actions/Actions/ActionDownloadUrl.php +++ b/app/plugins/Actions/Actions/ActionDownloadUrl.php @@ -34,7 +34,7 @@ class ActionDownloadUrl extends Action { return array( // Note: we do not normalize download URL - 'idaction_url' => array($this->getActionUrl(), $this->getActionType()) + 'idaction_url' => $this->getUrlAndType() ); } ``` (it would actually use the wrong type Page URL and would need to adjust this...) I reckon we better don't change this in a minor/patch release.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Needs Review
PRs that need a code review
not-in-changelog
For issues or pull requests that should not be included in our release changelog on matomo.org.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This issue was created in WP Matomo so was investigating and could reproduce this eg by tracking
It adds the http:// prefix twice causing the links to not work. Maybe this was a regression from when refactoring things into visitorDetails? It's probably more a workaround since the actual issue might be that it shouldn't set the url prefix when it keeps the http url, or maybe it should remove the http in the action when it sets a url prefix...
This might be a more proper fix but not sure if it would regress anything
(it would actually use the wrong type Page URL and would need to adjust this...) I reckon we better don't change this in a minor/patch release.
fix #15232