| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
but the entries aren't going to link to anything until we have a webpage search ability. But this will be a way to exercise and test widget arguments.
|
|
|
|
| |
interfaces. Much work remains beofre we're ready to actually use this interface. Think of it as a conceptual outline and I'm starting to fill it in from the top down.
|
|
|
|
| |
thumb. Soften them as well
|
| |
|
|
|
|
| |
mod/cloud.php - there is no other documentation. Use at your own risk. Send all bug reports to nobody@nowhere.com.
|
| |
|
|
|
|
| |
(probably on a different site). All other conversations link to 'llink' which is a local copy and may provide a richer possibility of interactions, especially if you're logged in locally and it's your own copy of the post.
|
|
|
|
| |
derived/sourced channels. It's now just "$author via $xyz".
|
|
|
|
| |
issue #113 and also provides the ability to reshare from that page.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
show that settings may be inherited. The reason for this change is that we want the individual settings to be stored regardless of the inherited settings, because if somebody changes the higher precedence privacy settings it could leave all their existing contacts with no permissions and this could be a support nightmare.
So this way if somebody starts off with "anybody on the network can send me their stream and posts" and later changes it to "only specific connections can send me their stream and posts", the individual setting will already be set for all their connections. The previous behaviour is that this setting would have been disabled so none of their existing connections will have this specific permission. Old-timers who were here and made lots of connections before this commit - will have to edit all their connections if they change their privacy settings from lesser restrictive to be more restrictive.
|
|
|
|
| |
not remember who it is/was.
|
| |
|
|
|
|
| |
code (and all theme stuff) out of main code and into templates, but on the short term provide both so nothing breaks.
|
| |
|
| |
|
|
|
|
| |
code and may create some new bugs due to regression
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
part of the normal import_xchan sequence - otherwise we get two for every change. Create it normally if we are called with a profile_update message and don't go through the whole import_xchan thing.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
to update table to store the target address since it's possible the mirroring directory won't yet have an xchan or hubloc they can link the ud_hash to and therefore mayn't know how to contact them.
|
| |
|
|
|
|
| |
added the option for multiple configs, I didn't make it work as it requires quite a bit of change to the shred program flow; which tries to load the default config before doing anything at all.
|
|
|
|
| |
completely NOT work, so at least there's some improvement
|
|
|
|
| |
viewsrc to item_photo_menu, and log what changed in import_xchan update objects so we can find out why there are so many updates when nothing _obvious_ has changed that should trigger it.
|
|
|
|
| |
hubloc if anything at all changed anywhere.
|
|
|
|
| |
posts have recipients.
|
|
|
|
| |
down has been solved.
|
|
|
|
| |
very old bug that's been reported time and time again and nobody every bothered to debug or even report it somewhere where we could monitor it. It's buried somewhere in my stream, but basically is "things don't work right if you've got 'everybody in my address book' permissions" on "can send me their channel stream and posts". I think this is Michelle's problem and anybody else who has en empty matrix after making lots of connections.
|
|
|
|
|
|
| |
logger_data level) on failure
This should probably be at a lower log level, but unsuccessful connections could happen a lot on a busy production site so we'll try to keep the log noise down unless somebody really needs to track this info.
|
|
|
|
| |
I'm making this up as I go and not exactly certain where to go next but it makes more sense now and I think the basic idea will actually work. I'll just have to keep making it up until it does work.
|
| |
|
| |
|
| |
|
|
|
|
| |
problem.
|
|
|
|
| |
at the moment and just want everything to fall into place quickly. The clerical work will have to wait.
|
| |
|
|
|
|
| |
important bits are in place.
|
|
|
|
| |
as a block editor, and probably a layout editor as well. Eventually, these should all probably just be switches onto a single editor instance. Decided to put the layout_mid into the item table directory rather than re-use resource_id, so that we can still have pages attached to different resources like photos and events and stuff. The block editor is far from finished, at this point I've only cloned it and changed the name and type of item it looks for.
|