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
Emoji in titles or URLs cause tracking to fail #7766
Comments
Hi @ethitter |
Shouldn't we do a 'quickfix' so that those urls will still be tracked. Maybe with the emoji cut off? |
Also relevant is Andrew Nacin's discussion of the security issues around these changes: https://www.youtube.com/watch?v=yQaRUEwEKxE. Simply updating the table encodings may not be sufficient; it wasn't for WordPress. I like the idea of a quickfix to just drop the emoji, but that'd likely break the URLs being tracked as emoji would need to be stripped from there too. |
@sgiehl makes sense, it would be better to track partial incorrect data rather than no data at all. Maybe instead of removing emojis, we could replace with |
FYI: Piwik now tracks URLs with emojis but emoji (and all utf8 4-byte chars) will be replaced by � character. it was done in #8765 |
This is fixed. Created: #8790 Tracking API: track Emoji correctly in page URLs and others |
Still having this issue with 3.4.0 on PHP 7.2 [09-May-2018 14:11:33 UTC] Error in Matomo: Your Matomo version 3.4.0 is up to date. |
@gmariani as it is not supposed to trigger an error, could you please paste in a new issue (this one is already closed), the |
WordPress 4.2 was released this week, and it includes full support for emoji, including in post titles and URLs. To take advantage of that, I published a post that used the 💥 emoji (https://s.w.org/images/core/emoji/72x72/1f4a5.png, in case it get's stripped out) in the title and URL, however Piwik failed to track any views of the post because
piwik.php
is returning a400 - bad request
status code. I confirmed against two other tracking systems that there were views to the post that should've been captured by Piwik.Is this a problem with the DB encoding (utf8 vs utf8mb4) or an issue in the PHP handling of the title and URL inputs when they include extended UTF-8 characters?
The text was updated successfully, but these errors were encountered: