Lots of the Memcached_DataObject classes stopped working when upgraded to
Managed_DataObject because they lacked schemaDef().
I have _hopefully_ made it so that all the references to the table uses
each class' schemaDef, rather than the more manual ColumnDef stuff. Not
all plugins have been tested thoroughly yet.
NOTE: This is applied with getKV calls instead of staticGet, as it was
important for PHP Strict Standards compliance to avoid calling the non-
static functions statically. (unfortunately DB and DB_DataObject still do
this within themselves...)
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.
In some brief tests, this causes no problems.
In this state however, you would need to modify DB_DataObject to have a static declaration of staticget (and probably pkeyGet). The next commit will change the staticGet overload to a unique function name (like getKV for getKeyValue), which means we can properly call the function by PHP Strict Standards.
The switch to having a function in Managed_DataObject is now being applied
to plugins which can use this as well.
There are some plugins that still use Memcached_DataObject, but these will
be taken care of later.
This merges GNU Social with current development of StatusNet. The only conflicts were some documentation, where GNU Social's versions were retained.
Conflicts:
doc-src/about
doc-src/faq
plugins/OpenID/doc-src/openid
commit 7ef19ab918cc9805abb8d01e8220ae4ed63155d7
Author: Evan Prodromou <evan@status.net>
Date: Mon Jul 9 12:53:29 2012 -0400
Show link to facebook account on profile block
If you've logged in with Facebook, show a link to that account on the profile block.
commit b56967479c009d702150791944dbd80746ee3ba1
Author: Evan Prodromou <evan@status.net>
Date: Mon Jul 9 12:28:34 2012 -0400
Add profile link from profile block to Twitter account
Add a profile link to Twitter for accounts that are linked via Twitter login.
commit 181e441fd03c6034e737f6a3dae115557aa3e1aa
Author: Evan Prodromou <evan@status.net>
Date: Mon Jul 9 11:57:56 2012 -0400
OpenID shows other account links
commit ef7357883dad9e34af2746e1c6a41ea826d7c992
Author: Evan Prodromou <evan@status.net>
Date: Mon Jul 9 11:53:12 2012 -0400
Add a profile link for OpenIDs
OpenID plugin now adds a profile link for each OpenID on the account.
commit 093d26b95bc453686d24c42f5a8f4739cb338fd2
Author: Evan Prodromou <evan@status.net>
Date: Mon Jul 9 11:15:18 2012 -0400
Better array access
commit 49d47257efdcae2101b589a1f825872bdd70667c
Author: Evan Prodromou <evan@status.net>
Date: Mon Jul 9 10:57:16 2012 -0400
Show list of other accounts in profile block
We add a group of "rel-me" links to other user accounts on the Web.
This is mostly useful for when you've used OpenID, Twitter, or
Facebook login to associate a remote account.
There's an extension to the profileblock recipe to show the links as
little icons; there's a new hook in accountprofileblock to get such
links from plugins.
There's a modification to the base theme to show the icons correctly
(I think).
