aboutsummaryrefslogtreecommitdiffstats
path: root/version.inc
Commit message (Collapse)AuthorAgeFilesLines
* there's no $a in comanche_block() (zottel)friendica2013-09-301-1/+1
|
* Issue #158friendica2013-09-291-1/+1
|
* fix can_comment_on_post when viewing wall-to-wallfriendica2013-09-281-1/+1
|
* structure for channel unionsfriendica2013-09-261-1/+1
|
* suppress creating the directory update record for profile updates which are ↵friendica2013-09-251-1/+1
| | | | 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.
* reduce susceptibility to bleichenberger attackfriendica2013-09-241-1/+1
|
* oauth settings - clarify textfriendica2013-09-231-1/+1
|
* adult channel settingfriendica2013-09-221-1/+1
|
* rev updatefriendica2013-09-201-1/+1
|
* sync item_search with yesterday's network fix for collections. Add ud_addr ↵friendica2013-09-191-1/+1
| | | | 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.
* make collections work againfriendica2013-09-181-1/+1
|
* add -C cfgfile option to shred to allow multiple configurations. I just ↵friendica2013-09-171-1/+1
| | | | 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.
* several oauth fixes - shred doesn't completely work yet, but it also doesn't ↵friendica2013-09-161-1/+1
| | | | completely NOT work, so at least there's some improvement
* implement what I hope will now be the server side of directory sync, add ↵friendica2013-09-151-1/+1
| | | | 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.
* import_xchan - check every known hubloc/location field and create a new ↵friendica2013-09-141-1/+1
| | | | hubloc if anything at all changed anywhere.
* doc update, put more telemetry on notifier and try to ensure that private ↵friendica2013-09-131-1/+1
| | | | posts have recipients.
* remove some debugging stuff now that the problem they were trying to locate ↵friendica2013-09-121-1/+1
| | | | down has been solved.
* assuming this doesn't blow up the internet like the last fix - this is a ↵friendica2013-09-111-1/+1
| | | | 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.
* z_fetch_url - include curl debug info in return array and log it (at ↵friendica2013-09-101-1/+1
| | | | | | 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.
* some alteration to the way directory sync was originally supposed to work. ↵friendica2013-09-091-1/+1
| | | | 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.
* rev updatefriendica2013-09-081-1/+1
|
* allow menu management even if there are no menu itemsfriendica2013-09-071-1/+1
|
* provide mimetype selector on edit (pages and blocks)friendica2013-09-061-1/+1
|
* fix network search - except it can't search private posts. That may be a ↵friendica2013-09-051-1/+1
| | | | problem.
* render blocks - yes these should be templates, but I've got too much to do ↵friendica2013-09-041-1/+1
| | | | at the moment and just want everything to fall into place quickly. The clerical work will have to wait.
* testing Comanchefriendica2013-09-031-1/+1
|
* webpage content-type -- needs cleaning up and a security check once all the ↵friendica2013-09-021-1/+1
| | | | important bits are in place.
* This isn't optimal, but on the short term we'll clone the page editor to use ↵friendica2013-09-011-1/+1
| | | | 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.
* more debugging on localize_item top find out why likes are not translated in ↵friendica2013-08-311-1/+1
| | | | notifications, but are in displayed posts (using 'new' on matrix page) - in one case we're successfully pulling stuff from item['object'] and in the other we aren't - and it's the same object.
* block attempts to set the baseurl to an ip address if it was previously a ↵friendica2013-08-291-1/+1
| | | | dns name
* right - here's how we're going to link comanche with webpagesfriendica2013-08-281-1/+1
|
* get rid of ssl_policy - it's implicit in the site urlfriendica2013-08-271-1/+1
|
* regex patchfriendica2013-08-261-1/+1
|
* always use system provided baseurl if configuredfriendica2013-08-251-1/+1
|
* fix xchans more completely after a URL changefriendica2013-08-241-1/+1
|
* add zid to connect_urlfriendica2013-08-221-1/+1
|
* poll stufffriendica2013-08-211-1/+1
|
* fix superblock for commentsfriendica2013-08-201-1/+1
|
* if changing primary hub during an import operation - remove the old xchan ↵friendica2013-08-191-1/+1
| | | | and create a fresh xchan pointing at this instance. Also a minor edit to increase the default photo upload limit for new sites. There aren't many cameras left that will take photos < 800k in size.
* Another try at issue #61 and #62 - an earlier fix was partially working but ↵friendica2013-08-181-1/+1
| | | | the issue persisted - this extends it a bit.
* issue #82, posted order not working - also doc updatefriendica2013-08-171-1/+1
|
* not able to drop pending connectionsfriendica2013-08-151-1/+1
|
* ru strings updatedfriendica2013-08-141-1/+1
|
* a bit more work on menusfriendica2013-08-131-1/+1
|
* theme personal menus so they look more or less like widgetsfriendica2013-08-121-1/+1
|
* don't import any hubloc that doesn't have a sitekey. Eventually we should ↵friendica2013-08-111-1/+1
| | | | also verify that it is a valid key, as we've already seen one case where one character got mangled and messed up communication.
* move sitekey creation to the account creation function instead of during ↵friendica2013-08-091-1/+1
| | | | channel creation. Channel import bypassed sitekey creation completely. We should do it during install, but it's possible somebody might have to install manually and the sitekey would never get created. This is the best compromise I can come up with. Looks like the doc tree was also updated in this checkin
* malformed ru string filefriendica2013-08-081-1/+1
|
* big changes to photo->store() which is now photo->save() and takes an array ↵friendica2013-08-071-1/+1
| | | | instead of a list of args. Also the beginning of the migration to using photo_flags to indicate special purpose photos such as profile photos and contact photos and "thing" photos.
* we've been storing json_encoded structures on disk in several places because ↵friendica2013-08-061-1/+1
| | | | it's a lot easier to parse than xml - but OMG do they get mangled - stored as single quoted strings when escaped as if double quoted. We need to use my new function json_decode_plus() wherever we need to parse one of these babies to make sure we get it right. Maybe we should've just used serialize().
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-28 06:49:06 +0000