Closed Bug 502092 Opened 13 years ago Closed 13 years ago
[Productization] Create admin preference to enable/disable minify
As part of the SUMO productization, we will need to have a preference for enabling/disabling minify. Alternatively, we may choose to remove minify entirely.
This blocks bug 502087, not bug 502089. I'm assuming it was a typo. ;) Minify should stay, but it absolutely needs caching. Otherwise, it's slower than before. If memcache isn't around, it should just cache in the filesystem.
(In reply to comment #1) > Minify should stay, but it absolutely needs caching. Otherwise, it's slower > than before. If memcache isn't around, it should just cache in the filesystem. Yes, I agree. Memcache > File cache > no cache (and without cache we might just as well remove it) However, the cache part can all be done in the config file in webroot/minify.php (it's currently done for memcache only). It should be easy enough to update the main() function for the two cases. However, minify should be configured on a per-product basis anyway, so I say we shouldn't go that far with this bug. We could have three options: * enable (using memcache) * enable (using file cache) * disable Sound good?
We also need to add a button for "purge minify cache". (This is the part that annoys me the most :) )
Everything seems to be fine. The admin options to enable/disable minify have been placed on the "General" page (i.e. tiki-admin.php?locale=en-US&page=general) I haven't been able to succesfully test the memcache flush, but it goes as far as calling flush() on the memcache object, so it should work. My cache just seemed to stay empty, but I'm sure that was me doing something wrong in testing :) I have tested the file cache and it works great. No cache also works, and memcache works just as before. I'm sure this will need a ton of QA once landed, but it's exciting to have a "Purge cache" button!
Oh yeah, the source used for creating the patch is here: https://bugzilla.mozilla.org/attachment.cgi?id=362842&action=edit
If the patch from bug 502245 gets an r+, which it may not, than this patch will need to be updated to use the new memcache tiki settings. This probably could be reassigned to me when it comes to that.
I agree. We can wait on your memcache patch first and go from there. The update for this would likely change: * the action for "purge minify cache" and the changes for the cache library files (which added the flush() function) * the location of the minify admin options (currently on the "general" page) if it doesn't follow Tiki practices
Note, just waiting on commit/QA of the memcache patch before I review this one.
Comment on attachment 387305 [details] [diff] [review] patch, v1 This will need to be updated to play well with the memcache patch. Reassigning to myself.
Assignee: smirkingsisyphus → paul.craciunoiu
This needs to be applied after the memcache patch to be tested.
Comment on attachment 396054 [details] [diff] [review] patch, v2 Extra QA on this one please.
Attachment #396054 - Flags: review?(laura) → review+
This didn't actually when memcache wasn't defined in local.php v3 patch fixes that by placing the memcache options in the minify config
r50450 / r50451 This needs to be enabled on tiki-admin.php?page=general The conf file currently cannot be created. Filed bug 513413
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: enable pref
Noting here that the code from tiki-admin_memcache.php that does the writing to minify.conf is not on the production server. I'm not sure why. Either way, we need to find a different implementation for this for our production servers.
From: Stephane Casset <sept@...> "I am planning to add this, ie kind of retake what SUMO did but in a little different way... So js at the bottom in one block, css loaded in one go with minifying..." Source: http://thread.gmane.org/gmane.comp.cms.tiki.devel/13690
LPH added an optional minify JS to Tiki. (Thanks!) But no minify CSS yet
You need to log in before you can comment on or make changes to this bug.