ninjaraptor

Hi Tami,

If you just want to make the template have no third sidebar, you can make it work with a little file editing.

First in your template files for your theme you need to remove the ‘tertiary’ sidebar. Depending on how it’s set up, it may have references in various files, most likely called with get_sidebar().

Then you need to adjust the width of the main column so that it fills the page – in the style.css file for the theme just set the width for #main to 100%.

If you’re not comfortable with messing with the theme, you might be better off finding a different one with two columns rather than three!

Hi jeff_, thanks for the reply.

I understand the placeholders in the default template – it was more the two that I mentioned (specifically calling the post permalink, and the slide button-content field) that were getting me, since they don’t appear to be explicitly used anywhere in the default template (correct me if I’m wrong!). I see the line;

<div id="fs-entry-button-comment-'.$id.'" class="fs-comment">'.$entry['button-comment'].'</div>

in the default template, but even though this is filled with the field from my saved page I can’t get the value to transfer into my active slide (have experimented with elements with ids like fs-comment, fs-button-comment, etc).

When I was using the default template, the fs-link element just called a hash ref (#frontpage-slideshow), which didn’t take me to the post (is this supposed to be replaced, or called via jQuery?).

Maybe I’m missing something, but I’ve been poking it for a while and it’s got me!

Cheers

————–

EDIT: After further poking in the fsChangeSlide2() function, it appears that the button-comment field is never set. That would explain my issues!

I also see now that the frontpageSlideshow() function sets an onClick handler for the link element, rather than simply setting the href in the template.

Further fiddling will ensue…

Well that’s answered my questions! Thanks for your time.

Hey Esmi,

Thanks for the tips – I ran through all of that and it still wasn’t working, so I stripped out parts of the install piece-by-piece on my local instance until the problem went away. Turned out the previous developer had written a proprietary plugin in a file named…upload.php. Looks like somewhere along the line the menu was parsing this file as a destination, so I renamed it and problem solved.

Caveat emptor – Don’t trust other people’s work!