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.
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?
This is the beginning of getting notice URI info via WebFinger
*XrdActionLinks is renamed *WebFingerProfileLinks, check EVENTS.txt
in WebFinger plugin for new events.
_flow_ reported on IRC that install.php had stopped working. This was
because default plugins had been put into two separate lists, and the
list with AuthCrypt was never loaded when performing an installation.
Core plugins cannot be disabled.
I also removed the Memcache autodetection thing since it should be
solved in a more elegant manner.
...no need to make a separate call to Local_group's setNickname all the time,
or a bunch of redundant code for the Profile table.
Next up is User->update()...
I implemented changes from quitter.se's new API that their front-end qvitter
uses, https://github.com/hannesmannerheim/qvitter/blob/master/api-changes-1.1.1/CHANGES
However I left out the URL shortening commens, since I believe whatever behaviour
they experienced that caused them to implement this was a bug (or many) and should
be fixed in their proper areas and that shortening should not be entirely left
out in API calls.
Profile_prefs aims to consolidate all the profile preferences into a
single table. Otherwise we end up with a bajillion *_prefs classes, like
User_urlshortener_prefs, or new fields in existing User/Profile classes,
like 'urlshorteningservice', 'homepage', 'phone_number', 'pet_name' etc.
Eventually we should migrate as many user-settable preferences as we can
into this system.
The data in Profile_prefs is organized by:
* profile_id Identify the current Profile.
* namespace Which plugin/section the preference is for.
* topic Preference name (like 'homepage')
* data Preference data (like 'https://gnu.org/')
The names 'topic' and 'data' are because 'key' and 'value' may be rather
ambigous when dealing with our DB_DataObject classes etc.
