* Subscription::start was sometimes passing users instead of profiles to hooks, which broke OStatus subscription notifications; now normalizing to profiles for processing.
* H-card parsing would trigger a lot of PHP warnings and notices in hKit. Now suppressing warnings and notices for the duration of the call to keep them out of output when display_errors is on.
* H-card parsing would trigger a PHP fatal error if the source page was not well-formed XML and Tidy was not present on the system. Switched normalization to use the PHP DOM module which is always present, as we have no need for Tidy's extra features here.
* Trying to fetch avatars from Google profiles failed and triggered a PHP warning due to the relative URL not being resolved during h-card parsing. Now passing profile page URL into hKit by sneaking a <base> tag in while we normalize the HTML source.
* Profile pages without a "Link" header could trigger PHP notices due to a bad NULL -> array(NULL) conversion in LinkHeader::getLink(). Now checking that there was a return value before converting single return value into array.
Base problem is that our caching-on-insert interferes with relying on column default values; the cached object is missing those fields, so they appear to be empty (null) when the object is retrieved from cache.
Now explicitly setting them when inserting subscriptions, and cleaned up some code that had alternate code paths.
May also have made auto-subscription work for remote OStatus subscribers, but can't test until magic sigs are working again.
We were double-unescaping for <content type="html">, turning <b> escaped chars into literal tags (which then may get removed entirely by the HTML scrubber).
For instance this was throwing an exception for DB_DataObject::staticGet when there's no match... definitely not what we want when all our code expects to get a nice null.
Example of this causing trouble: http://gitorious.org/statusnet/mainline/merge_requests/131
Revert "Don't attempt to retrieve the current user from the DB while processing a DB error"
This reverts commit 68347691b0.
Revert "Use PHP exceptions for PEAR error handling."
This reverts commit d8212977ce.
For instance this was throwing an exception for DB_DataObject::staticGet when there's no match... definitely not what we want when all our code expects to get a nice null.
Example of this causing trouble: http://gitorious.org/statusnet/mainline/merge_requests/131
Revert "Don't attempt to retrieve the current user from the DB while processing a DB error"
This reverts commit 68347691b0.
Revert "Use PHP exceptions for PEAR error handling."
This reverts commit d8212977ce.
With the FirePHP plugin enabled, I get these warnings in the output
page. This is because the StartLog handler inadvertly modifies the
original (number) priority with the corresponding (string) FirePHP
priority.
Flow:
1. Browser (IE7) is redirected to the login page.
2. Browser reads the page, sees OpenSearch descriptions, tries to
download them. Each request gets recorded by SN as the page the user
should be redirected to after logging in (returnto).
3. User logs in, then gets redirected to the returnto action, which is
an OpenSearch description.
The OpenSearch descriptions aren't sensitive so making them public in a
private site should be okay.
(I recall fixing this in 0.8.x... :-( )
