IPCommerceFan

Excellent, thanks @Marc Stridgen. Yeah the concern was primarily for the content since I generally use stock themes. 👍

If a site has clubs/pages meticulously set up and full of content, will it all carry over when it comes time to upgrade to V5?

I know I'm reaching for the stars here, but I'd like to see the ability to sell custom software via Commerce and serve it via Downloads. We do this already, but its clunky. Currently, our setup is something like: We create packages in Commerce and assign some custom fields to each When a customer wants to buy a package, they fill out the custom fields and we write the software to their specifications We then upload the custom software to a Download page, and change the owner to the customers account. Using a custom plugin, we disable the ability to edit or delete the download (things the owner of a file can normally do), and make it so each customer can only see their own files when they visit the Download page. This essentially gives us a secure download portal for all of our customers, but it'd be great if such functionality were streamlined and given the "IPS" treatment for V5!

If you mean Stripe isn't appearing as a payment method at checkout, remember to set it as an available method on each package in the store you wish to use it for.

This sounds like a net positive for developers. Two primary issues (based on observation) have always been how long it takes for IPS to approve an app, and the fact IPS takes a cut. This knocks them both out, so it seems like a win to me. I wonder though, since the Marketplace is essentially a portal for paid downloads, will this change affect the need/desire for IPS to continue developing/maintaining the Downloads or Commerce apps in the long run (V5)?

I have great disdain for Safari. lol We recently implemented some dynamic dropdowns which utilize jquery to populate the fields via ajax calls to a php script. For whatever reason, they work perfectly on windows, linux, and android using a variety of browsers, and even with iPad and iPhone, but NOT with the latest version of Safari for iMac and Macbook. I'm sure I'll figure it out, but it just goes to show Apple implements things quite differently from everyone else (even themselves! lol)

In my specific case, Facebook requested credentials to be able to see how the Facebook Connect app is using client data. This involves giving them access to the Login & Registration --> View and Manage Login Methods area - and ONLY that area. When testing the login though, I noticed the "Log Out All Users" button was still available. I'd really rather not have a Facebook agent clicking that button maliciously or by accident, so I can't comply with their request to log in and review the settings. (I'm currently waiting to see if they complain about it) More broadly though, I can imagine anyone with a need to delegate specific admin tasks would benefit from blocking this button. e.g. someone who processes reports, invoices, 3rd party add-ons (like Drip Campaigns), doesn't need the ability to log all users out.

I'd like to restrict a particular admin from being able to access the "Log Out All Users" button, however it appears there is no built-in way to do this. I'd suggest adding this to the list of things we can restrict in a future version. 👍

Thanks for the heads up!

I really would rather get to the bottom of it if possible, so yes lets open up a ticket. Thanks!

I dug around some more, and it was doing this even when we were on 4.6.10. It seems it only happens with non-US addresses, so its a rather fringe issue for us. If there is no "low hanging fruit" solution to this, I'm OK just living with it until we switch to Stripe.

This may be coincidence, but we upgraded from 4.6.10 to 4.7.8 recently, and ran into this again using the Braintree PayPal integration: The difference here is: I've verified the fix that was applied last time was retained. PayPal orders have been flowing just fine since the upgrade. The billing address that threw this error is in Mexico. In any case, I've updated my site access info, and the Transaction # in question is 30656. I'll also just state that this was duly noted!

Yup I'm figuring maybe the initial encoding is defaulting to some format the REST API on the php side isn't interpreting correctly. Nice, I have a co-worker who keeps telling me I should learn C#, then F# since they're pretty much ubiquitous. I've thus far ignored him and continue on my merry way with in php/mysql-land. lol

I don't know C#, but I would try sending a text field for troubleshooting purposes instead of trying to get an image to work. If it sends over garbled text, then you may discover it is sending the text in the wrong encoding and can course-correct from there. I ran into this recently with a Selenum script, where I used javascripts btoa() function to base64 encode some text, but when I received it on the php side, it was a bunch of gobbledegook. In my case I had to say: base64_decode(urlencode($_GET['stuff'])); instead of what I previously had: $html = base64_decode($_GET['calidpanel']); urlencode did the job of "un-garbling" the text before base64 decoding it. For your case, Google led me to this result, which you may find useful: https://stackoverflow.com/questions/46093210/c-sharp-version-of-the-javascript-function-btoa Specifically:

Will do! I noticed the release notes mentioned: I took that to mean Packages, but maybe I misread it and it really means all product-related pages. Can you confirm it indeed covers Package Groups? Thanks for taking care of this!