spl_autoload_register now calls the GNUsocial_class_autoload function
instead of us replacing the magic __autoload($cls). This means we can
queue up other autoload functions, such as the one now used for extlib
functions which exist directly in the 'extlib/' folder or have proper
namespacing (which our new Markdown class does).
At the same time we remove the "filecommand" setting, since we will
likely not have use of it thanks to PECL fileinfo.
Also the "supported" list for attachment mime types has changed
format, so we can keep track of at least some known file extensions.
Because if you have your own local/closed community, likely you
don't want random newcomers that drop in, spam and leave dead
accounts.
The Admin can of course always override this by setting the config
"inviteonly" to false either in the config.php or on the website.
Added the following FIXME:
How should a Twitter user get their Inbox filled with foreign tweets?
Every imported Twitter user has a profile in the Profile table, so we
could setup a Subscription entry for each of those, meaning they get
collected in the InboxNoticeStream... But this would mean a lot of
unnecessary entries and listings that generally just point to the
locked down Twitter service.
Let's figure out a good relation so we can connect any profile to any
imported foreign notice, so it shows up in the "all" feed.
Also cleaned up and made typing stricter for the stream, so only
profiles can be submitted. This reasonably also means we can create
"inbox" or "all" streams for foreign profiles as well using the same
stream handler (but of course only for messages we already know about).
To avoid looking up posts for a long time in a large notice database,
the lookback period for the inbox is no longer than the profile creation
date. (this matches the behaviour of Inbox)
Inbox class can probably be removed now.
Many of the microapps are pretty javascript dependant, but at least
we should allow users to get to the new notice field without allowing
javascript to run in the browser. :)
My reasoning: Minifying makes third party review harder. A visitor on
a GNU social site should have no problem reading, understanding and
modifying javascripts for their own liking. A minified script is much
more difficult to use, reuse, modify and share.
Free software is not minified.
Generally the Cron plugin will run if there's still execution time for
1 second since starting the Action processing. If you want to change
this (such as disabling, 0 seconds, or maybe running bigger chunks,
for like 4 seconds) you can do this, where 'n' is time in seconds.
addPlugin('Cron', array('secs_per_action', n));
Add 'rel_to_pageload'=>false to the array if you want to run the queue
for a certain amount of seconds _despite_ maybe already having run that
long in the previous parts of Action processing.
Perhaps you want to run the cron script remotely, using a machine capable
of background processing (or locally, to avoid running daemon processes),
simply do an HTTP GET request to the route /main/cron of your GNU social.
Setting secs_per_action to 0 in the plugin config will imply that you run
all your queue handling by calling /main/cron (which runs as long as it can).
/main/cron will output "0" if it has finished processing, "1" if it should
be called again to complete processing (because it ran out of time due to
PHP's max_execution_time INI setting).
The Cron plugin also runs events as close to hourly, daily and weekly
as you get, based on the opportunistic method of running whenever a user
visits the site. This means of course that the cron events should be as
fast as possible, not only to avoid delaying page load for users but
also to minimize the risk of running into PHP's max_execution_time. One
suggestion is to only use the events to add new queue items for later processing.
These events are called CronHourly, CronDaily, CronWeekly - however there
is no guarantee that all events will execute, so some kind of failsafe,
transaction-ish method must be implemented in the future.
To make the StatusNet::addPlugin() accept only arrays,
the lib/default.php had to be changed because all plugins
had 'null' as default value instead of an array.
If you're using XMPP by setting $config['xmpp'][*] then you should do:
addPlugin('Xmpp', $config['xmpp']);
because setting it directly in $config[''] won't do anything.
Also, default resource for XMPP is now 'gnusocial'. If you want something
more random, set it in your addPlugin config array.
Also removed the entirely unused saveGroups function.
Now avoiding multiGet and using listFind in Profile->getGroups()
so we don't have to deal with ArrayWrapper.
StatusNet chooses the first content element in an Atom feed, while
it should really choose the 'html' representation for its 'rendered'
and 'text' representation for the (text-only) 'content'.
GNU social will implement a better algorithm for retrieving Atom
feeds, but that is yet to be done. So to avoid having link-less posts
on remote nodes, we'll just do the old switch-a-roo.
Other Atom readers, such as Mozilla Firefox, has the reverse priority
(choosing the last of the content elements).
_flow_ reported on IRC that install.php had stopped working. This was
because default plugins had been put into two separate lists, and the
list with AuthCrypt was never loaded when performing an installation.
Core plugins cannot be disabled.
I also removed the Memcache autodetection thing since it should be
solved in a more elegant manner.
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.
clientError and serverError exit after they're done so no need for
break or return. Also, $this->format is default.
We also got rid of the incredibly verbose version of $this->isPost()
which was spread all over the place.
Not all of this cleaning up is done yet.
I implemented changes from quitter.se's new API that their front-end qvitter
uses, https://github.com/hannesmannerheim/qvitter/blob/master/api-changes-1.1.1/CHANGES
However I left out the URL shortening commens, since I believe whatever behaviour
they experienced that caused them to implement this was a bug (or many) and should
be fixed in their proper areas and that shortening should not be entirely left
out in API calls.
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!
* getOriginal added to Avatar class
This is a static function that retrieves the original avatar in a leaner
way than Profile->getOriginalAvatar() did (see below).
This will throw an Exception if there was none to be found.
* getProfileAvatars added to Avatar class
This gets all Avatars from a profile and returns them in an array.
* newSize added to Avatar class
This will scale an original avatar or throw an Exception (originally from
Avatar::getOriginal) if one wasn't found.
* deleteFromProfile added to Avatar class
Deletes all avatars for a Profile. This makes the code much smarter when
removing all avatars from a user.
Previously only specific, hardcoded (through constants) sizes would be
deleted. If you ever changed lib/framework.php then many oddsized avatars
would remain with the old method.
* Migrated Profile class to new Avatar::getOriginal support
Profile class now uses Avatar::getOriginal through its own
$this->getOriginalAvatar and thus remains backwards compatible.
* Updating stock GNU Social to use Avatar::getOriginal
All places where core StatusNet code used the
$profile->getOriginalAvatar, it will now useAvatar::getOriginal with
proper error handling.
* Updated Profile class to use Avatar::newSize
When doing setOriginal, the scaling will be done with the new method
introduced in this merge.
This also edits the _fillAvatar function to avoid adding NULL values to
the array (which causes errors when attempting to access array entries as
objects). See issue #3478 at http://status.net/open-source/issues/3478
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).
maxContent==0 implies that a notice text can be infinitely long, but
this value was directly transferred to maxNoticeLength, where 0 was
tested if it was longer than the notice length - which of course always
was false.
This commit fixes the problem for infinite length notices that always
got shortened.
I had a problem with PHP5.5 that caused ajax responses to be empty. This
fixes it, as the problem was related to pretty inconsistent calling to
headers, XMLWriter::startDocument etc. etc.
Includes some minor changes to other things as well, such as the session
token input element now having the same 'name' attribute as everyone else.
(it still retains a 'token-'+noticeid 'id' attribute for clientside JS)
It seems we don't need all the development files. Though it feels a bit
evil not to keep them. Then again we didn't have the whole dev-tree there.
Really we should maybe use git submodules for this?
I also made sure that if we don't have minify enabled, a non-minified
version of jquery-ui is loaded, as minification is the most evil of all.
Bad as hell to debug, and anyone visiting the site should be allowed to
view all scripts that are run in an overseeable manner.
getUser calls are much more strict, and one place where this was found was
in the (un)subscribe start/end event handlers, which resulted in making the
Subscription class a bit stricter, regarding ::start and ::cancel at least.
Several minor fixes in many files were made due to this.
This does NOT touch the Foreign_link function, which should also have a more
strict getUser call. That is a future project.
Action extended classes now can set 'needLogin' as a protected property,
which is defaulted to 'false'. However, FormAction defaults this to 'true'
because most of the form actions will require a current login to be valid.
NewgroupAction, NewmessageAction, NewnoticeAction are all affected by this
commit and in the future we will migrate each potential formaction to the
proper class parent tree. :)
Had to change Action function 'prepare' to 'protected', as you can't
(of course) protect something that's been public in a parent class. The
other way around seems fine for PHP... Eventually all actions will have
protected 'prepare' (use execute/run)
A feature of the previously fixed initialization of Action classes, is
that we now have $this->scoped which is the current profile in use. As
of now that is always a local User, except the corresponding Profile
object.
Also, instead of calling 'showForm' everywhere, in case of an error we
just throw an exception of some sort and pass the message along there.
I've also introduced in FormAction the 'showInstructions' function in
order to get a unified instructions/info/error display method.
TODO: Improve info/error message handling, and what/when/where to show.
Action classes can now be run by calling the static function 'run'.
Eventually actions will be migrated so most functionality gets put
into parent classes, and the children don't have to have as much
duplicate code as they have now.
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...)
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.
It may be a bad experience for new users to immediately when trying
out the service be asked for their geographical position. Instead,
let them opt-in for this behaviour.
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 bd23a7da105d635414643dfcedd9c8f710d565b8
Author: Evan Prodromou <evan@e14n.com>
Date: Sat Jun 29 07:49:03 2013 -0400
Make the after flag work correctly
commit 5c5845a2f866f0bbffedd8e2e5d1f512f87d5329
Author: Evan Prodromou <evan@e14n.com>
Date: Sat Jun 29 06:14:43 2013 -0400
Add an 'after' flag for backup script
commit bd23a7da105d635414643dfcedd9c8f710d565b8
Author: Evan Prodromou <evan@e14n.com>
Date: Sat Jun 29 07:49:03 2013 -0400
Make the after flag work correctly
commit 5c5845a2f866f0bbffedd8e2e5d1f512f87d5329
Author: Evan Prodromou <evan@e14n.com>
Date: Sat Jun 29 06:14:43 2013 -0400
Add an 'after' flag for backup script
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).
