suf_sidebar_count behavioral change 3.6.5

[metal450]

Hey Sayontan,

First, in response to the post (http://www.aquoid.com/forum/viewtopic.p ... 656#p11656): Yeah, it works great! I couldn't reply on that post though - the reply button was removed.


My actual support request: in all previous versions of the plugin, I was able to suppress the sidebars in certain custom templates by explicitly setting $suf_sidebar_count = 0 prior to calling get_header() (i.e. most of the blog has 2 sidebars, but in just a couple of pages, I was including none). This has stopped working in 2.6.5, and regardless of the setting it always shows the 2 sidebars as specified in the theme's settings. I wasn't able to locate where the relevant change took place, or how I can now suppress sidebars on a template-by-template basis. If you could point me in the right direction, it'd be greatly appreciated

[sayontan]

If those are static pages, you can actually use the templates for Single Left Sidebar or Single Right Sidebar or No Sidebars.

[metal450]

The custom templates have loads of other handwritten stuff in them, so I need to do it in-code...

[sayontan]

Still trying to understand the question. Are these templates you have created? If so, you have to tweak the code in custom-styles.php. Look for these lines:

Code: Select all

$template_prefixes = array('1l-sidebar.php' => '_1l', '1r-sidebar.php' => '_1r', '1l1r-sidebar.php' => '_1l1r', '2l-sidebars.php' => '_2l', '2r-sidebars.php' => '_2r');
$template_sb = array('1l-sidebar.php' => 1, '1r-sidebar.php' => 1, '1l1r-sidebar.php' => 2, '2l-sidebars.php' => 2, '2r-sidebars.php' => 2);

You can add to these arrays. So set the above to:

Code: Select all

$template_prefixes = array('1l-sidebar.php' => '_1l', '1r-sidebar.php' => '_1r', '1l1r-sidebar.php' => '_1l1r', '2l-sidebars.php' => '_2l', '2r-sidebars.php' => '_2r', 'custom-template.php' => false);
$template_sb = array('1l-sidebar.php' => 1, '1r-sidebar.php' => 1, '1l1r-sidebar.php' => 2, '2l-sidebars.php' => 2, '2r-sidebars.php' => 2, 'custom-template.php' => 1);

Notes:
1. Replace custom-template.php with your template's file name
2. Make sure that in the first array your template is associated with "false"
3. Put in the appropriate number of sidebars in the second array.

There may be some other tweaks needed in suffusion-classes.php:
1. Look for the function get_widths_for_template.
2. Change its parameters to:

Code: Select all

	function get_widths_for_template($prefix, $sb_count = false) {

3. Look for this code:

Code: Select all

		if ($prefix) {
			$sidebar_count = $sb_count;
		}
		else {
			$sidebar_count = $suf_sidebar_count;
		}

4. Change it to:

Code: Select all

		if ($sb_count != false) {
			$sidebar_count = $sb_count;
		}
		else {
			$sidebar_count = $suf_sidebar_count;
		}

Now go back to custom-styles.php and look for this:

Code: Select all

	$widths = $css_generator->get_widths_for_template(false, $suf_sidebar_count);

Change it to:

Code: Select all

	$widths = $css_generator->get_widths_for_template(false, false);

If this works let me know and I might consider adding a few filters for this so that you will not have to edit theme files.

[metal450]

Oh wow, that's a lot of changes...!

Basically what I've got is a number of custom templates, which live outside the theme directory and get invoked by a template_redirect action. This is so I can support them across multiple themes, which I often use for testing/development - i.e. whether I'm using suffusion or something else, the active theme always references the same PHP templates (because they sit outside of each individual theme's directory).

Some of the templates use 2 sidebars and some use none. For simpler themes, omitting a call to get_sidebar() was sufficient, but I found that with Suffusion I also needed to explicitly set $suf_sidebar_count = 0 before calling get_header() to suppress sidebar rendering. Since upgrading to 3.6.5, however, this no longer works.

(I think you got that already, just wanted to reiterate to make sure.)

So, I'm not sure exactly what's changed, but is the only way to achieve this functionality now to edit the theme's source? If that's the case, it *may* just payoff to stick with 3.5.7, as my main motivation for upgrading was to eliminate my last core-theme-edit, the aforementioned "featured content hack." It seems like achieving the no-sidebar functionality in my custom templates now requires substantially more core hacks than this - unless there's still another way around to accomplish this directly from the template in question.

For reference, an example of a "sidebarless" template:
http://www.justin-klein.com/potd/07_04_ ... _dsc_06_54

Whereas the majority of the pages use 2 sidebars, as per the suffusion options:
http://www.justin-klein.com/

[sayontan]

So, I'm not sure exactly what's changed, but is the only way to achieve this functionality now to edit the theme's source?

For now, yes, that is the only way. What has changed is that I have modified the custom-styles.php file. Earlier some parts of that file were dynamic, particularly things dependent on the number of sidebars. However I recently added the capability to write all the generated CSS to a separate file. For this to happen I had to remove the dynamic components of the style generation and follow a slightly different approach - relying on the body_class() method to generate the classes for the "body" selector.

To reduce the number of changes on your side I have to pass the $template_prefixes and $template_sb arrays through filters. That way your changes will be minimal. Let me think about this.

[metal450]

...Or perhaps something similar to what I had before, where i.e. it checks for a pre-defined generic flag that can be set to override the number of sidebars?

Not being wholly familiar with all the inner-workings, that strikes me as the simplest approach from a user's perspective - that way, each template is again responsible for only deciding its own sidebar overrides - and additional filters which define templates by name, etc, aren't necessary elsewhere. That would also most closely approach the more "standard" approach, where simply omitting get_sidebar() in a given template would omit the sidebar(s) in only that template.

I understand that this has its limitations which is why you went with a more complex solution, but I do think it's favorable to keep such an override limited to the template file in question.

...Or perhaps I misunderstood your proposed solution, and it would satisfy this

[sayontan]

Or perhaps something similar to what I had before, where i.e. it checks for a pre-defined generic flag that can be set to override the number of sidebars?

The trouble with this is that it is dynamic, which will prevent the right styles from being generated in the CSS. E.g. $suf_sidebar_count, if set for an individual template, will evaluate differently for each template and can hence only be generated at run-time.

[metal450]

Wouldn't changing the sidebars just be a matter of calling/omitting the relevant PHP that generates them, and you could still output the same (full) CSS either way?

If different *types* of sidebars result in different CSS, then a compromise could be to not allow the *type* of sidebar to be overridden, but just whether or not sidebars are used at all in the given template (again, akin to pulling out the call to get_sidebar()) - and of course, the generated CSS would be the same either way (i.e. include the rules that would be needed for the currently selected sidebar type - even if it may not be shown)

[sayontan]

Doesn't work that way. Trust me, it is complex, but mainly due to the insane amount of customizations possible through Suffusion. E.g. Your regular pages might have two sidebars, one on the left and one on the right, but you might want to use a separate template with two sidebars to the right for certain pages. Also the sidebars might have different widths across pages - that's another degree of customization.
Another complexity with eliminating calls to get_sidebar is that the theme is fixed-width, hence dropping a sidebar might create a gaping hole in the page.