Advantages:
* Increases security by preventing direct access to file/
* We are careful and have a defined('GNUSOCIAL') || die() to prevent
direct access to GS files, but we may miss one or a vendor/extlib may
not be as careful
* Improves directory structure - It's more natural to physically
separate what is public from what are GNU social resources
This commit also fixes the translation in /plugins/OpenID/actions/finishopenidlogin.php#L203-L204 (s/Syncronize/Synchronize)
Sync is a bad technical jargon and we should use Synch instead.
Synch is already used in other parts of GNU social as seen in plugins/TwitterBridge/classes/Twitter_synch_status.php
UI:
- "Delete" area is now "Actions" area
- Updated themes to better reflect the changes
Routes:
- index.php?action=finishsyncopenid => finishsyncopenid
Translations:
- Updated OpenID translation files
- Updated OpenID POT file
Versioning:
- Bump OpenID minor version
- Bump GS patch version
Why would have labeling the Synchronize button of Sync been of bad taste? - answered by XRevan86:
In "synchronise" "ch" is a digraph meaning /k/ (actually /x/ turned into /k/ in English but whatever).
So… not separate letters.
It's like "ph" in "alphabet", or "sh" in "sheep", or "ch" in "chop" -- "ch" can mean a whole variety of sounds.
Fixes handle()-related strict warnings such as "Strict Standards:
Declaration of AdminPanelAction::prepare() should be compatible with
Action::prepare(array $args = Array)
Ref. #190
Fixes handle()-related strict warnings such as "Strict Standards:
Declaration of AdminPanelAction::handle() should be compatible with
Action::handle()"
Ref. #190
Readme plugins
* Adds several plugin READMEs
They are pretty basic, but it's a start.
* Changes status.net/wiki URLs to git.gnu.io
The status.net wiki is dead.
See merge request !103
Lots of these changes mean that we're requiring certain values to
either by typed properly or return the expected value. If it doesn't
there should be a fatal exception thrown which we can followup in the
logs and won't go silently suppressed.
A bug which we fix here and there by sending the string '0' instead.
We will be able to remove these hacks ("booleanintstring") when the
next release of DB_DataObject comes as I patched it for them.
This is the beginning of getting notice URI info via WebFinger
*XrdActionLinks is renamed *WebFingerProfileLinks, check EVENTS.txt
in WebFinger plugin for new events.
Nickname verifications on registration and updates for profiles (not yet
groups) have been improved.
Minor bugs in RegisterAction were also fixed, where multiple forms would
be outputed because the function did not return after showForm(). This
will be solved more permanently with throwing exceptions in the future.
New plugins:
* LRDD
LRDD implements client-side RFC6415 and RFC7033 resource descriptor
discovery procedures. I.e. LRDD, host-meta and WebFinger stuff.
OStatus and OpenID now depend on the LRDD plugin (XML_XRD).
* WebFinger
This plugin implements the server-side of RFC6415 and RFC7033. Note:
WebFinger technically doesn't handle XRD, but we serve both that and
JRD (JSON Resource Descriptor), depending on Accept header and one
ugly hack to check for old StatusNet installations.
WebFinger depends on LRDD.
We might make this even prettier by using Net_WebFinger, but it is not
currently RFC7033 compliant (no /.well-known/webfinger resource GETs).
Disabling the WebFinger plugin would effectively render your site non-
federated (which might be desired on a private site).
Disabling the LRDD plugin would make your site unable to do modern web
URI lookups (making life just a little bit harder).
lib/plugin.php now has a parent onAutoload function that finds most common
files that are used in plugins (actions, dataobjects, forms, libs etc.) if
they are put in the standardised directories ('actions', 'classes', 'forms',
'lib' and perhaps some others in the future).
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.
