We often have the following problem :

1. a CSS or a Javascript file is changed in a package
2. we make a release (or not) and put it to production
3. some visitors still gets old CSS and Javascript versions (except if by chance we remembered to reinstall package / re-save portal_css and portal_javascripts configs) and need to flush their browser cache

As we do not have great memory and as our customer’s Helpdesk was tired of doing remote cache flush, we wanted to do something (automatic) about it.
Plone adds cache keys as suffixes for CSS and JS files, as for example base-cachekey6247.css.
This cache key doesn’t change, even after an instance restart. This is why browsers can keep the “old” versions cached.

To avoid that (and without touching to Apache or whatever), we wrote a little script that exectutes at the end of the instance startup process.It forces the “cook” of resources which generates a new cache key so that browser cannot cache CSS and JS anymore !

This script can of course be improved, but it fits our needs.

[Please note that this code is written for Plone 3.]
First, we subscribe to IDatabaseOpenedWithRootEvent (too bad we couldn’t use IProcessStarting because we have no context to get Plone sites) :

  <subscriber                                                               
      for="zope.app.appsetup.interfaces.IDatabaseOpenedWithRootEvent"
      handler=".resources.clear_cache"                               
      />

Then, our handler gets the work done :

# -*- coding: utf-8 -*-                                                    

from Products.CMFCore.utils import getToolByName                           
from zope.app.appsetup.bootstrap import getInformationFromEvent            
import transaction                                                         

from our.package import logger                                       

def clear_cache(event):                                                    
    """                                                     
    Force cache key renewal for CSS and JS on all Plone sites at startup.  
    This avoids any caching of changed CSS or JS.          
    """                                                     
    db, connection, root, root_folder = getInformationFromEvent(event)     
    app = root_folder                                                      
    for obj_tuple in app.items():                                           
        (obj_name, obj) = obj_tuple                                            
        if obj.get('portal_type') == 'Plone Site':                         
            p_css = getToolByName(obj, 'portal_css')                        
            p_css.cookResources()                                           
            p_js = getToolByName(obj, 'portal_javascripts')                 
            p_js.cookResources()                                            
            logger.info('Cache key changed for CSS/JS on Plone %s' % obj_name)
    transaction.commit()

And voilà, no more browser cache flush hassle for our customer and their Helpdesk

If you have any thoughts on this, or think that this should be packaged in a collective egg (useful for you ?), feel free to comment.

Do you have users that don’t care about image sizes at all ?
Do you have Plone sites with tons of raw photos galleries ?
Do you want to shrink your Data.fs ?

Then try the new collective.autoscaling package !

It allows automatic scaling of large images uploaded into your Plone sites.
You can configure the maximum width / height you are willing to tolerate and it does the rest !
This is totally transparent to the user (except if you choose to show message).

Images can be either Image content type or any Image field on Dexterity content types.

Example use case :

1. You configure collective.autoscaling to have images with maximum size of height 800px / width 1200px.
2. One of your user uploads a really big image : height 2000px / width 4000px.
3. This image will be resized to height 600px / width 1200px (aspect ratio is of course preserved).

There is also a migration view you can call on any folder (or at the site root) to resize all contained images.

collective.autoscaling (developed for IMIO) is available on Github and version 1.0 has just been released on Pypi.

Please enjoy, improve and send feedback !

For a project, we have added some extended fields on contents. Those fields use KeywordWidget widget (same as Plone ‘Subject’ tags).

We wanted to have a custom permission on those fields, so we used :

read_permission=permissions.OurCustomPermission
write_permission=permissions.OurCustomPermission

But it didn’t work : the field title and label displayed correctly (when we have the permission) but the widget never happeared.

Why ?

Because the KeywordWidget template use allowRolesToAddKeywords (from portal_properties / site_properties) to filter who can add new keywords. So that “permission” will impact your custom fields too !

There has been tickets / discussion about allowRolesToAddKeywords, but that never changed.

Hope that noone else would get bitten by this once-for-all permission on keyword widgets.

We just created a new package to gain a lot of time when we create new plone packages from scratch. The main goal is to maximum simplify this creation. This can include a diazo theme.

All the details are in the README of the package found in https://github.com/affinitic/templer.affinitic