Steven Ray

Forum Replies Created

Viewing 15 replies - 1 through 15 (of 84 total)
1 2 3 4 5 6
  • Forum: Plugins
    In reply to: [Admin Custom Login] 3.6.3 update introduces a critical bug
    Thread Starter Steven Ray

    (@steveneray)

    3 months, 3 weeks ago

    @zanimul, Weblizar refuses to provide proper support, so I will.

    I’ve identified this bug. The problem is in init.php lines 12-25 – when the “Force Redirect” feature is enabled but the redirect URL field is empty or invalid, the plugin redirects to wp-login.php by default.

    Quick fix: Go to Admin Custom Login → Login Form Settings, find “Forcefully Redirect” and set it to No. If you need this feature, make sure you have a valid full URL (including https://) in the redirect field.

    Manual code fix: If you want to patch it yourself, open init.php and find this around line 17-21:

    php

    if ( ! is_user_logged_in() ) {
    $login_page  = unserialize( get_option( 'Admin_custome_login_login' ) );
    $redirectURL = esc_url( $login_page['login_force_redirect_url'] );
    wp_redirect( $redirectURL, 302 );
    exit();
}

    Replace it with:

    php

    if ( ! is_user_logged_in() ) {
    $login_page = unserialize( get_option( 'Admin_custome_login_login' ) );
    if ( empty( $login_page['login_force_redirect_url'] ) ) {
        return;
    }
    $redirectURL = esc_url( $login_page['login_force_redirect_url'] );
    if ( empty( $redirectURL ) || strpos( $redirectURL, 'wp-login.php' ) !== false ) {
        return;
    }
    wp_redirect( $redirectURL, 302 );
    exit();
}

    This prevents the redirect when the URL is empty or invalid.

    Forum: Plugins
    In reply to: [WooCommerce] Fatal error, version 10.5.0
    Steven Ray

    (@steveneray)

    3 months, 4 weeks ago

    @tunyk, @romancc, @saivutukuru,

    I hit the same bug. It’s a filename mismatch in WooCommerce 10.5.0. The file class-wp-rest-abilities-init.php at line 25 requires class-wp-rest-abilities-run-controller.php, but the actual file is named class-wp-rest-abilities-v1-run-controller.php. To fix it, edit wp-content/plugins/woocommerce/vendor/wordpress/abilities-api/includes/rest-api/class-wp-rest-abilities-init.php line 25 and change class-wp-rest-abilities-run-controller.php to class-wp-rest-abilities-v1-run-controller.php or wait out the Automattic patch.

    Forum: Plugins
    In reply to: [WooCommerce] Critical issue: Add to Cart broken in WooCommerce 10.5.0
    Steven Ray

    (@steveneray)

    3 months, 4 weeks ago

    @ricardoaraujo330,

    If JS fails to load or encounters an error on your site, the button stays disabled. Check your browser console for JavaScript errors — a theme or plugin conflict may be preventing WooCommerce’s scripts from executing. Also, if you’re using a caching plugin that combines, minifies, or defers JavaScript, try excluding WooCommerce scripts from those optimizations. A combined or deferred JS file could prevent the re-enable script from running in the expected order.

    @valuemailer,

    I hit the same bug. It’s a filename mismatch in WooCommerce 10.5.0. The file class-wp-rest-abilities-init.php at line 25 requires class-wp-rest-abilities-run-controller.php, but the actual file is named class-wp-rest-abilities-v1-run-controller.php. To fix it, edit wp-content/plugins/woocommerce/vendor/wordpress/abilities-api/includes/rest-api/class-wp-rest-abilities-init.php line 25 and change class-wp-rest-abilities-run-controller.php to class-wp-rest-abilities-v1-run-controller.php or wait out the Automattic patch.

    Forum: Plugins
    In reply to: [Product Code for WooCommerce] Used for bin number – display issue
    Plugin Author Steven Ray

    (@steveneray)

    4 months, 3 weeks ago

    Thanks @lencw,

    This is a separate bug from the order confirmation issue – thanks for the thorough testing.

    For variable products, the plugin stores product codes on each variation, not the parent product. The template was checking !empty($value_second) before creating the HTML container, but it was reading the parent product’s value, which was empty. So the container never existed for the JavaScript to update when you select a variation.

    The fix allows variable products to create the container regardless of whether the parent has a value. The JavaScript then populates it via AJAX when a variation is selected. The fix is available in version 1.5.11.

    We apologize for the incomplete testing on this release – the assistant developer rushed these features out without properly verifying all option combinations. We wish WordPress offered a support sandbox for consensual beta testing with willing users who are eager to help. It would catch issues like this before public release, to avoid several updates in a row.

    We appreciate you taking the time to test thoroughly and report back. Please leave feedback on the plugin!

    @steveneray

    Forum: Plugins
    In reply to: [Product Code for WooCommerce] Used for bin number – display issue
    Plugin Author Steven Ray

    (@steveneray)

    4 months, 3 weeks ago

    Thanks @lencw, for catching this bug and providing the HTML snippet – that helped pinpoint the issue.

    The problem was in how the woocommerce_order_item_get_formatted_meta_data filter was implemented. When WooCommerce displays order item meta on the confirmation page, it passes an already-populated $formatted_meta array through this filter. The original code simply returned that array unchanged when the hide option was enabled, but the product code entries were already present in the array.

    The fix now iterates through $formatted_meta and unsets entries matching either the internal field names (_product_code, _product_code_second) or your custom Field Title label (“Bin”). The meta is stored using the label as the key, which is why matching on the internal field name alone wasn’t catching it.

    This is included in the 1.5.10 update just uploaded.

    Forum: Plugins
    In reply to: [Product Code for WooCommerce] Used for bin number – display issue
    Plugin Author Steven Ray

    (@steveneray)

    4 months, 3 weeks ago

    Hi @lencw,

    I’ve added a new setting specifically for your use case. Update to the latest 1.5.9 version (will be loaded up soon), and you’ll find “Hide from Customer Orders” in the Primary Product Code section.

    Check this option to hide the bin number from:

    • Cart
    • Checkout
    • Order received/confirmation page

    The code will still be:

    • Saved to order data
    • Visible in admin order screens
    • Available for invoices and packing slips

    This should give you exactly what you need – internal bin numbers visible for fulfillment but hidden from customers.

    Thanks for leaving positive feedback!

    Forum: Plugins
    In reply to: [Product Code for WooCommerce] Used for bin number – display issue
    Plugin Author Steven Ray

    (@steveneray)

    4 months, 3 weeks ago

    Greetings, @lencw,

    I just uploaded a revised interface with some text changes… it might make better sense now.

    Check both check boxes to the right of “Show Product Code” and “Hide Product Code”. The first enables display on cart, checkout, and receipts. The second hides it on product pages only.

    Thanks!

    • This reply was modified 4 months, 3 weeks ago by Steven Ray.
    Forum: Plugins
    In reply to: [Admin Custom Login] Caps Lock False Positive
    Thread Starter Steven Ray

    (@steveneray)

    4 months, 3 weeks ago

    I can’t help but notice that @weblizar doesn’t seem to care about its broken code, as nothing has been done after two weeks of multiple attempts at communication, and yet another error has been found.

    I found the following error as a result of having debug on: Warning: Uninitialized string offset 0 in /home/account/public_html/wp-content/plugins/admin-custom-login/login-form-screen.php on line 68

    This is unrelated to the significant issues reported and fixed initially; however, it has been long-standing in the plugin for some time. Again, I fixed it because my clients don’t appreciate broken plugins.

    Your developers were injecting error_reporting(0) everywhere to hide PHP errors from users, which, if WordPress finds out, could result in the plugin being suspended from the repository as they have done before. I have reported this security-compromised and vulnerable plugin to Patchstack.

    I submitted all the correct files for ease of deployment, along with changelog entries, directly to your support email, AND notified Weblizar support through your contact form. The good result is that this situation has motivated me to create my own login plugin, one that will actually receive support.

    Forum: Plugins
    In reply to: [Hide Cart Functions] Collision with Loco Translate
    Plugin Author Steven Ray

    (@steveneray)

    5 months ago

    Hello @daliborpuljiz,

    It took me longer than anticipated because I redid the user interface, rewrote the code-behind, and cleaned up the user side. Operates much better, looks better too. You might share this with @timwhitlock over on the Loco Translate ticket so he can test against 1.12.3.

    Hey, I don’t make a penny on these plugins, so please leave a qualified rating!

    Thanks!

    Forum: Plugins
    In reply to: [Hide Cart Functions] Collision with Loco Translate
    Plugin Author Steven Ray

    (@steveneray)

    5 months ago

    Greetings, @daliborpuljiz,

    I see the issue. The problem is in utilities-functions.php line 360 – the hwcf_translate_string() function is calling class_exists(‘Loco_gettext’), but that class doesn’t exist in Loco Translate. The correct way to check for Loco Translate is different.

    The fix is simple – check for a class that actually exists in Loco Translate, or check if the plugin is active another way. Looking at Loco Translate, the main class is Loco_package_Plugin or we can just check for the loco_plugin_self function.

    Actually, the whole function is unnecessary – Loco Translate works with standard WordPress __() translations, it doesn’t need special handling. The default else branch already handles it.

    I will have the 1.2.13 fix loaded up in the next couple of hours, along with other updates I want to apply at the same time. Thanks!

    Forum: Plugins
    In reply to: [Product Code for WooCommerce] Uncaught Error: Undefined constant “PRODUCT_CODE_COLOR” in
    Plugin Author Steven Ray

    (@steveneray)

    5 months, 3 weeks ago

    Greetings @grudikr, You’re correct – version 1.5.6 had a critical bug.

    The Problem:
    Line 24 of templates/product-meta-row.php referenced an undefined constant PRODUCT_CODE_COLOR that was removed in version 1.5.4 but the template wasn’t updated. This caused fatal errors on PHP 8.3.

    The Fix:
    Version 1.5.7 is now available and removes all references to this deprecated constant.

    We apologize for the issues with the recent releases and appreciate your patience.

    • This reply was modified 5 months, 3 weeks ago by Steven Ray.
    Forum: Plugins
    In reply to: [Hide Cart Functions] Message isn’t showing
    Plugin Author Steven Ray

    (@steveneray)

    5 months, 3 weeks ago

    Okay great, I will mark this support issue resolved.

    Forum: Plugins
    In reply to: [Product Code for WooCommerce] Add to cart stops working after updating to Product Code for WooCommerce 1.5.4
    Plugin Author Steven Ray

    (@steveneray)

    5 months, 3 weeks ago

    Hi @pastidea,

    Thank you for reporting this issue with such clear AI assisted detail—it really helped us identify the problem quickly!

    You’re absolutely right. Version 1.5.4 introduced a critical bug that broke add-to-cart functionality specifically when using AJAX cart plugins like WPC Fly Cart or XT Ajax Add To Cart.

    During the 1.5.4 updates, a critical JavaScript dependency (wc-add-to-cart-variation) was accidentally removed from the script loading sequence. This dependency ensures our product code script loads at the right time and doesn’t interfere with WooCommerce’s add-to-cart operations. Without it, the timing conflict caused add-to-cart to fail with AJAX cart plugin

    Version 1.5.5 attempted to fix a related error but didn’t restore this dependency, which is why the issue persisted.

    We’ve just released **version 1.5.6** which includes:

    ✅ Restored the missing JavaScript dependency
    ✅ Added safeguards to prevent similar issues
    ✅ Improved compatibility with AJAX cart plugins
    ✅ Removed some code that could cause conflicts during cart operations

    After updating, please test your add-to-cart functionality with your AJAX cart plugin and let us know if everything works correctly. Again, we apologize for the inconvenience this caused. We really appreciate you taking the time to report this. It’s users like you help us keep the plugin working smoothly for everyone.

    Best regards,
    @steveneray

    Forum: Plugins
    In reply to: [Product Code for WooCommerce] Add to cart stops working after updating to Product Code for WooCommerce 1.5.4
    Plugin Author Steven Ray

    (@steveneray)

    5 months, 3 weeks ago

    Greetings, @pastidea,

    Thank you for the detailed bug report. Your description of the issue and the steps to reproduce were very helpful in quickly identifying the problem. If you look at this plugin’s “Development” tab, you’ll see we’ve made many changes to align the code with the recent WordPress and WooCommerce releases among other updates.

    Cause: Version 1.5.4 removed an old and unused feature (Product Code Color) but missed two references to it in the cart functions, namely class-pcfw-services.php. This caused a fatal error when adding products to the cart, particularly noticeable with AJAX-based cart plugins.

    Fix: Version 1.5.5 has been uploaded to the repository, removing the remaining references and resolving the add-to-cart issue. Please update and confirm that the problem is resolved. Our deepest apologies for the inconvenience. Please leave a review, where we don’t make a penny from doing this.

    Forum: Plugins
    In reply to: [RSS Feed Pro] Can’t Get Pictures to Show Up
    Plugin Author Steven Ray

    (@steveneray)

    5 months, 3 weeks ago

    Greetings, @sjwoo,

    Regarding the support issue (%picture_url% not showing images):

    The original SimplePie’s code only tried $enclosure->get_thumbnail(), which is very specific and doesn’t work for most RSS feeds. The newly added code applied to the plugin now tries four methods in order:

    1. Enclosure thumbnail
    2. Enclosure link (if it’s an image type)
    3. Media:thumbnail or media:content via SimplePie’s get_thumbnail()
    4. Extract first <img> from the content/description

    Try installing the recently updated version 1.1.12, which should resolve the issue for most RSS feeds that include images. Please leave a raving review, where I don’t make a penny doing this.

Viewing 15 replies - 1 through 15 (of 84 total)
1 2 3 4 5 6