Andre Gagnon
Forum Replies Created
-
Forum: Plugins
In reply to: [Presto Player] Conflicts with GDRP requirements!Thanks for the valueable feedback. We do have this in our backlog, I don’t have and ETA for it at the moment, but we will revisit after our current objectives.
Thanks!
Forum: Plugins
In reply to: [Presto Player] Conflicts with GDRP requirements!Thanks for all the valueable feedback. The tricky part here is there are dozens of cookie consent plugins, and adding compatibility with all of them (at least from our end) wouldn’t be possible. Perhaps if anyone on this thread could share which cookie consent banners you are using we could look into an integration, or reach out to the plugin developer to see if they can add compatibility.
Hi David!
the_title filter is supposed to always have 2 arguments. It sounds like a 3rd party plugin might be incorrectly calling this hook with only one. I would start by deactivating all other plugins, then activating each one-by-one to find the problematic one. If you find it, please let us know so we can let the developer know they need to fix it.
Forum: Plugins
In reply to: [Presto Player] Delete Database TablesTo do that, you can install Presto Player again, navigate to the settings page, and ensure “Remove data on uninstall” is checked. Then uninstall/delete the plugin. This will remove everything from Presto Player.
https://share.zight.com/7KuZk6Qp
We don’t enable this by default in case of a temporary deactivation – we wouldn’t want any data loss.
Hi There,
Thanks for reaching out. These are dynamically generated based on the webhook event, so you won’t see them in plain text (which is why you are not seeing it by simply searching the codebase). However, the plugin does not subscribe to this one specifically, as everything is handled with
surecart/purchase_created. This is preferable because an order can have many line items, so this is specific to a line item.Should you want to listen for
surecart/order_created, you will need to update your webhook on app.surecart.com to broadcast that event.For purchase_created, the webhook argument is optional, as this can fire outside of the webhook process (i.e. when a person checks out on the site).
Can you explain more what you are trying to accomplish? Perhaps we can point you in the right direction.
Hi There!
We do have plans to enhance our PayPal integration to use inline credit card fields. However, I don’t yet have a timeline for that. We are currently focused on increasing the customizability, flexibility with page builders, removing shadow dom and using a custom post type.
Any other questions, let me know.
Hi @forjador
We have definitely not forgotten about this. We are making an architectural change to our products – using a custom post type, WordPress media library, removing shadow dom, and implementing the extensible WordPress interactivity API. Once these items are done, we will be able to tackle variant images. The new architecture will make this much more flexible and extensible.
Any questions about this, please let me know.
Hi Marc,
Thanks for your reply. Yes, I understand where you are coming from. However, we are following eCommerce standards here. Shopify, WooCommerce and Stripe also function like this, for example.
What we are trying to avoid is unexpected behavior. There are many scenarios where you are purchasing, but want to provide a different address or other information:
- Purchasing a gift for someone.
- Purchasing on behalf of a company.
- Having multiple addresses (home, work, P.O. Box etc.)
If the address were automatically updated, it could have serious unintended consequences. For example, if you have a subscription, we should not automatically update those as we do not know the reason for the address change. You may accidentally send your own items to your boss, friend, or the wrong address.
This is why eCommerce platforms take a more explicit, declarative approach. If a customer were to move to another city, they would simply update their address in the customer dashboard.
Please let me know if this makes sense.
Andre
Forum: Reviews
In reply to: [Presto Player] Unfortunately does not work with multsiteHi There!
Thanks for reaching out. Can you explain the specific issues you are having with multisite? Or is this related to Pro licensing?
Perhaps there is something amiss. Can you tell me what theme you are using ? Did you try refreshing the page?
This definitely sounds like you have a setting somewhere that is restricting the WordPress REST api to logged in users only. You will want to disable that setting, which may be in a security plugin you have installed.
All of our REST endpoints follow best security practices, so you don’t need to turn this setting on, otherwise non WP users will not be able to use your shop.
- This reply was modified 2 years, 3 months ago by Andre Gagnon.
Forum: Plugins
In reply to: [Presto Player] iOS Safari Fullscreen ProblemsIt’s a tough decision @mirrorofzen.
On the one hand I do agree with you. On the other, I think customers would be surprised if many of the presto player features were not working on mobile devices with fullscreen. We decided that we were okay with the tradeoff of the top bar being visible, and controls being visible when minified, if that meant keeping the same experience across devices. But perhaps we will add a global setting for this so that someone could decide the other way.
I will resolve this for now, but any other thoughts, please let me know.
Forum: Plugins
In reply to: [Presto Player] iOS Safari Fullscreen ProblemsIt’s a great question @mirrorfzen. What bunny.net is doing here is switching to the native player for fullscreen. We can do this too, but that means many specific presto player features are no longer available, including overlays, chapters, watermarks, searchable captions etc.
However, should you want to switch this functionality, you can do so with a code snippet:
add_action( 'wp_footer', function () { ?> <script> jQuery(function() { if (!wp || !wp.hooks) return; wp.hooks.addFilter('presto.playerSettings', 'ios-native-fullscreen', function(settings) { settings.fullscreen = { enabled: true, fallback: true, iosNative: true, container: null }; return settings; }); }); </script> <?php } );And make sure playinline is on. Just be aware of the tradeoffs that the native player is being used on fullscreen mode, whereas Presto Player is being used on inline.
It may be that the purchase_created hook is firing twice. Sometimes this can happen so that we can run integrations on sites locally, or otherwise unaccessible to webhooks. Can you add this condition at the front? This will ensure it only runs for the webhook context:
add_action( 'surecart/purchase_created', 'purchaseCreated', 10, 2 ); function purchaseCreated( $purchase, $webhook_data = [] ) { if ( empty( $webhook_data['id'] ) ) { return; } $wp_user = $purchase->getUser(); $boosts = (int) get_field( 'field_65baaaee56f72', 'user_' . $wp_user->ID ); $boosts++; update_field( 'field_65baaaee56f72', $boosts, 'user_' . $wp_user->ID ); error_log( 'Purchase Created #' . $boosts ); };Forum: Plugins
In reply to: [Presto Player] iOS Safari Fullscreen ProblemsThanks for bringing this issue back up. The reason this issue is still not addressed is due to restrictions on iOS, not due to lack of care about the issue. Let me explain a little more:
- Full Screen Top Bar: iOS does not have a fullscreen API, so we are accomplishing this through css. This means we cannot programmatically hide the top bar in that fashion, so this is not currently possible.
- Turning off playinline shows double controlsThis is because we are using the native iOS player here, instead of ours. That’s what turning off playinline does. The trade-off here, is that iOS locks this so that we don’t have a way to turn off controls . The reason this issue has not changed is that it is impossible to solve due to iOS restrictions.
However, iOS is very close to offering a fullscreen API, which would solve both issues. However, it is not yet released, and keep in mind this will only be supported in newer versions of iOS.
I hope this helps – I don’t want you to think that we don’t care about this issue, it’s that it’s not currently solvable.
Any questions, let me know.