Only serve tagprofile HTML if we aren't POSTing via ajax
This fixes an issue where POSTing the selftag form in the
profile_block sidebar via AJAX would generate an XML response
containing both the content from doPost() and showPage(),
resulting in invalid XML.
These changes make it so that if we're POSTing via AJAX,
we serve content from doPost(), otherwise we serve showPage()
but never both.
See merge request !8
This fixes an issue where POSTing the selftag form in the
profile_block sidebar via AJAX would generate an XML response
containing both the content from doPost() and showPage(),
resulting in invalid XML.
These changes make it so that if we're POSTing via AJAX,
we serve content from doPost(), otherwise we serve showPage()
but never both.
Sometimes we just want to accept the user's wrong, but when it comes
to remote APIs etc. we probably want to let the client know it has
done something already (in this case multiple identical subscription
requests - which might indicate to it that it should refresh the sub
lists or something).
For some reason the "retweeted to me" part of the Twitter API was removed
when Evan made some inbox changes back in the StatusNet days. We might
recover this functionality, but not yet. The proper function calls are
however fixed in this commit.
This goes for both users and groups, since they share nickname namespace.
If you want to enable nickname changes, just add this to your config:
$config['profile']['changenick'] = true;
This commit should cover all changes in our usual web forms as well as through
the API.
Calling serverError with a clientError status code (4xx) means it will
automatically default to Internal Server Error (500) which is in the
server error status code range (5xx). That is undesirable.
The code is now more event-driven when it comes to rendering notices
and their related HTML elements, since we can't have direct calls from
core to a plugin.
lib/activitymover.php has a function to move a Favorite activity which
will not happen now. The move must be pluginified and performed as an
event which plugins can catch on to.
Now we have to fix any code in the core which directly uses the Fave class
or any other favorite stuff, since it is pluginised and thus might not be
available on some installations.
No validation has been attempted yet. Lots of changes left. This
is visibly not (very) different from the previous CSS layout. But
some simplifications have been made.
Might cause issues with local changes to themes and CSS. Also maybe
javascript which depends on certain legacy microformats elements.
The move to microformats2 is motivated by the announcement that all
microformats should be migrated to version 2, as of 2014-06-20 at:
http://microformats.org/2014/06/20/microformats-org-turns-9-upgrade-to-microformats2
Conversation trees works pretty bad with the current layout, javascript
etc. So it's best if we separate it and work on it as a side-project. The
oldschool settings are currently being deprecated (or broken out like this).
I'll wait with removing User preferences for oldschool conversation tree,
since that might be reusable data. But I guess it will go in the near future.
It seems it was only used to get a _single_ file attachment from
the posted notice, with no possibility to get multiple attachments.
If one fetches metadata about attachments for the notice, we have
enough data there to fulfill anyone's fetching dreams.
The File object now stores width and height of files that can
supply this kind of information. Formats which we can not read
natively in PHP do not currently benefit from this. However an
event hook will be introduced later.
The CreateFileImageThumbnail event is renamed to:
CreateFileImageThumbnailSource to clarify that the hooks should not
generate their own thumbnails but only the source image. Also it now
accepts File objects, not MediaFile objects.
The thumbnail generation is documented in the source code. For
developers, call 'getThumbnail' on a File object and hope for the best.
Default thumbnail sizes have increased to be more appealing.
Actions have $this->scoped as the current profile which we can gladly
replace all the $cur=common_current_user() with.
And we want the prepare/handle functions to be protected. Plus only
the prepare function uses $args (which _must_ be an array).
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.
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.
...no need to make a separate call to Local_group's setNickname all the time,
or a bunch of redundant code for the Profile table.
Next up is User->update()...
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 bet JSONSearchResultsList is a good idea, but we have no immediate use of it right now.
And it's better if the SearchEngine can take care of all that jazz.
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)
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.
