Sidebars being produced by footer.php
I posted quite a while ago about the issue that graphene’s footer.php code actually produces sidebars as well. Which messes up the ability to do object caching, since widgets in sidebars (such as login status, …) are unexpectedly being output when calling or hooking to WordPress get_footer().
That original thread never had a response and is now closed??
I still would like to know why it was implemented that way, which seems hard to undo in child themes without basically redoing all files. Especially since other graphene template files do not call for sidebars as usual, but assume that calling on a footer takes care of everything, both footers and sidebars, all in one swoop. Even if sidebars are not wanted on certain pages.
A child theme to fix it would then end up being basically a total redo of most files to get the correct sidebar calls put in., rather than just a couple?ModQuote:That original thread never had a response and is now closed??
Topics in the forum automatically close after 60 days. This is to prevent people responding to old topics which concern older versions of Graphene. Graphene is in active development, so it’s always best to start new threads.
That said, I don’t know why nobody resonded to your original thread.
It might be easier for us to help if you provided an example of what you are trying to do. It’s possible that there is a better or easier way to do what you want to do; rather than assuming the theme is constructed incorrectly and requires to be fixed.Quote:Especially since other graphene template files do not call for sidebars as usual, but assume that calling on a footer takes care of everything, both footers and sidebars, all in one swoop
I’m not sure, but that might be the answer to your question right there. Let’s see if any one else chimes in.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.
You must be logged in to reply to this topic.