Sure.

The script stores the $templatesetid of the template set you are working on in a cookie called $bbadmin_templatesetid.

Cookies are set through the PHP function setcookie(..), which sets the cookie by sending an HTTP header to your browser (like any other cookie-setting mechanism).

Here comes the problem: HTTP headers have to be sent to the browser before any display output has been sent to the browser. My cookie-setting system doesn't abide by that rule at the moment, as I tried to make as few modifications to the original template.php as possible, in order to make installation as easy as possible for all you guys and galls.

Therefore, when you run the script, the setcookie(..) function is actually called after PHP has output stuff to the browser, causing it to fail...

u n l e s s . . . ;)

you have output_buffering enabled in your php.ini file. This has the effect of preventing any output being sent to the browser until the PHP script has completely finished its execution. Therefore, the setcookie function is still valid, even though it's being called at an illegal point in the script. Using vB2's GZip compression system will have the same effect.

If you do not use output_buffering or gzip compression, or if you are using PHP3, then you should comment out the line in ktemplate.php that says $usecookies = "yes";. This will prevent the setcookie(..) function from being called.

Does that make sense to you?

Yes, thank you so much!

But I thot I set my gzip stuff to on in the options? Gotta double check that but I'm pretty sure...

To be honest, I haven't looked that closely at vBulletin's implementation of gzip compression... most implementations employ some form of output buffering, which would allow the cookie to be set, but if the control panel doesn't use the compression, or if vB's gzipping doesn't buffer the output, then setting output_buffering = On in php.ini is going to be the only way to allow the cookie to be set.

Once vB2 goes gold, I will revisit the hack and recode it so that the cookie can be set on any system.

You DO have to set output_buffering on in the php.ini. I tried just setting the vB gzip and the error was still apparent.

Works great with output buffering on though.

I installed this have into v2.0 and it works fine except for one error that appears at the top of each page. It is as follows:

Oops, php3_SetCookie called after header has been sent in ../ktemplate.php on line 46

What does this mean? How can I fix it?
I do have GZip enabled with a level of "1" compression.

very nice hack Keir, however I am missing two options from the original -

1) revert back to original
2) view original

The second in particualr was very helpful, when I screwed up something - or thought I did - and wanted to compare my edited template to the original.

This functionality is still there, just click the 'remove' button. It does the same thing as the original 'revert to original' hyperlink. Yes, this function is currently not available. If any javascript gurus can tell me how to read the yyy part from this: <option value=xxx>yyy</option> then I can put the functionality back in very easily... but I don't know how to pull out that info at the moment. I'm sure it's possible though.

If they click the view default button, run an extra query to get the name of the template known by its templateid and then just grab that template where templatesetid=-1.

Cheers Ed, but I've just found a way to do it without an extra query :)

Will post an updated hack in a short while once i've integrated it into the existing code :D

Updated version now available in the first post of the thread.