IPS Management
  • Content count

  • Joined

  • Last visited

About Matt

  • Rank
    Chief Software Architect

Contact Methods

IPS Marketplace

  • Resources Contributor
    Total file submissions: 1

Profile Information

  • Gender
  • Location
    Cambs, UK!
  • Interests

Recent Profile Visitors

219,575 profile views
  1. I am not opposed to this.
  2. Hi Jack, I've just replied to your ticket, but as you posted this publicly, I feel it's worth replying here too. I was just asking for more information so I could make the correct fix. I wasn't trying to be difficult. In either case, you'll have a fix this morning.
  3. Hi all, Thanks for pitching in, we do appreciate your input. Our aim here isn't to cripple anyone's enthusiasm for helping us out by reporting bugs, neither is to try and diminish the importance of the bug tracker. What we're trying to do is find a way to streamline things a bit. During the course of a day, we probably fix a good few legitimate bugs reported via tickets. This means that while it looks like the tracker is sitting dormant, it is possible and indeed likely that many things are fixed but via tickets rather than the bug report. What we tend to do is work in cycles. We always try and find a balance between stabilising things and adding cool new things. When we do a stabilisation cycle, we will go through the tracker, which we're currently doing now if you took a look. You'll see we've created a few new categories to help key staff members order issues they will be responsible for. We've moved a lot of more complex engineering bugs that require significant work to our internal tracker so we can discuss how and when to resolve these issues. Of course, if it was a critical issue, then it would have been fixed by now because show stopping bugs tend to get our attention. As always, if you have a critical issue then a ticket is always the first port of call. That's what you're paying support for. I'm currently managing our top support tier and I'm committing bug fixes daily. So, to recap: we appreciate all your input. We love that you are enthusiastic and want to help us and we're not trying to diminish the importance of a tracker.
  4. "Sunset" I think we decided?
  5. Actually, it's a whole new system to highlight specific groups' posts and comments which is configurable per theme via the theme settings.
  6. As IPS 4.1 matures, we'll be switching gears to devoting more time in the bug tracker. One must keep in mind that we make dozens of bug fixes and changes a day based on tickets sent to us, so please don't think that we're neglecting the software.
  7. You can via editing the CSS, yes.
  8. Yep, @Mark Hhas a very busy 3.x forum that he upgrades as part of the QA procedure.
  9. I would do this: 1) Submit a bug report. Note it is a dev site. 2) If the developer working the report wants a ticket, submit a ticket quoting the bug report ID in the title of the ticket and re-iterate in the body of the support request that developer Z (Andy, Matt, etc) requested you submit a ticket. 3) Reply to the bug report saying that you've submitted a ticket and add the ticket number.
  10. I'm going to go ahead and lock this. RPG, we often butt heads in the bug tracker, and I don't think arguing semantics is really helping anyone. Feel free to contact me via a support ticket or PM if you want to talk or push for a code change because of feedback you wish to give.
  11. The best solution I can think of right now is that if you encounter a bug on a dev copy of your site, go and file that bug report and note it's a dev install. A developer will triage the report and if it requires more investigation, they'll ask for a ticket for access to that dev installation (assuming access is possible, otherwise this whole discussion is moot). We've done this a lot in the past. I consider a bug report different from a support request. We appreciate people taking the time to test and report issues, so we'll happily look at your dev installs if it fixes an issue we can't reproduce and has great impact on the suite.
  12. I have thought about beta releases again, but that wasn't always a perfect system in the past. That said, I think the QA needs for a release than has 10 bug fixes and no feature changes is different from a release that has 400 bug fixes and a dozen new things. I think that's what we need to focus on moving forwards.
  13. Hi all, Thanks for all your feedback. We're painfully aware of when things go wrong. It doesn't go unnoticed internally. We're made a lot of progress in the past year with the aim of making releases more stable and the upgrades smoother. We've implemented dedicated QA testing and "auto" upgrades to make the upgrades simpler to apply. 4.1.12 was a huge release with over 400 bug fixes. Unfortunately several issues escaped us and we had to push out a release to resolve those issues. The failure rate was about 0.5% - it's just that 0.5% affected a lot of people. We're having a discussion internally about how to improve; including revamping QA and introducing automated testing and so on. It's always a balance finding time and talent to do those things when the code base is constantly shifting to accommodate performance improvements, feature additions and bug fixes. But we always learn and strive to improve. I'd love to hear your thoughts on how to improve the process (please make them realistic though! We'd love to employ 20 QA testers on a permanent basis but it would mean a hike in license costs to do that ).
  14. is not showing under available downloads?


    This is a maintenance release to resolve the following issues: Permission matrix can show incorrect permissions when using the Member > Group permission tool. Using Authorize.Net Payment Gateway may result in an error. A logged in member without a valid timezone set will trigger exceptions any time another members age is checked. Where the upgrader can result in a fatal error due to an invalid class stored for a Pages record comment. An upgrade error where reports are loaded for Pages databases that no longer exist. Orphaned comments trigger an exception when search index is rebuilding. An exception can occur continued upgrades: DateTime::setTimestamp() expects parameter 1 to be long, object given. Recursion can occur if the core_log table doesn't exist yet (as happens during auto upgrade). An issue where importing a theme can break CSS. MySQL strict mode upgrade to 4.1.12 can fail. Installing a new plugin via the ACP can fail. As part of our ongoing internal security audit, this release also improves security in the following areas: Possible XSS in the "hovercard" system. Further hardening to the insecure file upload code.