We're also now using $config['image']['jpegquality'] to determine the
quality setting for resized images.
To set Avatar max size, adjust $config['avatar']['maxsize']
The getAvatar call now throws exceptions too. Related changes applied.
Now let's move Profile->avatarUrl to the Avatar class!
Not all instances of this has been fixed, but at least the ones
in the base class of Memcached_DataObject.
Avatar fix (in classes/Profile.php) requires a pkeyGet function
in the Avatar class (or as in this tree, the parent class of
Managed_DataObject)
Memcached_DataObject now defines
* pkeyGetClass to avoid collision with Managed_DataObject pkeyGet
* getClassKV to avoid collision with Managed_DataObject getKV
I used this hacky sed-command (run it from your GNU Social root, or change the first grep's path to where it actually lies) to do a rough fix on all ::staticGet calls and rename them to ::getKV
sed -i -s -e '/DataObject::staticGet/I!s/::staticGet/::getKV/Ig' $(grep -R ::staticGet `pwd`/* | grep -v -e '^extlib' | grep -v DataObject:: |grep -v "function staticGet"|cut -d: -f1 |sort |uniq)
If you're applying this, remember to change the Managed_DataObject and Memcached_DataObject function definitions of staticGet to getKV!
This might of course take some getting used to, or modification fo StatusNet plugins, but the result is that all the static calls (to staticGet) are now properly made without breaking PHP Strict Standards. Standards are there to be followed (and they caused some very bad confusion when used with get_called_class)
Reasonably any plugin or code that tests for the definition of 'GNUSOCIAL' or similar will take this change into consideration.
We always call staticGet statically, so we define it statically. Next
step is to remove a bunch of definitions of 'staticGet' from classes
that can instead fall back to a parent class in Managed_DataObject.
The ampersand is removed as we're returning a class anyway, which does
not need a reference (and when we return false, it means nothing).
I was storing the full objects in the cache for the listGet()
function. I've changed it to store only pkeys, and use pivotGet() to
get all the corresponding values.
This also required changing pivotGet() so it can get objects with
multi-column pkeys, which complicated the whole thing quite a bit. But
it seems to work OK.
This method lets you get all the objects with a given variable key and
another set of "fixed" keys. A good example is getting all the avatars
for a notice list; the avatar size stays the same, but the IDs change.
Since it's very similar to multiGet(), I refactored that function to
use pivotGet().
And, yes, I realize these are kind of hard to follow.
like leprous boils in our code. So, I've replaced all of them with //
comments instead. It's a massive, meaningless, and potentially buggy
change -- great one for the middle of a release cycle, eh?
