aboutsummaryrefslogtreecommitdiffstats
path: root/include/hubloc.php
Commit message (Collapse)AuthorAgeFilesLines
* figuring out how to bootstrap the change_primary procedure when all you have ↵friendica2014-10-131-0/+2
| | | | is inconsistent data which you think you trust.
* more diagnostic when changing primaryfriendica2014-10-131-4/+17
|
* sqlfriendica2014-10-131-1/+1
|
* new function hubloc_change_primary()friendica2014-10-131-0/+42
|
* that's why remove_obsolete_hublocs() isn't telling anybody when it does its ↵friendica2014-09-301-3/+3
| | | | thing, I forgot to uncomment the bit that tells everybody after I tested it. I needed extensive testing to make sure we didn't accidentally wipe out all hublocs everywhere. Testing went fine so I just assumed it was all working as planned; but went back today to find out why I wasn't told of a recent change.
* provide a way to sync locations and get rid of bogus hublocs, now implementedfriendica2014-09-141-12/+29
|
* some backend work for the remaining missing bits of mod_hubman - this is ↵friendica2014-09-131-1/+55
| | | | still a fair ways from being complete and is not ready for prime time. Basically we'll let a channel send out a public message saying "these are my currently approved locations" and anything that isn't in the list will be marked deleted. We'll send out this message when locations change somehow - either through direct personal involvement (hub revoke, change primary, channel import) or during a system rename or "find bad/obsolete hublocs" activity. This way we won't have clones sending back location info we just got rid of and re-importing the bad entries.
* remove some code duplicationfriendica2014-07-141-0/+12
|
* docofriendica2014-03-191-0/+1
|
* prune_hub_reinstalls() and add cron weekly as a side effectfriendica2014-03-191-0/+32