Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
|
|
|
|
doesn't like the XHR response with XHTML DTD. New notices without the
file attachment work fine.
The rendered content (the anchor for the file attachment link) doesn't
appear to be the issue.
To fix this problem, I removed the XHTML DTD line from newnotice's XHR
response. This is unnecessary for text/xml outputs that's intended
for XHR responses any way. It just happens to fix an IE issue.
Still a mystery to me as to why it is particular to notices with file
attachments.
|
|
|
|
|
|
|
|
|
|
|
|
Updated our API to match.
|
|
Conflicts:
lib/util.php
tests/URLDetectionTest.php
|
|
|
|
|
|
This reverts commit d46f2ee350b9bf2c70371f7bcd2f2793e7ed8110.
|
|
tables to both upgrade scripts"
This reverts commit e9edb803bc66028204defcfa659cccbf23da97c6.
|
|
This reverts commit 6704ddddf227865de43c1fdd846b68f76f723fe6.
|
|
|
|
|
|
|
|
|
|
of empty notice prefix text in facebook settings.
Filed bug upstream at http://bugs.developers.facebook.com/show_bug.cgi?id=7110
Per documentation, saving a pref value of "" or "0" will delete the pref key:
http://wiki.developers.facebook.com/index.php/Data.setUserPreference
which used to do what we want... Now Facebook throws back an error
"Parameter value is required" when we do this. Workaround appends a
space to empty string or "0" at save time, then trims the string when
we load it.
The input string was already trimmed at pref save time, so this won't
alter any user-visible behavior.
Thanks to ^demon in #mediawiki for pointing out the behavior regression
after testing the identi.ca Facebook app!
|
|
of empty notice prefix text in facebook settings.
Filed bug upstream at http://bugs.developers.facebook.com/show_bug.cgi?id=7110
Per documentation, saving a pref value of "" or "0" will delete the pref key:
http://wiki.developers.facebook.com/index.php/Data.setUserPreference
which used to do what we want... Now Facebook throws back an error
"Parameter value is required" when we do this. Workaround appends a
space to empty string or "0" at save time, then trims the string when
we load it.
The input string was already trimmed at pref save time, so this won't
alter any user-visible behavior.
Thanks to ^demon in #mediawiki for pointing out the behavior regression
after testing the identi.ca Facebook app!
|
|
Fixes file magic checks on 64-bit systems.
http://bazaar.launchpad.net/~danilo/php-gettext/trunk/revision/17
http://bazaar.launchpad.net/~danilo/php-gettext/trunk/revision/18
http://bazaar.launchpad.net/~danilo/php-gettext/trunk/revision/19
|
|
Fixes file magic checks on 64-bit systems.
http://bazaar.launchpad.net/~danilo/php-gettext/trunk/revision/17
http://bazaar.launchpad.net/~danilo/php-gettext/trunk/revision/18
http://bazaar.launchpad.net/~danilo/php-gettext/trunk/revision/19
|
|
http://status.net/trac/ticket/1411
|
|
|
|
rebuild it:
* el_GR - Greek localization updates
* he_IL - one additional Hebrew message, removed two fuzzies that gettext doesn't like
* is_IS - added new Icelandic localization file from Pootle
* nb_NO - Norwegian Bokmål updates
* zh_CN - a few Chinese message updates
|
|
Previously, the attachment URL would simply be dropped when shortening returned false instead of a short URL... the attachment was present if you clicked through to notice details but didn't appear in the timeline, making it nigh-impossible to see the attachment.
|
|
fixup_conversations.php fixes
|
|
|
|
Previously, the attachment URL would simply be dropped when shortening returned false instead of a short URL... the attachment was present if you clicked through to notice details but didn't appear in the timeline, making it nigh-impossible to see the attachment.
|
|
0.8.x
|
|
|
|
into 0.8.x
|
|
git://gitorious.org/statusnet/mainline into 0.8.x
|
|
git://gitorious.org/statusnet/mainline into 0.8.x
|
|
git://gitorious.org/statusnet/mainline into 0.8.x
|
|
|
|
|
|
|
|
private and user is not logged in
|
|
|
|
|
|
|
|
|
|
This reverts commit aeca8807dbce951beccbc3fb0e5a4ae5600e5e5f.
We specifically DON'T have closing tags so we don't get errors with
whitespace after the closing tag.
I realize this is less of an issue with scripts, but we should still
not use closing tags.
|
|
|
|
|