Jump to content

Arthmoor

Clients
  • Posts

    36
  • Joined

  • Last visited

 Content Type 

Profiles

Downloads

IPS4 Providers

Release Notes

IPS4 Guides

IPS4 Developer Documentation

Invision Community Blog

Forums

Store

Everything posted by Arthmoor

  1. I've been getting these "-200" errors ever since updating to 4.6.x and I'm pretty convinced it's due to the fact that the upload progress bars are not working. This is in turn causing the browser to lose communication with the server if the upload is large enough. If the upload takes too long then it triggers the error. This never used to be an issue with 4.5.x because the progress bars worked fine there and it didn't matter how big the file got as long as it compiled with the limits set in the ACP on the particular category.
  2. I've already tried that, but it doesn't maintain them in the order they're uploaded in for some reason. So that doesn't help unfortunately.
  3. When a file category has the "Keep previous versions" setting enabled, admins and moderators will be presented with an option during a file upload to toggle keeping the previous versions. When a regular member does this, no such option is given and they are simply told the previous copies will be archived. I filed a support ticket thinking this must have been a bug, but IPS says it's made this way intentionally and that I should file this here for consideration. So here I am. Regular members should get this option presented to them as well because not all uploaders want their older copies of things kept even when the category has the setting enabled.
  4. Yep, another downloads module issue. It would be really nice to be able to get some way to drag & drop uploaded screenshots and place them in a new order. Right now there appears to be no way to guarantee a particular order to screenshots associated with an upload. I'm sure it seems like a silly thing to want, but people uploading stuff to showcase their work often have a certain order they'd like things in.
  5. At the moment, comments and reviews on file uploads can only be enabled or disabled at the category level. So either they're off entirely for everyone, or they're on for everyone. I think this is something that would be useful to have optional controls for on each individual file upload. Some people may prefer to use the comments and reviews, others may prefer to direct things toward an actual forum topic. They might also want to decide to disable one or both of these at some future point as well. In addition, it would also be nice if a file upload had an option somewhere to point to a topic after an upload has already been submitted, and to specify one during the upload instead of having to use the topic linkage feature in the ACP to assign where they would go.
  6. In looking into this for some members who have asked to have their accounts deleted, I am surprised to find there's no native support for it in the package and no mention of this ability outside of a $20 plugin in the marketplace. Why has this not yet been made a native function of IPB itself? The desire to delete one's account from a service is becoming more and more common the more sites people realize they're on and don't want to be.
  7. FWIW I've got the same. 79 "Guest" accounts. No bots listed. It's been like this for who knows how long.
  8. I'd suggest caution - this kind of flippant attitude toward the customer base is why people seek out alternatives. Even if those alternatives aren't as robust.
  9. I'm not sure what other people are doing that makes it so broken, but in the circles I roam in, BBCode works pretty flawlessly, and so far it hasn't caused any issues at all when used in the IPB sites I frequent. I think it's pretty disingenuous to say that it's broken because IPS switched to storing posts as HTML and therefore it's always been broken. No, that just indicates to me that the implementation in IPB is broken. This sort of thing reeks of the classic "we're deprecating this feature nobody uses it anymore after we gimped it badly to make people stop using it." Whether you want to call it a war or not, it's being actively shoved aside for no good reason. Often replaced with even worse garbage like Markdown tags. Or in the case of CKEditor (which IPB outsources editing to) forcing the use of a clunky WISYWIG editor that causes way more problems than BBCode ever did.
  10. Maybe I'm just a crusty old dinosaur, but I don't get this war against BBCode being waged everywhere. Just because something is old doesn't mean it doesn't work, and BBCode "just works". It's especially useful in posting prewritten text to include formatting. It's a much larger pain in the backside to use the post editor to do that.
  11. All I can tell you is that whatever is on the form for the contact link by default doesn't work for squat. Mike John's addon has significantly slowed the flow, but it hasn't stopped it. I really think that form needs to have full spam filtering applied to it because that appears to be nearly 100% foolproof for the actual forums.
  12. Thanks, I'll give that a try. It ought to be an included feature in the package though. Seems like a pretty big oversight not to protect that form since guests can use it.
  13. Over the last couple of months our site at afkmods.com has been getting a lot of spam for various things ranging from offers to supplement advertising to x-rated material. Is there any way to get this contact form to be subject to spam filtering at all? If not, is there any chance of seeing this done in a future update?
  14. Ok, thanks. That's what I normally do is log in anonymously so that explains why it's not working. Hopefully a solution isn't too difficult to come to.
  15. I've had the Unread Content set according to this for as long as I've had the forum running: As you can see, after upgrading to 4.4.2 it is no longer displaying anything even though there are new replies to view on the forum. I'm not sure why this is the case because it worked perfectly fine right up to version 4.3.6 when set this way. Any idea why this might be or does this need to be raised with official support as a bug?
  16. Ok, thanks. Looks like more of Google's usual improper useragent sniffing.
  17. In the AdminCP there are a number of places where charts of some sort should be getting displayed. What are the requirements for this to work? All I see where they should be is the error "Your browser does not support charts" on a red bar. Is this some kind of user agent sniffing that's going on that thinks I'm using something that's incapable of rendering them?
  18. No. All local storage on the server. Those settings are both currently set to 2GB because we allow uploads up to that size and they got blocked prior to 4.3.3 if they weren't set that high. They still are, and 4.3.3 is blocking the uploads anyway.
  19. You are who again? Not staff? Then why should I accept your word that it's not an IPS issue when there's nothing at all to suggest otherwise? Given that the server operated perfectly fine under the same conditions for years running all manner of different forum packages in that time, I'm confident this is strictly an IPS issue specific to the 4.3.3 update. Something they did with that code broke this function. It's that simple. It's way too specifically centered around the 128MB marker to be anything else. Unless they're trying to get people to switch to competing products that actually work, it's in their interest to investigate this properly and fix it. I don't use Cloudflare, and yes, every upload gets all the way to 100% before failing for no reason whatsoever. Not a single log entry in any server log as to why. Which is why I'm 100% certain this isn't an issue with my server.
  20. I've already gone fishing in the logs, including tailing them all to try and spot something. There's nothing to spot. Everything worked perfectly fine on 4.3.2, for files all the way up to our limit of 2GB per upload. With 4.3.3, that no longer works. Files larger than 128MB are rejected with the cryptic and useless -200 error. Which is another beef I have. Errors thrown by this software need to be informative so that we can actually make a proper attempt at diagnosing the problem. A -200 error is literally the equivalent of "There was an error". That's absolutely useless. Given the strong evidence found via Google that only this package ever throws this error, and other packages I have on the same server uploading the same files to their own areas don't also have the same problem, it's definitely something IPS did in 4.3.3. There were an awful lot of files uploaded during that upgrade. Any one of them could be where the error actually comes from. Plus I'm clearly NOT the only one having this problem as I can see there's one other thread here I didn't notice as well. The company shirking its duties on this isn't sitting well and if there were ANY other decent package out there that supported as robust an uploads module I'd already have ditched this one in favor of it. IPB routinely fails to take responsibility for issues under their control and it's very annoying considering we're paying good money for this.
  21. It's definitely not a browser issue. I tried it in Chrome, Firefox, Edge, and IE. They all failed to upload the file. I don't see how this could be a server config issue either since I run my own server on a Linode VPS. No shared account issues. Prior to 4.3.3 the sever had exactly the same configuration since I'm on an Ubuntu LTS install. Plus the fact that all Google hits come from IPB based sites and nowhere else.
  22. We just upgraded our site to version 4.3.3 of the forum software, after which uploads larger than a certain point are no longer possible. I'm trying to upload a file into the Downloads module of about 150MB. It's a 7zip file, which we've uploaded plenty of times in the past without issue. The category for the downloads that I'm trying to put the file into has a limit of 512MB set in the permissions. PHP has the upload_max_filesize value set to 2048MB, and the post_max_size value set to 2048MB, so it shouldn't be a server error of any sort. Permissions on the Uploads and Downloads folders in the package are set to 777 as recommended, and I can even see that the forum created a new folder in Downloads for June 2018 just fine. So the software clearly has permission to write files. So I started trying to narrow this down with various sized files I could find. One file at 113MB uploads fine. Another at 130MB does not. So I'm guessing that some new 128MB restriction got introduced somewhere, but I can't find it. Nothing in the AdminCP points to this anywhere. After searching Google for the exact error in the title, I am finding it exclusively comes up for IPB installs, but the annoying thing is they go back for years and nobody ever finds a solution that I can see. They just work around it by fiddling with things until it works. Unfortunately those have also been for nothing but image files, but I'm not uploading an image. I have checked server logs, no errors of any sort are thrown. I've checked IPB's own logs, no errors are thrown there either. I've run out of places I can think to look.
  23. Getting the same problem with downloads in the "Add New Version" menu. Same kind of thing with the "Edit Details" menu in a download entry.
  24. Yes, but the license agreement you're referring to is for the site, not the individual downloads, which may have different requirements depending on who is uploading and what they're uploading.
  25. Would it be possible to add something to the downloads module to allow a user who uploads something to specify a license agreement that other people downloading have to click to agree to before they can get the file?
×
×
  • Create New...