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)
This won't run properly if other scripts stop javascript execution before
it's time to crop (such as in the Bookmark plugin, which when writing this
hasn't been migrated to Jquery 2.x - so it stops on a '.die' call).
Some images were cleaned up from the theme/base/images/illustrations too.
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. :)
There are still several improvements which can be made, such as not
having an entirely separate setup of ajax form functions. Instead
those should be implemented in FormAction. But at least now we got
rid of the redundant code use in prepare/handle.
Also, there is no need to do 'return' after throwing a ClientError
Exception. And we'll use the Action->clientError for logging benefits
until the error handling is properly done all the way to backend.
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.
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.
Issue #3125 at http://status.net/open-source/issues/3125 (and its duplicate 3127) describe buggy behaviour when trying to create a new group - i.e. the group is still created but with nickname NULL.
The reason the group is created is that when failing Nickname::normalize, the function trySave() in actions/newgroup.php doesn't call 'return' - meaning it just keeps going despite the error thrown. It a
So the simple solution to this bug was adding a return call at line 128, inside the catch just after the showForm(...) call.
