You are not logged in.
Yes I thought it was permissions so I’ve been experimenting a bit. I noticed via FTP that the owner for the CSS files (there are 4 of them) was set to 99 99 rather than to me and using PHP5 I couldn’t delete them. I reverted back to PHP4 and first downloaded the files to my PC. I then deleted the files on-site and re-uploaded them again via FTP. Doing a refresh showed them as belonging to me. I deleted one of them and then I went into txp admin and re-saved it from there. Checking via FTP showed that it had been saved as 99 99 again. The other 3 files that I had re-uploaded and left in place, when I re-saved those via TXP admin they remained as belonging to me.
I’ve reverted back to PHP5 again and all seems well but it would seem there might be a problem with ownership when saving a new file with the plug-in active. Any thoughts?
The plugin doesn’t set file ownership. That purely depends on how your webserver software calls the PHP binary which in turn executes the TXP PHP script (and plugins).
OK thanks Ruud. Looks like a couple of emails are in order. ;)
Hi Ruud and everyone,
I’ve been trying to get this to work with the CSS compression directions here.
So far, I have been unsuccessful. Anyone have any thoughts?
No matter what, thanks for the great plugin!
Swim Kitten, A Magento Site
When nothing but incredibly revealing dresses and swimwear will do
Raina, those compression techniques turn the CSS file into a PHP file. My plugin was written to achieve the exact opposite: being able to serve the CSS file as a static file instead of using PHP to increase performance.
You don’t need PHP to compress CSS. Your webserver can do this by itself if configured to do so. Depending on which webserver software you use, a different technique is needed: mod_gzip (apache 1.3.x), mod_deflate (Apache 2.x), mod_compress (lighttpd)
You don’t need PHP to compress CSS.
I’m wondering though, does compression really make any noticable difference to the end users except for in edge cases? Is it worth the gain seeing as external css is cached and hence won’t need to be downloaded again on subsequent page loads?
Compression helps with the speed of delivery. Really though, the benefits of compression are experienced by the host as there is overall. Less data sent per visitor equals a lot less as compared to all the monthly visitors as it relates to any bandwidth quota.
And strange as it may seem, although the actual compressing takes up some CPU time, it can reduce the server load for two reasons:
But as Eric says, one of the main benefits is cost reduction. After I added compression for static files on a server that I manage, bandwidth usage dropped 30-40%. Most of the websites involved contained mostly text, not a lot of images. That reduction was enough to avoid paying $135 extra each month (!) for additional bandwidth.
And strange as it may seem, although the actual compressing takes up some CPU time, it can reduce the server load…
Makes sense. Just wish someone could convince my hoster of this. Their answer on the subject:
mod_gzip is not a possibility on the server, as the associated loads (and temporary file generation) are insufficient. If this was a dedicated server then it wouldnt be a problem, but high loads on a shared server can cause serious issues.
rvm_css has still helped a lot in terms of perceived site speed though. It rocks.
Ruud, how are you handling changes in the CSS file in the ‘css’ directory?
I am used to edit my static CSS file with a feature rich editor which is getting the file via FTP.
I assume that saving the file via FTP results in a conflict with the CSS stored in the database.
Is there a possibility to synchronize the files via date?
One problem might be a time offset between server and local desktop.
Get all online mentions of Textpattern via OPML subscription: TXP Info Sources: Textpattern RSS feeds as dynamic OPML