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.
The only reason it worked was because DB fetches calls to get$varname if
the dataobject has a variable with the specific name. However, it started
blurting out errors that the case must be correct (which would require
'geturl' to be the function name).
Since we probably want to replace DB sometime, we'll just override this
auto-fetching mechanism and use more explicitly defined functions.
Avoiding collisions with date (shorter than before) and 4 character
random alphanumeric string. I bet someone could mass-upload files
and generate all combinations of aaaa-zzzz during the course of a
day, but then maybe that user should be disabled anyway :)
(filling the collision space will cause a never-ending loop).
The exception thrown from MediaFile will be caught and simply result in
no thumbnail at all right now. In the future we might use a catch-all
and have a "cannot generate preview"-icon or something.
VideoThumbnails requires php5-ffmpeg and php5-gd.
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.
This will work without much extra effort because there will always be
more notices (higher value) than conversations (so no collisions).
But please run upgrade.php to avoid having an autoincrement id on
conversation table.
Installations using code after 2014-03-01 will have identical
conversation IDs to the initial (conversation root) notice IDs. This
will not affect older installations, which will have very different
values.
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.
NoResultException was the wrong choice in this case, because it was
not a DB_DataObject instance that performed the search, but a static
call to the Notice class.
This reverts commit 8cc4660bd9.
This seems like something Evan only did to make pump.io import notices easier,
or maybe he just wanted to get rid of the identi.ca URLs?
This is the beginning of getting notice URI info via WebFinger
*XrdActionLinks is renamed *WebFingerProfileLinks, check EVENTS.txt
in WebFinger plugin for new events.
_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.
...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()...
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.
Profile_prefs aims to consolidate all the profile preferences into a
single table. Otherwise we end up with a bajillion *_prefs classes, like
User_urlshortener_prefs, or new fields in existing User/Profile classes,
like 'urlshorteningservice', 'homepage', 'phone_number', 'pet_name' etc.
Eventually we should migrate as many user-settable preferences as we can
into this system.
The data in Profile_prefs is organized by:
* profile_id Identify the current Profile.
* namespace Which plugin/section the preference is for.
* topic Preference name (like 'homepage')
* data Preference data (like 'https://gnu.org/')
The names 'topic' and 'data' are because 'key' and 'value' may be rather
ambigous when dealing with our DB_DataObject classes etc.
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.
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.
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...)
Not all instances of this has been fixed, but at least the ones
in the base class of Memcached_DataObject.
Avatar fix (in classes/Profile.php) requires a pkeyGet function
in the Avatar class (or as in this tree, the parent class of
Managed_DataObject)
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 parent class for our database objects, Managed_DataObject, has a
dynamically assigned class in staticGet which objects get put into,
leaving us with less code to do the same thing.
We will probably have to move away from the DB_DataObject 'staticGet'
call as it is nowadays deprecated.
We always call staticGet statically, so we define it statically. Next
step is to remove a bunch of definitions of 'staticGet' from classes
that can instead fall back to a parent class in Managed_DataObject.
The ampersand is removed as we're returning a class anyway, which does
not need a reference (and when we return false, it means nothing).
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.
If you look at classes/User_group.php on line 412 in the current code, you can see that a call to $profile->getGroups() is made. This implies getGroups($offset=0, $limit=PROFILES_PER_PAGE) only giving a limited amount of groups.
This means only the first 20 groups in an ascending numerical order by locally stored User_group->id will be addressable with the bangtag syntax.
I solved this by making the getGroups() call to the same one made in Profile->isMember(), i.e. $profile->getGroups(0, null);
User::getTaggedSubscriptions()
This change escapes the $tag argument to prevent a SQL injection
attack in User::getTaggedSubscriptions(). The parameter was not
escaped higher up the stack, so this vulnerability could be exploited.
This change escapes the argument to User::getTaggedSubscribers() to
prevent SQL injection attacks.
Both code paths up the stack fail to escape this parameter, so this is
a potential SQL injection attack.
This patch escapes query parameters in Profile_tag::getTagged(). This
is an extra security step; since these parameters come out of the
database, it's unlikely that they would have dangerous data in them.
