Also removed the entirely unused saveGroups function.
Now avoiding multiGet and using listFind in Profile->getGroups()
so we don't have to deal with ArrayWrapper.
NoResultException was the wrong choice in this case, because it was
not a DB_DataObject instance that performed the search, but a static
call to the Notice class.
"[...] posts _local_ users (like you) make won't get data about "repeated by"
from federated users"
This was because the ActivityObject would processShare where the shared object
has a _local_ 'actor' URI. Ostatus_profile would complain this meant that a
"Local user cannot be referenced as remote.".
So we see if the shared activity object's id (URI) is in our Notice table, so
we don't have to processActivity - and can skip ensureActivityObjectProfile.
This reverts commit 8cc4660bd9.
This seems like something Evan only did to make pump.io import notices easier,
or maybe he just wanted to get rid of the identi.ca URLs?
Added the relevant section in INSTALL about queues and daemons to get
the plugin runnig.
Made resource required, as otherwise XMPPHP will send invalid from JIDs
in it's stanzas. For example when my configuration didn't had the
resource part, outbound stanzas looked like this:
<message
from="gnusocial@example.de/"
to="flow@example.de"
type='chat'>
<body>
User "flow" on GNU Social has said that your
XMPP/Jabber/GTalk screenname belongs to them.
…
</body>
</message>
Note the '/' at the end of the from attribute, without an actual
XMPP resource. But according to RFC6122 2.1 "every allowable portion of
a JID MUST NOT be zero bytes in length". Causing a jid-malformed
response from the server.
Also, it's nice to know that debug=true will print out all sent and
received stanzas, which helped me to debug the problem.
Furthermore I add a note that if the XMPP services uses DNS SRV records,
'host' has to be configured (in cases where service host != xmpp domain).
This is the beginning of getting notice URI info via WebFinger
*XrdActionLinks is renamed *WebFingerProfileLinks, check EVENTS.txt
in WebFinger plugin for new events.
StatusNet chooses the first content element in an Atom feed, while
it should really choose the 'html' representation for its 'rendered'
and 'text' representation for the (text-only) 'content'.
GNU social will implement a better algorithm for retrieving Atom
feeds, but that is yet to be done. So to avoid having link-less posts
on remote nodes, we'll just do the old switch-a-roo.
Other Atom readers, such as Mozilla Firefox, has the reverse priority
(choosing the last of the content elements).
