• Since the new plugin version, the widgets on my subpages failed. There I controlled the widget display by Widget Logic and an own function is_parent() which uses get_post_ancestors(). Replacing the page ID with the page object (as recommended in post by mmikkel) did work on one site. But on another this did not work anyway. There is also a ticket in the WordPress core trac. This gives the hint that the function get_post_ancestors() has sometimes caching problems. And that is, what I suspect, the final reason for my widget problems.

    In the last days I’ve analysed the new plugin implementation a bit and found a quite strange behaviour.
    When using the old version 0.48 the widget logic is executed exactly one time for each widget. With the new version and exactly the same widget configuration on a freshly resetted wp3.3.1 installation the widget logic for one widget is executed 9 times. The first execution already before the get_header() function. At this point no post ID is provided.
    (Only the plugins “Widget Logic” and the debug plugin “Electric Studio Logger” were enabled.)

    When the widget logic is called the first time no post ID is provided and in some cases get_post_ancestors() probably caches an empty result for subsequent requests. After replacing the function with an alternative algorithm (based on direct mysql database requests) the widgets are displayed correctly, but there is still the multiple execution of the widget logic for a single widget.

    I stepped back to Widget Logic v0.48 for now and hope that the new version may be improved to work properly. Without doubt, the concept of the new version is the better.

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

Viewing 1 replies (of 1 total)
  • I have been very bad at getting round to what I promised in this thread

    http://wordpress.org/support/topic/plugin-widget-logic-wordpress-fatal-error

    which is to say a ‘delayed’ loading of WL. The new ‘sidebars_widgets’ filter approach means that the sidebar is evaluated a number of times depending on themes and plugins used – often to check if there are no widgets, in which case a theme can provide alternative content or layout markup.

    What i said in that thread is that I’ll work on providing the option of when WL steps in to intercept widgets – because some people do want it early, but others like yourself (probablt even the majority) would benefit from/prefer it later. I’m thinking of offering:

    plugins_loaded (the current default)
    after_setup_theme (so theme functions will be callable)
    wp_loaded (another crucial point where all code is ready to go)
    wp_head (after the query is run and posts to display are selected)

    This last would introduce ‘compatibility’ with the old version, and would suit you I think. One problem users had in the old version (and it’s in the FAQ) was that some themes forgot to call wp_head, so I thought I was being clever not having to resort to it. But at least with these alternatives, WL should be able to cope with a wider range of needs.

    I’ll try to get something in the next couple of weeks.

Viewing 1 replies (of 1 total)
  • The topic ‘[Plugin: Widget Logic] Strange behaviour of new implementation’ is closed to new replies.