| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Replaced by MediaWiki Translate extension script http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/Translate/scripts/genStatusNetPluginsConfig.php?view=markup
|
|
|
|
2d4e0693c88bb8cad47f917db3ac5ecfacf28619)
Changes in 2d4e0693c88bb8cad47f917db3ac5ecfacf28619 changed Ostatus_profile::filterReplies() (which sorts out the local, remote, and group recipients on incoming remote messages) from checking for remote profiles with a safe call to Ostatus_profile::staticGet() to calls through Ostatus_profile::ensureProfileURL() and Ostatus_profile::ensureWebfinger(), which throw exceptions and thus abort processing.
Since this was done before checking for local groups, the filter would fail when the ensure* functions determined it was looking at a local group and rightfully refused to create a remote group profile for it.
Changing the calls to the ensure* functions was done so we can record remote reply recipients for future reply-to-reply processing (the staticGet() call was a cheaper way to do a lookup when we knew we only actually had to process groups that somebody signed up to); most important fix is simply to actually check for the exception! :)
Here I'm changing the order of processing so we do the local group lookup first -- where it's nice and safe -- and then when we do the remote checks, we'll go ahead and gracefully skip that entry if the full remote lookup fails, so we'll still process any following recipients.
|
|
sources lists.
To add just these to an existing table:
INSERT INTO notice_source
(code, name, url, created)
VALUES
('StatusNet Mobile', 'StatusNet Mobile', 'http://status.net/mobile', now()),
('StatusNet iPhone', 'iPhone', 'http://status.net/iphone', now()),
('StatusNet Android', 'Android', 'http://status.net/android', now()),
('StatusNet Blackberry', 'Blackberry', 'http://status.net/blackberry', now());
|
|
command names must not be translated
|
|
Reapply of revised b27882c9166191de4aaea298ba1b1a524cfe9ac7 that was reverted by Brion Vibber in 2d4c0f9a47f6534c578a37abe79670cec699caae.
|
|
data, etc added to them at leisure.
|
|
doesn't work and spews error messages
This reverts commit b27882c9166191de4aaea298ba1b1a524cfe9ac7.
|
|
|
|
|
|
|
|
* superfluous whitespace removed
|
|
* superfluous whitespace removed
|
|
* remove superfluous whitespace
|
|
* remove superfluous whitespace
|
|
by spaces.
|
|
|
|
|
|
|
|
|
|
exception messages.
|
|
|
|
|
|
* update translator documentation.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* fixes several po -> mo issues in 'cs' and 'ka' also reported at https://bugzilla.wikimedia.org/show_bug.cgi?id=25120
* removed some unneeded leading spaces in 'cs'
|
|
|
|
|
|
|
|
|
|
|
|
translatewiki.net)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
permissions, causing failure to see images if background queues are different user from web server.
The original-size file is now forced to 0644 (all-readable), which should help. Not sure this is 100% ideal, but it's better than 0600!
(The other sizes were being created in other code and had sane read perms already.)
Watch out for similar issues in Twitter bridge etc; avatar import code should get cleaned up and consolidated.
|
|
The Net::OpenID::Server perl module that LJ uses appears to be very picky about input, and rejects most request types unless the data comes in as GET parameters (apparently following OpenID 1.1 rules, rather than OpenID 2.0 rules which permit any request to be POSTed but requires that if so, the data must all be in the POST body).
Apparently something got updated on LJ at some point that's either added that behavior or (more likely) added the OpenID 2.0 namespace info to discovery, which tells the Janrain-based OpenID libraries that they should go ahead and do POST requests instead of redirects to GET requests... thus breaking everything. ;)
GET should be just fine for both 1.1 and 2.0 though, and also saves having to sit through that lame autosubmit page.
Switched the authentication submission from checking whether it should redirect to GET or do a form POST, to simply always doing the redirect to GET.
Tested against providers:
* LiveJournal
* Google
* LaunchPad
* identi.ca
|
|
|
|
The Net::OpenID::Server perl module that LJ uses appears to be very picky about input, and rejects most request types unless the data comes in as GET parameters (apparently following OpenID 1.1 rules, rather than OpenID 2.0 rules which permit any request to be POSTed but requires that if so, the data must all be in the POST body).
Apparently something got updated on LJ at some point that's either added that behavior or (more likely) added the OpenID 2.0 namespace info to discovery, which tells the Janrain-based OpenID libraries that they should go ahead and do POST requests instead of redirects to GET requests... thus breaking everything. ;)
GET should be just fine for both 1.1 and 2.0 though, and also saves having to sit through that lame autosubmit page.
Switched the authentication submission from checking whether it should redirect to GET or do a form POST, to simply always doing the redirect to GET.
Tested against providers:
* LiveJournal
* Google
* LaunchPad
* identi.ca
|
|
|
|
|
