Jump to content
Invision Community

Lindy

IPS Management
  • Content count

    3,882
  • Joined

  • Last visited

  • Days Won

    237

Lindy last won the day on September 22

Lindy had the most liked content!

About Lindy

  • Rank
    That Lindy Character

Contact Methods

Profile Information

  • Gender
    Male
  • Location
    Forest, VA

Recent Profile Visitors

101,647 profile views
  1. IPS 4.2 observations

    Invoices are necessary to serve the varying needs of Commerce and its clients - I'm unsure where you've been shopping where you don't deal with invoices in some form -- some may call them "orders" but ultimately, they're invoices. They can be transparent to the client in Commerce as well. If you want to allow no grace period and change settings to focus more on instant transactions and you needn't mess with expirations, etc. Please understand, it's an e-commerce product. The entire system relies on some form of valid currency and changing it to use a unapproved currency would be an expansive undertaking, for a rather niche use-case. If you're trying to sell points, you could perhaps consider the account credit feature, a custom field, or similar? It's not that we're trying to just make it simple for you in terms of knowing where to deliver the product. If you pay via credit card with PayPal, an address is required. Most merchant processors - auth.net, etc. are going to require an address. 2checkout, at last check, requires one. If you're handling physical products, you're most likely supposed to be collecting tax based on the customer's location (which you wouldn't know, if you didn't get their location), fraud screening won't work properly, fraud rules in Commerce won't work properly. I understand you have an edge case... from my experience, not requiring an address for physical products is, by far, the exception, not the norm. It may seem "simple" to just allow people to do whatever they please with the product with no engineering limitations at all, but we do have an obligation to maintain the integrity of the product, keep support minimal and try to avoid issues the client may not have considered (ie: "I don't require addresses and I've gotten 30 chargebacks!", "I don't require addresses and now the revenue service is auditing me.", "I don't require addresses and I can't get PayPal to work if the user is using a credit card.") etc. We allow you to ignore all of that for non-physical products if you really, really want to - but the extremely limited cases where you'd even be able to sell a physical product online without knowing who your client is at all, do not warrant the potential ramifications. Nonetheless, I will investigate the ability to have a power user setting - no promises. In the interim, if it's a sticking point for you, then I suppose you could try (I've not tested) editing the language strings for the address fields and instruct them to put "n/a" if they don't want to provide an address if you're ok with that, you're using a payment processor that doesn't require addresses and you're not using fraud rules. If you'd like to PM me, I'd be happy to review your shop and make suggestions. Commerce shouldn't be difficult for end-users, if you can articulate further feedback, we would be happy to review. I like this idea a lot and will log it internally. Subscriptions is, by far, the most common usage scenario for Commerce, so I would agree making it easier to add and manage would make total sense. On it! @Colonel_mortis - I just want you to know, why perhaps irrelevant now, we've not ignored your feedback on PayPal billing agreements. We have been working with PayPal and have made changes to the gateway for agreements in 4.3. As for the original invoice concern - are we good on that?
  2. IPS 4.2 observations

    To address the various Commerce discussions related to subscriptions: I like simple solutions and we're leery of adding pages of potentially confusing settings to accommodate all possible usage scenarios - Admin A sells tiered subscriptions and only wants subscriptions in a group to be unique because he's fearful of a user purchasing multiple subscriptions at once. Admin B has an automotive repair support community and sells subscriptions based on what vehicles they need service info on and he WANTS people to be able to purchase "Chrysler, Ford and/or GM" subscriptions simultaneously in the "Domestic Vehicles" group. If Admin A's subscriptions expire, he wants them to buy a new one. Admin B wants them to be able to renew past invoices and NOT buy new subscriptions because his bookkeeping and analytic requirements dictate he needs to isolate new sales vs renewals. Admin C uses subscriptions to sell recurring online game credits that can stack, so his needs are also different than Admin A and B. Admin D wants to prevent people from ordering multiple subscriptions at initial checkout, but wants them to later be able to order simultaneous subscriptions once they're a client. Invision makes an attempt to specifically accommodate Admins A-D and Admin E comes along that wants to simply sell a single premium subscription and has difficulty because there's a series of what-if complications they need to traverse through. I hope the above better explains why things are done for what you may consider "no good reason." As you know, users tend to get focused on their specific needs - totally understandable, we don't expect you to consider every possible angle, it's your needs that you should be most concerned about. Our job is to parse feedback and incorporate the simplest solution that benefits the most. On the simplest level, if your issue with selling subscriptions is people can't renew from expired invoices -- the solution is quite simple - don't expire the invoices. If you don't have a specific need, it's not a requirement and you can in fact disable that today. That seems to solve the brunt of the issue, which as best as I can tell are: you've set invoices to expire and also enabled one-purchase protection, so they can't pay expired invoices and they can't purchase a product they've already purchased. Both of these concerns are admin configured and changing only one of them resolves the issue at a basic level. If there are suggested tweaks that can be further articulated, I'm happy to act upon those internally. An example would be: a user tries to purchase a subscription that has protection enabled, we can modify that "error" to be more friendly and refer them to their purchases page, or even, a pending renewal invoice if one exists. Another potential solution to the expired invoice concern is to continue the global expiration time, but allow that to be overridden on a per-package level. So, for certain subscriptions, you may opt to allow the client to renew 10 years after it expired. Others, you may only want 30 days. Finally, it may be a good idea to allow for product groups (categories) to have the unique/one purchase protection for those that desire it. In short: we want you to be able to use the product to be successful. We are happy to make tweaks and try to accommodate various use-cases without overcomplicating the product. Again, the best solutions are often the simplest. If you agree, we'll proceed with further internal discussions and try to get these ideas materialized.
  3. IPS 4.2 backwards compatibility

    I had a look and as suspected, there's been some rather significant modifications to templates. Forum row, the global template, userbar, navbar, breadcrumb, sidebar, etc. CSS files were directly modified as well instead of perusing custom.css (though that was used extensively as well.) It's frankly a bit of a disaster I'm not able to recover - as a quick courtesy, I even tried creating a new theme and applying just CSS changes, but the layout was far more engrained in template changes than it should have been. Unfortunately, you will essentially need a new theme, done properly. Most of the customizations done did not need custom template changes and could have been accomplished via css alone. I could not fix your header issue for you, but I did add reactions to your topic view. I would advise enlisting the assistance of a reputable third party designer.
  4. IPS 4.2 backwards compatibility

    No problem! These things are tricky as our support team are not developers and our developer resources are scarce in terms of client-driven assistance. I appreciate that you're willing to pay for a service - I would be happy to recommend a third party to assist. As a courtesy, however, I will take a quick look at your ticket and see if there were in fact custom template changes and advise on what you can do.
  5. IPS 4.2 backwards compatibility

    @steadyoptions I do understand the frustration and have been on the other side of this equation as well using different software. Your expectations, unfortunately, are simply not reasonable. Your custom code caused the issue to your site; that is not a "fault" of the software. We introduced a new feature and because you've modified content templates, the upgrade was unable to determine what exactly you've done to your templates and thus, the code for reactions was likely not introduced to your community. Demanding your customizations be made compatible with future releases is akin to telling Ford that you've put your own custom spoiler on your vehicle and the next generation of that model better have the same size rear decklid so the spoiler will transfer and fit - or they have to make you a new spoiler. It just doesn't work that way. They don't build vehicles around your spoiler and while we make every effort to retain backwards compatibility when feasible, we can not develop software around your customizations. We deeply encourage you to make as many changes as possible within the custom.css framework, which is retained on upgrade and we try very hard to avoid tampering with. When you start editing core templates - I'm sorry to say, it's up to you to maintain the changes you've made. We do try to provide a resource to make you aware of changes you will need to make: https://invisioncommunity.com/index.php?app=core&module=system&controller=plugins&do=diff Beyond that, it may be a good idea to use one of our many talented third party theme designers who are generally quite good about keeping their themes up to date. I'm sorry for your frustration and hope you're able to restore the missing functionality to your community. Thank you for your feedback.
  6. Clubs - a different use

    That's great! Thanks for sharing, Adlago - we love to see creative uses for Invision Community.
  7. IPS 4.2 observations

    Thanks for the feedback, John. 1. We have this on our roadmap already and agree it's necessary. 2. I can tell you from experience overseeing support, allowing users to repeatedly create new subscriptions instead of renewing expired purchases creates a lot of housekeeping issues and confusion, from PayPal billing agreements and beyond. In such cases where this isn't a concern, I'd recommend turning the single purchase limit off. I've not seen double orders as a technical issue in Invision Community 4.2. We will, of course, monitor this for further feedback and make any reconsiderations as necessary. 3. Great idea - this drives me a bit batty as well. I've put it on our roadmap. Thanks again.
  8. Gallery Improvements

    Most of those should be fairly straight forward. Thanks for the feedback.
  9. Don't care for the new look

    It's possible (and I'd very much like to) do and release theme modifications, but our own corporate theme is for our site only. We appreciate your interest though!
  10. Significant drop in GA pageviews

    The placement of the GA code would only be an issue in cases where your users aren't fully loading the page before going to another page. Nonetheless, GA is asynchronous these days so it should no longer slow the page being in the <head> section of the page - I'll check into having it moved there. Now, with that said, the experts largely agree - you should not hang your hat on the accuracy of Google Analytics. If your site is larger, you may be encountering sampling. There's also the fact that there's imply less pages in modern web applications than there used to be and much is fired via Ajax. We do try to account for this the best we can via virtual pageviews, but there are still simply less pages. Finally, millions of people use ad blockers and disable tracking. These visitors will not be accounted for at all in your Google Analytics pageview counts. Depending on the nature of your site, this could reduce the number of pageviews you have by 10-75%+ Tech, security and and similar user-savvy websites especially will have incredibly skewed numbers because many on those types of sites are more apt to employ ad blockers and/or disable tracking. More important than raw pageviews is engagement - I'd suggest focusing on that. Check your community participation stats -- registration, content submissions, etc.
  11. Whats next on the docket?

    2019? We'll be on IPS 7.2 by then! I'm kidding, but 4.3 is underway and we should start talking about it in coming weeks. Without too many spoilers, the focus for 4.3 is largely engineering and refinement. Gallery, clubs, search, etc.
  12. Inconsistent theme HTML

    It's in the works and we'll address it as soon as we can.
  13. I've logged a feature request to get "banned" added to: I have no ETA, however.
  14. Alternate contacts should be able to run the auto upgrader. If that's not working for one of your alt contacts, please submit a ticket and specify which one and we'll take a look. Ensure that the contact is assigned to the license in the client area with support privileges.
×