giangel84
Forum Replies Created
-
Thank you for your attention.
- This reply was modified 3 months ago by giangel84.
Hi @frankremmy , thanks for the reply.
This is not an environment-specific issue. It’s a code-level bug that can be verified by reading the source directly:
- The view template
views/meta-box/coupon_channel_visibility.phpaccesses$this->is_setup_completeat line 40 - The method
CouponChannelVisibilityMetaBox::get_view_context()insrc/Admin/MetaBox/CouponChannelVisibilityMetaBox.phpnever includesis_setup_completein the context array it passes to the view
This means the property is always missing, regardless of the environment. The
PHPView::__get()magic method throws aViewExceptionwhen it can’t find a property in the context array — which is exactly what happens here.If the page loads for you without errors, it’s likely because:
- The meta box is not being registered (e.g. Merchant Center is not connected, so
can_register()returns false) - Or PHP error reporting is suppressed on your test environment
The fix is a one-line addition to
get_view_context():'is_setup_complete' => $this->merchant_center->is_setup_complete(),I’ve already opened a GitHub issue with the full analysis and fix. I’d appreciate it if the development team could review the actual code path I described above rather than treating this as a configuration issue.
However, this is the WC Status report, as required: https://pastebin.com/mbkLqSBLThanks.
@danis039 I can confirm that this pull request will also fix the “Use Optimized Files” and “Destroy All Optimization Data” (already tested).
Please wait for the team update ofsrc/utility.cls.php, you can check the repo here.
After that you’ll able to try the new Development version, by following these instructions.@litetim Thank you for your attention! 😊
Best regards.
@binarywc — jumping in as a third party:
You’re asking @giuse for a very specific remediation (hand-written SQL) while simultaneously dismissing the steps he’s pointing you to (debug log + checking/removing the mu-plugin) which are actually the correct way to diagnose and stop 502/503/fatal issues.
A couple of factual points:
- You renamed the plugin folder via FTP (“.hold”). That means WordPress will not load the plugin in the normal way, and the plugin’s uninstall routine also won’t run. In that situation, the only FDP-related code that can still execute is something that loads outside the normal plugin loader (e.g. a must-use plugin file). That’s exactly why Jose keeps mentioning
wp-content/mu-plugins/eos-deactivate-plugins.phpand enablingwp-content/debug.log. - 502/503 are not “WordPress errors” by themselves — they’re gateway/service failures. Claiming “the plugin caused 502/503” without providing any supporting evidence (PHP-FPM/nginx/apache error log line, timestamp, stack trace, WP debug.log excerpt) is basically impossible to validate in a support forum. The normal (and expected) thing in WordPress support is: show the logs or at least the exact fatal message so people can help you precisely.
- It’s also not reasonable to demand a custom SQL procedure from a volunteer maintainer when the standard, safe procedure is another and already provided: restore normal state → deactivate/delete properly → check logs if the site is crashing. Jose already described the safe path and the troubleshooting steps.
If you want this to be productive, here’s what would move the thread forward in 5 minutes:
- Post one relevant log line from your host for a 502/503 request (nginx/apache + PHP-FPM if available) with a timestamp.
- Enable WP debug logging and paste the relevant snippet from
wp-content/debug.log. - Confirm whether
wp-content/mu-plugins/exists and whether any FDP file is present there (that’s the only FDP component that could still run after “.hold”).
Until you provide that, nobody (plugin author included) can honestly do more than guess.
Same issue for me. Fixed with a rollback to the previous version.
@abrarfaisal87 Thank you, this could be a solution but it’s applicable only when you have a single field to treat as boolean…otherwise you need to build a lot of conditions.
I hope you could take this case as a feature request, in order to improve your plugin in the next future.
Thank you.I have a similar problem: When the order is set to “processing” the number of stocks of the ordered product does not decrease. It decrease only when the order status change to “completed”.
This is affecting the normal orders and not “combined orders”. I managed this issue with this code:add_filter('woocommerce_can_reduce_order_stock', function($can_reduce, $order) {
if ($order instanceof WC_Order) {
$status = $order->get_status();
if (in_array($status, ['processing', 'completed'])) {
return true;
}
}
return $can_reduce;
}, 10, 2);If I deactivate the plugin, I doesn’t need for the code above.
Forum: Plugins
In reply to: [ShopMagic - email automation] Re-send email functionGood morning,
Thank you for your quick and thoughtful reply. I’m glad to hear you find the idea useful, and I really appreciate you saving it for a future ShopMagic release. I look forward to hearing from you when the “Resend” feature becomes available.
Thanks again for your time and attention!
Best regards,
GianlucaHello Krystian,
Thank you for your reply and for looking into the issue. However, after further testing we believe that the problem lies with the WooCommerce PayPal Payments plugin itself.
After replacing it with an alternative (Payment Gateway for PayPal on WooCommerce), our site processed six orders via PayPal in the last 24 hours—all completed successfully without the order status ever switching to “Failed.” and without any warnings in the logs.
When we tried to reactivate WooCommerce PayPal Payments plugin afterward the problem immediately reappeared.
This consistent behavior with the alternative plugin indicates that the issue is specific to the WooCommerce PayPal Payments plugin, rather than due to any third-party interference or modifications of fees/shipping after checkout, and confirms also that the problem is definitely occurring during the phase where the order total is updated (likely involving shipping fees) via the PATCH request, and it appears to be handled incorrectly by the plugin.Here you can find the full website status report. (the link will be available for the next 48h).
Hope this can help you.Since PayPal is a crucial payment gateway for our business and the alternative plugin works flawlessly, we will be maintaining the alternative solution moving forward.
Thank you for your attention and support.
Best regards,
GianlucaHello @inpsydekrystian,
Thank you for your detailed response and for investigating the logs. However, I’d like to clarify some critical points regarding our checkout flow:
- Pre-filled Checkout Data:
Customers always reach the checkout page with all fields pre-filled and with the total—including shipping costs—accurately calculated from the start. There is no opportunity for the customer to change any details once they are transferred to PayPal. - Unexpected Order Update:
The log indicates that an order is initially created with a total of €56.90, which is then updated via a PATCH request to €63.80. This update is occurring without any customer intervention. In our flow, the shipping cost is already included at checkout, so modifying the total after customer approval is not expected. - Order Status Transition to Failed:
It is concerning that the plugin marks the order as “Failed” during the payment process, which in turn triggers a failed order email to the customer—even though in some cases the order eventually goes through successfully. This inconsistency suggests that the plugin may be erroneously handling the order update, leading to an unauthorized change in the total that triggers PayPal’s protection mechanism (i.e., the “Payer action required, possibly overcharge” response).
Given this, it appears that the issue is not related to any customer modifications or additional fees being intentionally added at checkout. Instead, the plugin itself seems to be updating the order total improperly. Could you please re-examine the logic behind the PATCH request? Ideally, the final total (including shipping) should be locked in before the customer is redirected to PayPal to ensure the amount remains consistent throughout the transaction.
We appreciate your assistance in resolving this critical issue and look forward to your further guidance.
Best regards,
GianlucaHi,
Thanks for the quick reply!Deleted reply due to double input.
Please read the correct one below.- This reply was modified 1 year, 1 month ago by giangel84. Reason: Deleted reply due to double input
Forum: Plugins
In reply to: [Shipment Tracking DDT for WooCommerce] Is the plugin fully HPOS compatible?Hi @titsmaker, thank you for your feedback.
I have understood your suggestions, and they are definitely helpful for improvement.
I’ve added your considerations to the to-do list, and in the next release of the plugin, you will find options to hide the tracking columns in both the backend and frontend.I’m aware that there are no similar free plugins for WooCommerce. This project was born from multiple requests from some of my clients, and I decided to publish the plugin for free in the official repository so that everyone could benefit from it.
In the near future, other exciting features are planned, such as the ability to add/remove shipping methods (couriers) and the option to automate the creation of tracking links for individual couriers based on the provided tracking information.
Thank you again for your input!
Forum: Plugins
In reply to: [Shipment Tracking DDT for WooCommerce] Is the plugin fully HPOS compatible?Hi @titsmaker I can confirm the plugin doesn’t work with legacy mode.
If your WooCommerce is using Legacy mode, you must switch to HPOS mode first; only then can you use the plugin.
When I built this plugin, HPOS was already available for WC as the default option. I believe that everyone using WC today should already be using HPOS. That’s why I never planned the development of the plugin to be compatible with legacy installations. It wouldn’t make sense on the verge of 2025.
Do you think it would be useful to make it compatible with Legacy mode?
