WordPress.org

Ready to get started?Download WordPress

Forums

Widget Logic
Shopping Cart Widget Fatal Error (8 posts)

  1. theroundwell
    Member
    Posted 2 years ago #

    I created a custom function in my theme files (I use Headway 2.0.13) and used Widget Logic to display my shopping cart widget only when there are items in the cart. (I use Cart66 to handle my shopping cart needs)

    Until I upgraded to the most recent version of Widget Logic (v0.51), this function was working as expected. After the upgrade, I am receiving a fatal error that crashes my site. When I deactivate the Widget Logic plugin, the site loads as expected, except that my cart widget is now displaying irrespective of the number of items in it.

    How can I fix this? [Code and error info is below]

    This is the code I use in the custom_functions.php file of my theme:

    /* // Displays cart widget if there are items in cart */
    
    function check_cart66_cart()
    {
    if(Cart66Session::get('Cart66Cart')->getItems())
    {
    return true;
    }
    else
    {
    return false;
    }
    }

    This is the code I put in the Widget Logic field of the shopping cart widget:

    check_cart66_cart()

    This is the fatal error generated after I upgraded Widget Logic:

    Fatal error: Class 'Cart66Session' not found in [...directory info...]/public_html/wp-content/themes/headway-2013/custom/custom_functions.php on line 46

    http://wordpress.org/extend/plugins/widget-logic/

  2. theroundwell
    Member
    Posted 2 years ago #

    One more thing: for the time being, I dropped back to using Widget Logic v0.48, where the custom function is working without a hitch.

  3. alanft
    Member
    Plugin Author

    Posted 2 years ago #

    it must be to do with the class Cart66Session which a quick google suggests might be from this plugin

    http://wordpress.org/extend/plugins/cart66-lite/

    so some interaction there is causing that plugin not to load the class when it was with the old widget logic technique. That's going to be a tall order to troubleshoot TBH

    I'll give it a go though, and get back to you.

  4. alanft
    Member
    Plugin Author

    Posted 2 years ago #

    ok, my diagnosis, but no actual solution YET. (it's late here)

    WL used to only intercept widgets after wp_head action, #22 in the 'typical' actions run:

    http://codex.wordpress.org/Plugin_API/Action_Reference#Actions_Run_During_a_Typical_Request

    and your cart plugin sets up the class at init (#9), so no problem

    but since the big change in v.50, WL puts in the interception way earlier - when the plugins are all activated (#2). and what I reckon is happening is that your theme (setup around #6) is calling wp_get_sidebars_widgets for something, which will then test for the existence of widgets and thereby triggering the WL code that references your class that hasn't been called yet.

    (I took out the reliance on wp_head because it seemed cleaner to do it the new way, esp as the old way often fell foul of themes that neglected to have a wp_head.)

    I can totally see that putting in the interception early is going to mess up using theme-based functions in WL text, so I need to make it delay til after themes are loaded (or at least provide that option).

    Looking down the list of actions init and wp_loaded seem to be the best candidates, and if I went with wp_loaded that would mean your plugin (which adds the class at init before wp_loaded) would work ok.

    One request I got for the old version of WL was to make wp_get_sidebars_widgets work properly so themes could decide what to do with an empty sidebar. So I think I'm going to have to offer this as another option 'late or early' (before or after theme load) loading of the widget logic.

    I'll try to whip this up in the dev version, and when I do, I'd be obliged if you could feedback on whether it's helped.

    Cheers, A

  5. theroundwell
    Member
    Posted 2 years ago #

    A,

    First of all, thank you for the complete and thorough explanation. I really appreciate it, even if I don't follow the intricate details!

    I'll be happy to work with you to give feedback as requested. Use this space to let me know what you need.

    Also, this may be a noob question, but wouldn't you want to set up WL before widgets_init is called? (I have no idea what widgets_init does, but I figured I'd ask since your plugin's sole function is to interface with widgets)... Or would that be a reason to set it up after widgets_init?

  6. alanft
    Member
    Plugin Author

    Posted 2 years ago #

    Great stuff thanks. Expect something within a few days (rather than hours or weeks)

    By default it actually intercepts widgets when all plugins are activated, ie BEFORE they widgets_init is called, though it doesn't run the WL code of course. This is the early load. Choosing the 'late load' point it would make sense to wait until the 'coast is clear' which is wp_loaded after all code, themes, widgets, etc etc are ready and we're poised to make an actual page.

    I'll be back in touch here. cheers

  7. alanft
    Member
    Plugin Author

    Posted 2 years ago #

    apologies for the lack of update. this 'late loading' will come soon, but it has turned into a few weeks :-(

  8. alanft
    Member
    Plugin Author

    Posted 2 years ago #

    I have added loading time options to the development version

    http://wordpress.org/extend/plugins/widget-logic/download/

    It's a new drop down option "Load logic: …" on the widgets page along with the other widget logic options.

    I'd be obliged if anyone seeing this would try it out and let me know if it's OK, failing, has fixed problems, made things worse, etc.

    Added to the dev version since .51 are these optional 'load times', and a export/import all WL settings

Topic Closed

This topic has been closed to new replies.

About this Plugin

About this Topic