this have been done in another hack related to templates compression...
I did search, maybe you could point to where this is.
Quote:
Originally Posted by nexialys
most of the time, it's not good to have such a feature because html is not written well, or is not xhtml relevent...
The hack doesn't break things, it doesn't affect JavaScript, etc... it merely collapses white space.
As both HTML and XHTML renderers ignore white space the hack can't possibly do anything that the HTML or XHTML wasn't already doing.
I've tested it on my forum and been sure to not upset anything anywhere... I only replace multiple white spaces with a single space... there is no chance a renderering engine will alter what it does because of this.
If I didn't put back 1 white space for the many taken out, then I would agree that I might be affecting the page display or something... as someone might've relied on spacing. However, I leave a single space in there for that reason.
I'm using 3.0.0, and I had to do something else, and still worked.
You see, I didn't find:
PHP Code:
if (DB_QUERIES)
{
But I did find:
PHP Code:
$pageendtime = microtime();
Strange indeed.
I've just checked the default file from Jelsoft for vBulletin 3.0.3 and the code as I've pasted it is on line 1852. So it is there when shipped.
You must've removed it at some point, maybe for another hack?
Well... no worries. If it didn't have the if (DB_QUERIES) block then you would be best to place the hack code BEFORE the $pageendtime variable. Otherwise the stat you get telling you how long the page took to load will not reflect the inclusion of the hack, as the $pageendtime is literally the timestamp of the page as it finishes being generated.
That won't work if someone uses the <pre> tag, which utilizes whitespace for formatting.
A fine point... added a 'lite' version to the first post that leaves white space at the beginning of lines alone.
However if you have a tech site in which you paste lots of HTML, etc... and you want to preserve space within that. Then you'd be best not using this hack at all
Your site will be even quicker if you let vBulletin store your CSS as external files. Then they can cache in the browser and you send less with each page request
Your site will be even quicker if you let vBulletin store your CSS as external files. Then they can cache in the browser and you send less with each page request
AdminCP > vBulletin Options > Style & Language Settings > Store CSS Stylesheets as Files? = Yes
Note that vBulletin needs to be able to write the files to the folder:
Quote:
If you would like to store the CSS stylesheet for each style as a file, you must ensure that you have a directory called 'vbulletin_css' inside the 'clientscript' folder, and that the web server has permission to write and delete files within that directory.
So you will need to create the directory is it doesn't exist, and then CHMOD the directory in question to have permissions something like 755 or 775 depending on how your Apache is configured. You don't want to CHMOD it 777... you never want to do that.
You can usually set permissions via FTP programs or SFTP... but it can always be done from SSH or Telnet
AdminCP > vBulletin Options > Style & Language Settings > Store CSS Stylesheets as Files? = Yes
Note that vBulletin needs to be able to write the files to the folder:
So you will need to create the directory is it doesn't exist, and then CHMOD the directory in question to have permissions something like 755 or 775 depending on how your Apache is configured. You don't want to CHMOD it 777... you never want to do that.
You can usually set permissions via FTP programs or SFTP... but it can always be done from SSH or Telnet
And yes, I realise that 664 is probably a better chmod... but you know... some servers I've been on are just lovely and hardened and prevent writing withour very specific chmod values... 755 and 775 being the most common two... so I was being lazy in giving execute too as this prevents people bugging me about something unrelated to the hack