The tartget page's URL was not being URL-escaped when passed as a parameter into the query string. Result was that any URL-encoded bytes in the link would be unescaped and interpreted as raw UTF-8 when our bookmarklet post target page reads its parameters; this would break 8-bit high characters (eg a Latin-1 %FC turning into a corrupt UTF-8 byte) or reserved chars that needed to be kept escaped (eg a %3F turning into literal ?)
Unfortunately as this was a bug in the original bookmarklet's JS code, this'll only fix it for people who grab a fresh copy of the bookmarklet.
The tartget page's URL was not being URL-escaped when passed as a parameter into the query string. Result was that any URL-encoded bytes in the link would be unescaped and interpreted as raw UTF-8 when our bookmarklet post target page reads its parameters; this would break 8-bit high characters (eg a Latin-1 %FC turning into a corrupt UTF-8 byte) or reserved chars that needed to be kept escaped (eg a %3F turning into literal ?)
Unfortunately as this was a bug in the original bookmarklet's JS code, this'll only fix it for people who grab a fresh copy of the bookmarklet.
Should help with dupes that come in when inbox distrib jobs die and get restarted, etc.
Conflicts:
classes/Inbox.php
Looks like this was implemented on master recently and not copied up to testing. Merging to my version on testing as I've added some doc comments and extracted a couple functions for future ease of use.
to (profile_id, id) instead of (profile_id, created, id).
It's been falling back to PRIMARY instead, which is really
very inefficient for a profile that hasn't posted in a few
months. Even though forcing the index will cause a filesort,
it's usually going to be better. Even for large profiles it
seems much faster than the badly-indexed query.
to (profile_id, id) instead of (profile_id, created, id).
It's been falling back to PRIMARY instead, which is really
very inefficient for a profile that hasn't posted in a few
months. Even though forcing the index will cause a filesort,
it's usually going to be better. Even for large profiles it
seems much faster than the badly-indexed query.
Basic splitting/validation code submitted via http://status.net/wiki/XMPP/JID_validation -- Copyright 2009 Patrick Georgi <patrick@georgi-clan.de> Licensed under ISC-L, which is compatible with everything else that keeps the copyright notice intact.
Added PEAR Net_IDNA package to extlib to handle IDN normalization (also used by Validate's email verifier if present).
* added test suite, supplemented my own test cases with JID validation and normalization test cases from libpurple
* follows XMPP rules for validation of name part
* fixes for normalization with non-ASCII names
* will do domain checks if $config['email']['check_domain'] is on, checking for an XMPP-server SRV record or any lookup. (We don't actually need to ping those direct though.)
* some more obscure stringprep validation rules aren't quite followed yet, but we err on the side of permissiveness.
* we still don't actually let you save your address with a resource on it, as we strip resources when looking up users who've sent us presence or message updates. I would recommend saving the outgoing resource as a separate field if/when we add that..?
* respect count instead of listing all groups
* respect page parameter
* don't spew notice on undefined $id
* don't spew notice on undefined $group->homepage_url (dropped the element since there's nothing to go in it)
* respect count instead of listing all groups
* respect page parameter
* don't spew notice on undefined $id
* don't spew notice on undefined $group->homepage_url (dropped the element since there's nothing to go in it)
I swapped the settings from negative to positive ($config['queue']['stomp_transactions'] = false rather than $config['queue']['stomp_no_transactions'] = true), gave them defaults (both on for best ActiveMQ experience), and added notes to the README about configuring them.
