Ideally the character set should be set with the connection, and so this is
exactly what's being done now.
And now the character set code is attempted to be generalised.
"Magic quotes" were removed in PHP 5.4, no need to mitigate it anymore.
Avoid implode() with the join()-like order of arguments which was deprecated
since PHP 7.4 and implicitly since PHP 5.3.
Also avoid implode() with an implicit separator for stylistic reasons.
mktime() with no arguments has been deprecated since PHP 5.1.
ImageMagickPlugin:
- Remove animated thumbnail setting, we'll be able to use FFmpeg for performance
- Remove onFillImageFileMetadata and onCreateFileImageThumbnailSource(), these
are handled just fine by ImageFile
- Bump minor version number
README:
- Update
This check made registration impossible when welcomeuser didn't have validation
as well.
And rename the "grandfatherCutoff" option to "exemptBefore".
"Grandfathering" is a relatively obscure term linked to the history of the
United States of America, so replace that with something self-descriptive.
This adds a requirement for all definitions that have foreign keys to also
require indices for all source (local) attributes mentioned in foreign keys.
MariaDB/MySQL creates indices for source attributes automatically, so this
serves as a way to get rid of those automatic indices and create clean explicit
ones instead.
In PostgreSQL, most of the time, indices on the source are necessary to
decrease performance penalty of foreign keys (like in MariaDB), but they aren't
created automatically, so this serves to remove that difference between
PostgreSQL and MariaDB.
- getMessages() is now fetching from the Notice table as supposed
- every show{format}* method is properly updated to use Notice objects
- json and xml responses retrieve multi-recipients without compromising
backwards compatibility
Instead of relying on the MariaDB's ON UPDATE CURRENT_TIMESTAMP trigger update
"modified" attributes in Managed_DataObject. Every raw query that needs
adjusting is adjusted, as they won't update "modified" automatically anymore.
The main goal behind this change is to fix "modified" updates on PostgreSQL.
This way UNKNOWN (NULL) explicitly turns to FALSE when three-valued logic is
reduced to binary.
In pgsqlschema, however, use "IS FALSE" as boolean attributes in pg_index are
non-nullable, there is no outer join and there's no clear preference for NULL
reduction.
Over-complicated constructions in TagCloud queries have been simplified, which
should not affect their performance.
Additionally, in TagCloud's lib/subscriptionspeopleselftagcloudsection.php
a typing mistake in an equi-join of "profile_tag" and "profile_list" on
"tagger" was fixed.
That regression was introduced in f446db8e2a
Argument 3 passed to htmloutputter::input() must be of the type string or null, array given, called in /srv/gnusocial/plugins/Bookmark/forms/bookmark.php on line 166
Argument 1 passed to xmloutputter::text() must be of the type string, null given, called in /srv/gnusocial/plugins/ExtendedProfile/lib/extendedprofilewidget.php on line 556
There was no checking of attributedTo, actors and referent object IDs to make
sure they exist in the same domain. Therefore, one could spoof messages from
people by doing attributedTo: whoever-i-want-to-spoof
Avoid the use of deprecated MariaDB "zero dates" globally. If they're present
as attribute defaults somewhere, they will be replaced with NULL implicitly.
The existing "zero dates" in MariaDB storage will be left intact and this
should not present any issues.
The "timestamp" type in table definitions now corresponds to DATETIME in
MariaDB with "DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP", which
should be close enough to the original behaviour for compatibility purposes.
It is now the recommended type for "modified" attributes, because of the
update trigger on MariaDB. But there is no such trigger implemented on
PostgreSQL as of this moment.
Make common_sql_weight employ standard SQL functions for the timestamp
difference in seconds.
Also replace UTC_TIMESTAMP in the MariaDB-specific part with CURRENT_TIMESTAMP
as it is the only occurence and GNU social sets UTC as a default timezone.
In a delete_orphan_files.php script simplify the main query considerably.
In clean_profiles.php stop using COUNT as if it is ANY, that is unnecessary
punishment for the database. Instead implement the anti-join with a
left outer join.
In Autocomplete and Activitypub_profile use joins instead of a WHERE OR
anti-pattern for the semi-joins.
In lib/ui/galleryaction.php replace a CROSS JOIN with an INNER JOIN.
In actions/sup.php remove a redundant subquery: WHERE is applied before
grouping either way.
Activitypub_profile:
- Update do_insert to trigger TFN's assistance in inserting the profile
explorer:
- Use the new LRDD's method for grabbing profile aliases
Remove redundant setting retrival code.
An example config.php entry to activate the new config:
$config['site']['sensitivecontent']['hideforvisitors'] = true;
This should fix nulls on explorer lookups inputed by postman after generate_followers/getSubscribers, that I think were caused by calling common_profile_uri that, curiously, only handles local profiles
Use $object->sqlValue('NULL') (identical to DataObject_Cast'ing) instead and
fix related issues like (email|sms)settings considering these NULLs as a
false positive for the E-Mail address still being set when it's been removed.
There could also be security implications to the now-disabled approach of
considering 'NULL' strings as SQL NULLs.
ActivityPubPlugin:
- Rework onProfileDeleteRelated to account for the tables _rsa and _pending_follow_requests
- Update onEndShowAccountProfileBlock to stop creating the ap_profile if it doesn't exist (we'll handle this in a different manner)
Activitypub_profile:
- Remove unnecessary code from from_profile method and add return type information
Explorer:
- Update travel_collection to call itself instead of _lookup, that was wrong
Trying to enable the RedisCache with the latest nightly, getting this with the daemon:
sep 25 11:40:18 friedrich startdaemons.sh[21428]: PHP Fatal error: Uncaught Error: Call to a member function getPayload() on null in /var/www/social/plugins/RedisCache/RedisCachePlugin.php:96
sep 25 11:40:18 friedrich startdaemons.sh[21428]: Stack trace:
sep 25 11:40:18 friedrich startdaemons.sh[21428]: #0 /var/www/social/lib/util/event.php(89): RedisCachePlugin->onStartCacheSet('gnusocial:herds...', Object(HubSub), NULL, 86400, false)
sep 25 11:40:18 friedrich startdaemons.sh[21428]: #1 /var/www/social/lib/cache/cache.php(202): Event::handle('StartCacheSet', Array)
sep 25 11:40:18 friedrich startdaemons.sh[21428]: #2 /var/www/social/classes/Memcached_DataObject.php(520): Cache->set('gnusocial:herds...', Object(HubSub))
sep 25 11:40:18 friedrich startdaemons.sh[21428]: #3 /var/www/social/classes/Memcached_DataObject.php(52): Memcached_DataObject->encache()
sep 25 11:40:18 friedrich startdaemons.sh[21428]: #4 /var/www/social/classes/Managed_DataObject.php(50): Memcached_DataObject::getClassKV('HubSub', 'hashkey', 'a38b9dc516371af...')
sep 25 11:40:18 friedrich startdaemons.sh[21428]: #5 /var/www/social/plugins/OStatus/classes/HubSub.php(47): Managed_DataObject::getKV('hashkey', 'a38b9dc516371af...')
sep 25 11:40:18 friedrich startdaemons.sh[21428]: #6 /var/www/social/plugins/OStatus/lib/hubprepqueuehandler.php(68): HubSub::getByHashkey('https://herds.e...', 'https://raki.so...')
sep 25 11:40:18 friedrich startdaemons.sh[21428]: #7 /var/www/social/plugins/RedisQueue/classes/RedisQueueManager.php(58): HubPrepQueueHandl in /var/www/social/plugins/RedisCache/RedisCachePlugin.php on line 96
Sign in to j
Refactored Activitypub_profile::ensure_web_finger to Activitypub_profile::ensure_webfinger
Do not throw exceptions in the handling of this event because we don't
want to stop the regular search just because we were unable to find
ActivityPub actors or notes.
