In reply to: Sidebars being produced by footer.php

#32159

Quote:

rather than assuming the theme is constructed incorrectly and requires to be fixed.

I am not assuming anything really. Just looking at facts.

Whether it is “constructed” incorrectly” depends on whether Graphene intends to be running within normal WordPress style/rules. Under which, when you call WordPress’ get_footer() function, it will call on the template’s footer.php, and you are supposed to get a set of footer HTML. Similarly, when calling get_sidebar(), WordPress will call on the templates sidebar code.

Not so for Graphene! When you call footer.php in the Graphene template (and therefore expect that you can take that content and cache it as footer HTML, you really get both the footer, PLUS any and all sidebar’s that might have been configured. There is even a comment in sidebar.php for Graphene that says something like “no need to call this because it is called in from the footer”.. Weird.

My original posting (you can see it by listing it in my profile) explained what I was/am trying to do.

To speed up output for special page-types and output, I was/am implementing object caching (like other CMSs have as built in functionality), so individual larger objects, such as footer, Sidebar, main content, header, … can be cached separately. without regenerating unnecessarily. To be wiped under certain conditions. For example, header and footer might be 100% fixed across all pages. Main content changes for every page of course, and any one (sidebars in my case) can change if a user for example logs out and magically a login/status widget has to change. Or if you have such as “Related Posts” widgets, which of course change on every page as well.

Anyway, that is when I suddenly realized that when running under Graphene, caching what SHOULD have been the otherwise 100% static “footer” html suddenly also cached in sidebar HTML. And trying to cache actual sidebar by hooking into WordPress get_sidebar() does not work at all, because Graphene’s sidebar code assume it will be called ONLY from its footer, and you now get a second set of HTML.

(Can you see how that sounds and looks strange in itself? Just seeing it in writing? That sidebars are spit out when one call WordPress’ standard get_footer() function to get a footer?

I cached the header/footer, and page content, avoiding caching the sidebar because the widgets change. But magically my widgets never changed as they should. They stayed constant. Same login-status, same “related posts”, whatever the widget content migth be.

Because that code had landed inside the now saved footer cache-object, where neither I nor WordPress expected it to be. 🙂

In fact, if you separately cache a “Footer” and “sidebars” as WordPress in itself expects it to be, you will with graphene get double sidebar HTML. One set of sidebar HTML comes out from calling for the footer, and if one calls for the actual sidebar separately (like most non-Graphene post/page templates do) , you would then get a second set. 🙂 You can see that also in Graphene page/post templates. None of them ever call for a sidebar. That code was taken out, because calling for the footer spits out all of it. 🙂

The owner of the code can judge whether “wrong” or not. The fact still remains, that independent of that judgement Graphene is not doing it the way WordPress (and WordPress add-on programmers) expect it to be done. A shortcut was made in the logic (likely to centralize the decisions about “which sidebars to produce” in one place). With with the configurable Graphene sidebars a laps in judgement probably got that centralization stuck inside footer.php, where it is not really supposed to be.. But that shortcut comes with some serious side-effects.

It might have been better to put the decision around which sidebars into logic in functions.php, and then support “sidebar-logic” from each page/post template as usual for WordPress. When left/right sidebars are created/called for separately they can also be cached separately. Maybe one is static, and another has the above mentioned constantly changing contents and should never be cached.

In reply to: New "Feature" of sidebars being built by footer.php

#28201

BTW.. This also had another side-effect when building the bbpress setup (with or without the caching functionality). The base bbpress template files call get_sidebar() and get_footer() separately, as most templates would do, which when added on top of graphene means two calls to get_sidebar(). One in the bbpress template code, and a second time inside its get_footer() call, when it hits graphene’s footer.php. I had to delete the bbpress calls to get_sidebar() to stop the doubling up on sidebar calls.