Removed the free calls (unneeded since destructors now work), and added an error check w/ logging & an exception for future attempts to forward calls to nonexistent object.
Note that the current version of the infinitescroll jquery plugin fixes this, but I'm not updating to it because the code's been altered from the upstream version, apparently to stop it from actually working as infinite scroll. WTF? :)
Note that these tests won't pass on master branch yet as the join/leave don't work, and there's a bug in Activity parsing which prevents interop between new feeds and old remote subscribers (both fixed in this branch).
Given a notice in the local system, we package it up as an Atom entry and MagicSig it up.
We run the magicenv verification on it locally to make sure our own functions can decode it.
Optionally with --verify we can send to Tuomas Koski's verification test service (not sure if this is working 100%)
If given --slap= with a target Salmon endpoint, we'll sent it on and see if it liked it. (Note that StatusNet will reject if there's not a relevant mention, but will report acceptance for dupes so you can use a message that's already been delivered as a test.)
It seems to have actually been saving correctly, but the update of the colors on the form success page wasn't working properly.
When a design object is pulled out of the database, the numeric fields are read in as strings, so black comes back as "0".
But, when we populate the new object and then stick it live, we've populated it with actual integers; with memcache on these might live for a while in the cache...
The fallback code in Design::toWebColor() did a check ($color == null) which would be false for the string "0", but counts as true for the *integer* 0.
Thus, the display code would initially interpret the correctly-saved black color as "use default".
Changing the check to === against null and "" empty string avoids the false positive on integers, and lets us see our nice black text immediately after save.
We can make a lot of HTTP requests from the server side. This change
adds some configuration options for using an HTTP proxy, which can
cache hits from multiple sites (good for status.net-like services, for example).
We were passing DOM nodes directly into the queues for the final bookmark import stage; unfortunately these don't actually survive serialization.
Moved the extraction of properties from the HTML up to the first-stage handler, so now we don't have to worry about moving DOM nodes from one handler to the next. Instead passing an associative array of properties, which is fed into the Bookmark::saveNew by the per-bookmark handler.
