* Possible fix for #5470:
- $data is not an object like stdClass but an array
- newer PHP versions doesn't allow cross-access like following:
$object['foo'] = 123;
$array->foo = 123;
- added type-hints for private methods for above cases
- used `if (empty($foo)) instead of just `if ($foo)` preventing some nasty
E_NOTICE
- added some empty lines for better readability
* Rewrite:
- mixture of object/array was here, causing under newer PHP versions some E_NOTICE
- this has been now finally fixed by converting any `object` type to an
associative `array`
- also changed `is_object()` to `is_array()`
* Rewrites:
- moved PAGE_* to Friendica\Model\Profile class
* Fixed more rewrites from plain (global namespace) PAGE_* to Friendica\Models\Profile class
* CR request:
- moved all PAGE_* constants to Friendica\Model\Contact class
- fixed all references of both classes
* CR request:
- moved ACCOUNT_TYPE_* constants from boot.php to Contact::ACCOUNT_TYPE_*
* Just copy-pasted this code from boot.php, needs to be changed to `const ACCOUNT_TYPE_FOO = x;`
* Ops, melting brain cells here ... :-/
- $data is not an object like stdClass but an array
- newer PHP versions doesn't allow cross-access like following:
$object['foo'] = 123;
$array->foo = 123;
- added type-hints for private methods for above cases
- used `if (empty($foo)) instead of just `if ($foo)` preventing some nasty
E_NOTICE
- added some empty lines for better readability
* The permission set is now used for item permissions
* Check for allow_cid, ... is superfluous. Checking for "private" is enough
* We query the permissionset
* Permissions are displayed correctly
* Changed index
* We don't store the permissions in the item table anymore
* Permission fields are now deprecated
* Reversed ...
* "normal" is an uncommon logger level:
- changed LOGGER_NORMAL -> LOGGER_INFO
- added LOGGER_WARNING (a common logger level)
* Used constants instead of values (MrPetovan)
- added type-hints for DOMDocument, DOMXPath and array
- added missing documentation about optional parameter
- `if ($foo['bar'])` is not a good choice, better use
`if (!empty($foo['bar']))` instead
- added internal TODO to decide about is_result() usage
- removed semicolon (not needed here) from SQL query
- added empty line
Signed-off-by: Roland Häder <roland@mxchange.org>
* "post-type" replaces "bookmark" and "type"
* Removed some more type
* Added index to permission set
* The permission set is now stored
* The permission set is now removed upon expiry
* Post update now stores the permission set
* New file
* Permissions are now sorted
* Changed documentation
- fixed E_NOTICE in mod/follow.php
- fixed 2 E_NOTICE in src/Protocol/Diaspora.php
- added more type-hints for `array` type where known
Signed-off-by: Roland Häder <roland@mxchange.org>
* Use "LEFT JOIN" to always fetch the item. Needed for update routines.
* New conversion routine that now covers every item
* Post update is now activated
* We now use a hash based upon RIPEMD-320 for content and activity
* The hash doesn't contain the plink anymore
* Legacy item fields are now "null"able
* New hash function for a server unique item hash
* Introduction of the legacy mode (usage of old item fields)
* Code simplification
* We don't need the "uri" fields anymore in item-activity and item-content
* Use the "created" and not the "received" date for the hash
* Avoiding several notices
* Some more warnings removed
* Improved uri-hash / Likes on Diaspora are now getting a creation date
* Corrected the post update version
* Ensure an unique uri-hash
* Don't delete orhaned item data at the moment
* Partly reworked, due to strange behaviour
* Some more parts reworked
* Using the uri currently seems to be more reliable
* Using the uri here as well
* Use the hash values again
* Grouped item fields in different categories
* Notices again
* use the gravity (we always should)
* Added hint for disabled post updates
* Notices ...
* Issue #5337: Personal notes are displayed again
* Use the gravity again
* Some more warnings removed
* Even more warnings ...
* Will it ever end? ;-)
* Avoid warning in dbstructure
* Origin and OStatus ...
* There are more warnings solved ... yeah!
* And again ...
* We are not done yet
* And more ...
* And some new places ...
* And more in the feeds
* Avoid some more
* And some backend stuff
* Notifications cleared
* Some more stuff
* and again ...
* It's getting fewer ...
* Some warnings had been hidden in the notifications
* Fix the fix
* And another missing one ...
* We need the owner here, not the user
* Forgotten user
* And more ...
* And some more warnings disappeared ...
* Some more frontend warnings
* Some backend warnings removed
* Fixed sidebar for "vier"
* And more ...
* Some more ...
* And something for "remote self"
* Am I stuck in an endless loop?
* Fix: Clear tag and file field on update
* Preset page content
