Re: do we need plone.app.customerize? was: [Plone-Users] Insufficient privileges on folder_contents

On 10 Dec 2013, at 4:34 pm, Nathan Van Gheem <[email protected]> wrote:

> Playing with the idea of TTW jbot: https://github.com/collective/collective.jbot
> 
> This approach isn't "safe." It actually creates temp files for each template customization so templates aren't run in restricted python.
> 
> I think this could hit most people's use-cases though.

There already exists a package to do this which includes something like jbot.

https://pypi.python.org/pypi/plone.app.themingplugins

However I think that encouraging overriding inbuilt templates isn't a good idea. Mostly what people want to do is change just one or two parts of the template. Overriding the template this is reasonably easy but creates a big mess when you try and upgrade your site since plone's innards could have changed including templates.
I think a simple quick way for users to create new views would be safer.



> 
> Thoughts?
> 
> 
> -Nathan
> 
> 
> On Thu, Dec 5, 2013 at 12:41 PM, David Glick (Plone) <david.glick-z4DKO/[email protected]> wrote:
> On 12/5/13, 6:24 AM, Nathan Van Gheem wrote:
> I think many problems can probably be solved with diazo these days and yes, customerize doesn't not consistently work.
> 
> That being said, we do need a customization story for non-devs.
> 
> How feasible would it be to make a TTW jbot?
> 
> Shouldn't be too hard. z3c.jbot already has the right hooks to look for a template's source "somewhere else" when a template is rendered. We would just need to add to the possible "somewhere else" locations, by configuring it with a set of ZODB paths to search for templates.
> 
> This only takes care of overriding existing templates though. In a world without portal_skins and Acquisition, to add new templates we would need a way to register new views TTW (stored in the persistent component registry). There's no technical reason that can't be done, but no one has built it yet.
> 
> And even for the use case of overriding templates, security is a caveat. Part of the problem with portal_view_customizations is that it takes a template which was running as filesystem code (i.e. unrestricted) and, once customized, runs it as restricted Python. That tends to lead to authorization errors once things are customized if the template was/is using things that aren't allowed in restricted code. For some sites (i.e. most standalone sites) it would be fine to allow unrestricted execution of TTW-edited code as long as only Managers are allowed to edit that code. But for shared hosting (multiple Plone sites for different clients in one Zope instance) that's not very safe. I'm not sure how to solve this for those sites, short of maybe doing automated testing of all templates to make
  sure they still execute successfully as restricted Python.
> 
> 
> 
> -- 
> Nathan Van Gheem
> Solutions Architect
> Wildcard Corp
> ------------------------------------------------------------------------------
> Sponsored by Intel(R) XDK 
> Develop, test and display web and hybrid apps with a single code base.
> Download it for free now!
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk_______________________________________________
> Plone-developers mailing list
> Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/plone-developers


------------------------------------------------------------------------------
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk