aboutsummaryrefslogtreecommitdiffstats
path: root/include/zot.php
Commit message (Collapse)AuthorAgeFilesLines
* sync_locations() toggle DB flag functions were broken - result of postgres ↵friendica2015-01-301-4/+22
| | | | changes. Split these into seperate set and reset blocks.
* let zot_refresh continue without a primary hub if one cannot be found. also ↵friendica2015-01-301-5/+14
| | | | weekly doc updates
* local_user => local_channelfriendica2015-01-281-1/+1
|
* add yet another firehose checkfriendica2015-01-281-1/+1
|
* more minor tweaks to the route mismatch algorithm after watching it all day.friendica2015-01-281-2/+5
|
* ignore route mismatches on firehose posts to the sys channel. Use whatever ↵friendica2015-01-271-1/+1
| | | | parent route we have. By definition we aren't going to have permission issues with these things.
* we need to actually ask for the id from the DB if we want to use it.friendica2015-01-271-1/+1
|
* improved route mismatch detection. We will be less strict about the absolute ↵friendica2015-01-271-2/+22
| | | | route matching and only look at the last hop before it got to us - which is ultimately all we should care about (since that sender controls the thread permissions). Route mismatches seem to occur somewhat frequently from yamkote (for unknown reasons), and the logging has been improved a bit so it should provide some slightly more useful debugging info in case it still happens going forward. Oh, also we'll set the parent on comments when we store the initial post (item_store()) and only go back and set the parent for top-level posts. This should reduce the number of comments with missing parents on shared hosts, but may increase the number of missing threads. Probably worthwhile to do a query occasionally for parent = 0 and see how we're doing and how many have shared host related delivery issues.
* handle an incoming directory rating messagefriendica2015-01-261-2/+45
|
* remove superfluous group byHabeas Codice2015-01-241-1/+1
| | | | | this gets called from a zot post_post dealing with a specific messageid and hubloc_hash combination. grouping by site doesn't make sense here and it gets grouped when pulled back out elsewhere anyway
* zot_finger second arg is optional but function declaration didn't specify ↵friendica2015-01-211-1/+1
| | | | this - causes issue with check_upstream_directory
* connection clone issuesfriendica2015-01-101-0/+3
|
* don't update locally deleted itemsfriendica2015-01-061-3/+8
|
* don't import to sys channel from self-censored authorsfriendica2014-12-121-1/+11
|
* can't reset public to false because it may have been passed in as true and ↵friendica2014-12-011-5/+5
| | | | this would be wrong and cause even more subtle bugs. Reset to whatever value was passed in.
* Somewhat subtle process_delivery() bug - $public was not being reset if a sysThomas Willingham2014-12-011-0/+1
| | | | channel is reached but then the loop iterated over another channel.
* change logging of some troublesome or noisy bits so we can figure out what ↵friendica2014-11-191-2/+2
| | | | is really going on
* couple of fixes:friendica2014-11-191-0/+5
| | | | | - significantly increase the content availability on the discover channel - fix the button group on the blog/list mode which made the border on a single comment button a bit wonky
* there's still a permission issue delivering a public post directly to the ↵friendica2014-11-191-0/+2
| | | | sys channel (on the local system), but this puts the local sys channel in the public delivery chain and fixes an issue with unseen counts showing on the discover page (where you can't do anything about it).
* add sys channel to public recips if scope publicfriendica2014-11-181-0/+12
|
* put timeout code in place but don't turn it on.friendica2014-11-131-6/+7
|
* Merge remote-tracking branch 'upstream/master'Habeas Codice2014-11-131-46/+97
|\ | | | | | | | | | | | | | | | | | | | | | | Conflicts: boot.php include/dba/dba_driver.php include/diaspora.php include/follow.php include/session.php include/zot.php mod/photos.php mod/ping.php
| * indicate public forums in directory results (there will be some [possibly ↵friendica2014-11-101-4/+5
| | | | | | | | considerable] lag time before existing forums are correctly tagged).
| * add public forum identification to libzot. No attempt is made to identify ↵friendica2014-11-101-2/+6
| | | | | | | | other types of forums or weird custom channel permissions. If the channel is auto-accept and taggable, it's a public forum.
| * don't overwrite $x (contains import_xchan result) with role permissionszottel2014-11-061-3/+3
| |
| * ok heads up - potentially destabilising change. I've tried to sort out all ↵friendica2014-11-041-9/+9
| | | | | | | | | | | | | | | | | | | | the default connection permissions for those who don't have a predefined (or therefore have a "custom") permissions role. Unfortunately this includes most people that were using this software more than a month ago. The real changes are that the SELF address book entry no longer holds "auto-permissions" but instead holds your "default permissions" (if you have a pre-defined role, the defaults will be pulled from the role table). The auto permissions have moved to a pconfig (uid.system.autoperms). A DB update will move these settings into their new homes. What used to be the "Auto-permissions settings" page is now the "default permissions settings" page and a checkbox therein decides whether or not to apply the permissions automatically. A link to this page will only be shown when you have the "custom" role selected. With luck nobody will notice anything wrong. But at least for the next few days, please review permissions that have been assigned to new connections (either automatically or manually) and make sure they make sense (e.g. they aren't "nothing"). You still need to take action when seeing a message "permissions have changed but not yet submitted" as we always let you review and perhaps adjust the settings _before_ a connection is established (unless you have autoperms turned on).
| * php warningsfriendica2014-11-021-23/+23
| |
| * I'm going to try again with the conversation request packets. I've looked ↵friendica2014-11-021-11/+55
| | | | | | | | this over and tested a lot of edge cases, and thought about from every angle I can think of to prevent looping. I don't *think* this can loop. I also doubt that this is the problem at friendicared.de, but I don't know for sure what that problem might be.
| * add some more safety checks before turning the conversation request messages ↵friendica2014-11-021-3/+5
| | | | | | | | back on
* | PostgreSQL support initial commitHabeas Codice2014-11-131-52/+52
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There were 11 main types of changes: - UPDATE's and DELETE's sometimes had LIMIT 1 at the end of them. This is not only non-compliant but it would certainly not do what whoever wrote it thought it would. It is likely this mistake was just copied from Friendica. All of these instances, the LIMIT 1 was simply removed. - Bitwise operations (and even some non-zero int checks) erroneously rely on MySQL implicit integer-boolean conversion in the WHERE clauses. This is non-compliant (and bad programming practice to boot). Proper explicit boolean conversions were added. New queries should use proper conventions. - MySQL has a different operator for bitwise XOR than postgres. Rather than add yet another dba_ func, I converted them to "& ~" ("AND NOT") when turning off, and "|" ("OR") when turning on. There were no true toggles (XOR). New queries should refrain from using XOR when not necessary. - There are several fields which the schema has marked as NOT NULL, but the inserts don't specify them. The reason this works is because mysql totally ignores the constraint and adds an empty text default automatically. Again, non-compliant, obviously. In these cases a default of empty text was added. - Several statements rely on a non-standard MySQL feature (http://dev.mysql.com/doc/refman/5.5/en/group-by-handling.html). These queries can all be rewritten to be standards compliant. Interestingly enough, the newly rewritten standards compliant queries run a zillion times faster, even on MySQL. - A couple of function/operator name translations were needed (RAND/RANDOM, GROUP_CONCAT/STRING_AGG, UTC_NOW, REGEXP/~, ^/#) -- assist functions added in the dba_ - INTERVALs: postgres requires quotes around the value, mysql requires that there are not quotes around the value -- assist functions added in the dba_ - NULL_DATE's -- Postgres does not allow the invalid date '0000-00-00 00:00:00' (there is no such thing as year 0 or month 0 or day 0). We use '0001-01-01 00:00:00' for postgres. Conversions are handled in Zot/item packets automagically by quoting all dates with dbescdate(). - char(##) specifications in the schema creates fields with blank spaces that aren't trimmed in the code. MySQL apparently treats char(##) as varchar(##), again, non-compliant. Since postgres works better with text fields anyway, this ball of bugs was simply side-stepped by using 'text' datatype for all text fields in the postgres schema. varchar was used in a couple of places where it actually seemed appropriate (size constraint), but without rigorously vetting that all of the PHP code actually validates data, new bugs might come out from under the rug. - postgres doesn't store nul bytes and a few other non-printables in text fields, even when quoted. bytea fields were used when storing binary data (photo.data, attach.data). A new dbescbin() function was added to handle this transparently. - postgres does not support LIMIT #,# syntax. All databases support LIMIT # OFFSET # syntax. Statements were updated to be standard. These changes require corresponding changes in the coding standards. Please review those before adding any code going forward. Still on my TODO list: - remove quotes from non-reserved identifiers and make reserved identifiers use dba func for quoting - Rewrite search queries for better results (both MySQL and Postgres)
* check that we have valid datafriendica2014-11-011-0/+1
|
* disable request message response until we work through thisfriendica2014-11-011-0/+3
|
* document request packets a bit morefriendica2014-10-311-1/+4
|
* flag notify packets that are sent in response to a message_id request and ↵friendica2014-10-311-4/+5
| | | | prevent them from recursing
* What this checkin does is catch the case where a comment arrived and there's ↵friendica2014-10-301-1/+82
| | | | a missing top-level post to match it with. So we'll send a request back to the sender that you've never seen this thread and please send a fresh copy of the entire conversation to date. We could soon have posts in the matrix from different platforms from days gone by, which have been migrated into the modern world. We'll be polite and not deliver these to everybody. However, if someone comments on one of these antique threads we wouldn't be able to see it in our own matrix because we won't have a copy of the parent post. So this rectifies that situation. Be aware that item deletion may need to change to keep "hard deleted" items indefinitely so that they don't keep coming back. We'll have to null out the important data of the former item to accomplish the deletion aspect.
* Tried this once before but had to revert. Basically prevent a comment from ↵friendica2014-10-191-1/+7
| | | | being relayed more than once - as it's a huge drain on resources. But last time I tried this, wall-to-wall comments stopped getting relayed. This checkin should do the right thing in both conditions.
* if a hubloc primary change results in an xchan primary change, create a ↵friendica2014-10-131-1/+5
| | | | directory update packet.
* figuring out how to bootstrap the change_primary procedure when all you have ↵friendica2014-10-131-0/+4
| | | | is inconsistent data which you think you trust.
* don't use cached datafriendica2014-10-131-0/+2
|
* there's the problemfriendica2014-10-131-2/+2
|
* new function hubloc_change_primary()friendica2014-10-131-3/+18
|
* cleanup of sync_locations and better logging. There was one significant code ↵friendica2014-10-121-7/+11
| | | | change but it is unrelated to current issues, basically if no primary was set we were setting everything as primary.
* ah yes, the redundant relay run was for the benefit of wall-to-wall posts ↵friendica2014-10-101-2/+1
| | | | issue #633
* missing source route after editfriendica2014-10-101-0/+2
|
* improvement in source route checking when handling complex *upstream* ↵friendica2014-10-101-6/+19
| | | | delivery chains, which were not adequately accounted for in the earlier checkin.
* allow (our own) ajax urls to pass through bbcode intact.friendica2014-10-091-1/+2
|
* OK this is important. So read it carefully.friendica2014-10-091-3/+33
| | | | | | | | This checkin implements route matching of comments so that they are only accepted from the same route as the top-level post they are attached to. This way there should be no mis-match of permissions between any posts in the thread. It may not be completely compatible with comments posted in the past (though I've tried to be, there may be some minor issues). In addition it seems that relaying was invoked more often than necessary - especially when a duplicate post arrived which was not processed because the edited time hadn't changed - it still invoked relaying. This fix should improve site performance considerably for comments cross-posted to forums; which got bounced around a bit and delivered redundantly for no reason. Roll this back *only* if it causes a meltdown or comment loss is "serious" (as in OMG people are dying, make it stop!). If we can get past 24 hours without serious issue we need to get everybody onto this code. There may be some minor comment loss (mostly affecting new comments to older posts or likes of older comments) until the majority of sites have moved to the new code. It may be difficult or impossible to deliver comments to posts that pre-date the addition of source routes (April 1, 2014) to anybody but the top-level post author at his/her primary hub. We may wish to close comments on these posts, but let's see how we go before doing that.
* ability to pre-populate connections for new channels. e.g. "MySpace Tom"friendica2014-10-011-2/+0
|
* found the suckerfriendica2014-09-221-2/+2
|
* just mark dead hubloc deleted - don't remove them. This could cause ↵friendica2014-09-161-2/+4
| | | | problems. Also clean up fetch_url/post_url header option
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-17 16:31:39 +0000