We've updated the site with the following changes, fixes and new features!
Beta 70
* Added: A bunch of new site banners! Many thanks to the artists who created them. Hover over the site logo to see the changer so you can cycle through them, or hit the “R” to see a random one per page load. Banners are always welcome, but we cannot guarantee if/when they will be added due to the highly manual process it takes to add them at the moment.
* Added: The artist’s name now appears when hovering over the chosen site logo/banner.
* API- Added: There is now an interface in the API to get all the users who +faved a submission. Only the submission owner or a moderator can access this information (others will receive error code 42). https://wiki.inkbunny.net/wiki/API#Submission.27s_favin...
* Changed: Donors now get to keep their sponsor badge for up to one year depending on the amount donated over a given period (it drops one level at three and six months, and reverts to the “past sponsor” leaf icon once it drops below Bronze level). See https://inkbunny.net/donations.php#details for a list of the donor levels.
* Fixed: Several submissions imported using FA2IB had broken Fur Affinity username or submission links in their descriptions. These should work now.
* Changed: We’ve increased the per-connection speed limit to 2MB/s as we have the spare overhead in our bandwidth. This should mean faster page loads for people with fast internet connections.
* Security: We have dropped SSLv3 support, to protect our site and users from recently discovered exploits in that protocol. Users with very old browsers may need to update to access the site. https://inkbunny.net/journalview.php?id=153381
* Fixed: Better indication and explanation for when users banned from your account were added to your banlist by staff (which means you cannot unban them yourself).
* Changed/Added: When you unban a user you banned from your account, it now has a delay (currently 6 hours) before the unban actually takes effect. This is to prevent people unbanning people for brief periods just to comment on their accounts, then banning them again (because if you ban someone from your account, it stops you commenting on their account or replying to their comments too).
* Fixed: Better support for multibyte characters when truncating strings. Previously when text contained special characters like Chinese characters, it would sometimes break and display blank areas when we tried to cut text to a certain length such as for journal text summaries. For example we now tell the system to return “the first 100 characters” rather than “the first 100 bytes”.
* Optimised: Our PHP session files were storing a whole bunch of redundant data. We’ve trimmed them to 10% of their original size, saving disk space, memory and giving us a bit of a speed boost.
* Fixed: Formatting issues for the “Sort By” and “Date Range” options on the Search Results page caused by the addition of search options.
* Updated: Revised the list of suggested streaming services at the top of the “Advertise Stream” page.
* Fixed: Sometimes a registered Twitter account wouldn’t show automatically on the userpage contact details list when the user had turned that option on.
* Fixed: Now displaying the correct error page to guests if they try to perform some actions that require a login.
* Fixed: User icon uploads now checks if the user has overall file upload permission.
* Fixed: A bunch of little spelling and grammar issues were corrected.
* Optimised: Skip checking what users the Guest user is watching (data we cache per request for logged in users). That was redundant when Guest can never watch.
* Optimised: Don’t check for next/previous items in pools if there are no pools to display for the user account being viewed.
* Optimised: Don’t try to iterate through empty arrays in a bunch of places if no results are returned for a search. This cuts down on superfluous warning messages in the logs and gives us a little speed boost.
* Optimised: Set default values for some functions where leaving those values null was causing benign warnings in the error logs. Gives us less cluttered logs and a little speed boost.
* Optimised: A bunch of other little chunks of superfluous code, duplicate IF statement checks and other silly things removed.
* Optimised: Now using multithreaded XZ as our preferred compression method for logs. This makes log processing faster and saves disk space.
* Optimised: Stop logging every database connection via the connection pooler. This was redundant info that was filling up log files.
* Changed: The message on the Donors page now says that having your Donor Icon displayed is optional, rather than off by default. We found that most people wanted their icon turned on by default, so having it off wasn’t efficient.
* Updated: Lots of improvements to the server and web application install and maintenance documentation.
* Changed: There’s now a more helpful message in the Location pages that advises you to choose a nearby location in the same timezone if your particular city isn’t found, or no cities are found in your country.
* Optimised: We now use NR_HUGEPAGES memory option in Linux to allow more efficient use of memory space by the database.
* Optimised: Changed logging options for Piwik site activity tracker to optimise disk space usage and speed.
* Optimised: Enabled buffered logs for Apache and Postgresql, which eases the load on the disk I/O and gives us a speed boost.
* Fixed: Submission owners can now add keywords to their own HIDDEN (non-public or friends-only) submissions via the keyword suggester on the submission page. Previously it would give them the same error message that others would see if they tried to add suggested keywords to a hidden submission.
* Changed: We now use HSTS (Strict-Transport-Security) on all subdomains. We were already using it on the main domain. This means subdomains such as http://wiki.inkbunny.net will always try to use https:// instead of http:// regardless of what protocol is in the actual URL.
* Fixed: The Roles Management page (a moderator tool) now remembers the settings you chose if it returns to that page to display an error, such as a mistyped password.
* Changed: Site descriptions now place less emphasis on currently disabled sales features.
* Changed: Made it more clear on user account creation that you must agree to the Acceptable Content Policy (ACP). Previously this was implicit in agreeing to the broader Terms of Service. This hopefully means new users will read and understanding the ACP before posting.
* Changed: Improved the wording of the login error message to help users better work out why their login attempt might be failing and how to fix it.
* Fixed: FA usernames containing '^' and '.' will now be correctly linked in contact details
* Fixed: Trying to log in to a deleted account will now show a more meaningful error message on the login screen.
* Changed: “Popular” page now shows top 120 submissions in the last 3 days (was top 100). 120 items divides into the 60 items per page much more nicely, plus you get to see a few more submissions in the top list!
* Changed: Donation method signup links now use HTTPS
* Changed: AlertPay has been renamed to Payza
* Changed: Since Fur Affinity, SoFurry, deviantART, Twitter, YouTube, WikiFur, Wikipedia, Flayrah, F-list, e621, Flickr, PayPal and Facebook all support HTTPS, submission descriptions, journals, comments and profiles linking to them have been changed to use it. This stops anyone on the same network (except corporate proxied networks) from determining that you were using Inkbunny when using one of these links, or what page you were going to. We strongly suggest you use HTTPS when using and linking to Fur Affinity and SoFurry, as it is not currently their default.
* Changed: da!, fa! and sf! external links now use HTTPS. We recommend you use these shortcuts instead of bare URLs to user pages.
* Changed: YouTube, F-list, Steam and WikiFur profile links now use HTTPS.
* Changed/Added: When you unban a user you banned from your account, it now has a delay (currently 6 hours) before the unban actually takes effect. This is to prevent people unbanning people for brief periods just to comment on their accounts, then banning them again (because if you ban someone from your account, it stops you commenting on their account or replying to their comments too).
I understand the reasoning behind this change but I disagree with the criteria. Is it not possible and more practical to incite a change like this only if a user tries to rapidly ban and unban another user in the way you've described? If I unblock someone, I don't do it by accident; 6 hours is a surprising amount of time to wait for any block to be lifted. I think AIM did a similar thing with message spamming with its rate limiting system--all you really have to do is keep track of the amount of time between the block and the unblock in those functions and prevent the unblock if the user had just been blocked like... I don't know, more than once an hour beforehand.
The way things are now, you're inconveniencing all users for a behavior that may be common enough to address, but isn't common enough to justify gimping a pretty standard function in a way that few other sites I can think of have ever tried before.
Thanks for the updates! One thing, though: ~~~ Quote: * Changed/Added: When you unban a user yo
all you really have to do is keep track of the amount of time between the block and the unblock in those functions and prevent the unblock if the user had just been blocked like... I don't know, more than once an hour beforehand.
Unless I misunderstand, this is not as effective as what has been implemented. If you only measure block->unblock time, this still allows users to go "oh, that idiot I blocked the other day? Let's give them a hard time!" and immediately act on that. A mandatory cooldown reduces the set of abusers down to those few who are really determined, rather than merely bored.
In regards to the inconvenience, how common a task is unbanning, for an ordinary user?
~~~ Quote by Tweaker: all you really have to do is keep track of the amount of time between the
Well if you're approaching things in those terms, people can easily circumvent any form of prevention for harassing a user and unblocking/reblocking them at some nondescript point, including the changes made in this update.
I'm not saying that unblocking someone is this absolutely essential feature that everyone is going to use every day--hell, I barely ever block people and I unblock them even less. But I think that isn't a feature that should be time-restricted based on how a few people are abusing the system so they can leave snarky comments or antagonize people and prevent them from responding back. If you unblock someone, leave a comment and then try to reblock them, I think the system should keep you from doing that and find some way of recognizing that specific behavior instead of trying to make it a catch-all that inconveniences people using the system legitimately. That's all I'm saying.
Well if you're approaching things in those terms, people can easily circumvent any form of preventio
Well if you're approaching things in those terms, people can easily circumvent any form of prevention for harassing a user and unblocking/reblocking them at some nondescript point, including the changes made in this update.
Of course they can. This change simply means that premeditated intent is required, since abusers -must- wait 6 hours before they can carry out their abuses. This reduces the pool of possible abusers massively.
"
If you unblock someone, leave a comment and then try to reblock them, I think the system should keep you from doing that and find some way of recognizing that specific behavior
As a user, I agree. As a programmer, I cannot agree. Writing usable heuristic routines is in general difficult, and heuristics also tend to break in surprising ways when a corner case comes up. A simple exploit for what you describe is for the abusive user to simply implement the inverse policy ("I'll reblock them after 6 hours, and ignore any comments they make in the meantime").
"
instead of trying to make it a catch-all that inconveniences people using the system legitimately. That's all I'm saying.
I asked about frequency of unblocking because that is how to get a realistic measurement of inconvenience. If you visit IB 30 times in a month, and exactly one of those times you want to unblock someone, then you have been inconvenienced for ((6*60) * 1/30 == 12 minutes, assuming that you did want to communicate with the unblocked user ASAP; if you didn't, then you have not been inconvenienced at all.
~~~ Quote by Tweaker: Well if you're approaching things in those terms, people can easily circu
Not quite sure what you mean, can you be more specific? Or maybe a trouble ticket?
Banning another user will remove friend linkages, but not watches. However, if a user is banned from your account, you will not receive notifications when they watch you or when they +fav something of yours, and they cannot ask to be your friend.
Not quite sure what you mean, can you be more specific? Or maybe a trouble ticket? Banning another
and then after a few weeks of not being able to really get on..I get on and find that somehow I wasn;t watching him, but neither of us blocked or banned each other.
No..I mean like I was watching Rethex ( https://inkbunny.net/Rethex ) and then after a few weeks o
I wonder when (or If) you will implement a Mobile Version of the site,I have been wanting this to happen for a while now but never actually spoke up. I use my phone very often (more often than the computer) plus my time and ability to use this site on the computer is limited because of the location of the computer and the age of the inhabitants here (2 persons exceeding Retirement age) limiting the times I can be on the computer and the location of the computer limits what I can view on the site and im sure the same goes with other people the persons may be too young in some cases (ages 3 and 17 for A rated files)
I wonder when (or If) you will implement a Mobile Version of the site,I have been wanting this to ha
We're not going to promise something that we can't deliver yet, but it's definitely an area for us to improve on. I see people browsing FA on their phones at every meet I got to.
We're expect that as the site gets even more popular, developers will be interested in making more native apps for Inkbunny (we need to add some API features for this, notably comment reading and posting). But we could also make a mobile stylesheet that would work better.
We're not going to promise something that we can't deliver yet, but it's definitely an area for us t
At this time we suggest using a guest-blocked or friends-only journal to address such concerns. That doesn't mean we're not going to do anything else in the future, but we don't have a date for it. Update: We did something about it a few months later; profiles can now be hidden from guests.
At this time we suggest using a guest-blocked or friends-only journal to address such concerns. That
Please consider more options for the front page!! Sometimes I just want to see suggested submissions from the past 3 days instead of popular submissions; in the last year, there has been less and less variety in the "Popular submissions" default section as some artists begin to pull away from all the others...
Perhaps allowing users to change how they see the front page might be easier (and less controversial) to implement than changing the algorithm to favor newer / less popular (by watch count) artists~
good work @w@ Please consider more options for the front page!! Sometimes I just want to see sugge
A late comment, but it's worth mentioning; we've doubled the scope of Popular since then. We're also considering other means of improvement, such as a "rising stars" section (+favs / submitter watches).
A late comment, but it's worth mentioning; we've doubled the scope of Popular since then. We're also
ooh i love the new banners! kinda wish i would have know you were looking, i'd have given a shot on making one. Maybe another time.. now i cant decide which i like best X3
ooh i love the new banners! kinda wish i would have know you were looking, i'd have given a shot on
As a quick update: It's not that hardware-related news is a bad thing... it's just that I've seen a history of certain sites (well, just one, really) that only seem to talk about hardware updates as the solution to all performance problems. It's nice to see competent tuning taking place, instead of just screaming "MORE POWER!" when performance tanks.
As a quick update: It's not that hardware-related news is a bad thing... it's just that I've seen a
* Changed/Added: When you unban a user you banned from your account, it now has a delay (currently 6 hours) before the unban actually takes effect. This is to prevent people unbanning people for brief periods just to comment on their accounts, then banning them again (because if you ban someone from your account, it stops you commenting on their account or replying to their comments too).
Can you ban again in the 6-hour delay?
~~~ Quote: * Changed/Added: When you unban a user you banned from your account, it now has a de
No, but that's something we're going to change real soon now (or at least next revision, after some internal debate about how best to do it :-). Will essentially just clear the scheduled un-ban.
No, but that's something we're going to change real soon now (or at least next revision, after some
I'm glad to see such attention to security! You guys rock.
On a related note, is there any chance we'll get to see some PGP features at some point down the line? Maybe allow for signature files to be uploaded with submissions or a clean way to attach signatures to journals that doesn't make the uninitiated go, "What is all this gobbledygook?" One-time passwords delivered with PGP encryption, perhaps?
I'm glad to see such attention to security! You guys rock. On a related note, is there any chance w
I'm afraid there isn't yet, but it is in our list of feature requests! For now, you could try using a separate account (perhaps logged in on a different browser) to keep track of those you don't wish to display.
I'm afraid there isn't yet, but it is in our list of feature requests! For now, you could try using
* Fixed: Better support for multibyte characters when truncating strings. Previously when text contained special characters like Chinese characters, it would sometimes break and display blank areas when we tried to cut text to a certain length such as for journal text summaries. For example we now tell the system to return “the first 100 characters” rather than “the first 100 bytes”.
I guess you're talking about the database here?
"
* Added: The artist’s name now appears when hovering over the chosen site logo/banner.
Not to nitpick, but it fails to work on FF 31.2.0 ESR.
~~~ Quote: * Fixed: Better support for multibyte characters when truncating strings. Previously
How does it fail? I'm using FF 33. Which icon are you using? We've detected already a bug in that and the fix will be released soon.
And about the first question, no, in this case it was the php coding when truncating strings so they'd fit in the database's field or when pulling them from them to present them in the screen.
How does it fail? I'm using FF 33. Which icon are you using? We've detected already a bug in that an
* Added: The artist’s name now appears when hovering over the chosen site logo/banner.
Can you make this toggleable on user settings? Knowing which artist make this beautyful logo is good, but I use logo to go main menu, and every time I hover over it this thing pops up. I started to got annoyed. -_-
~~~ Quote: * Added: The artist’s name now appears when hovering over the chosen site logo/banne