Disclaimer: We do not hate TTW
So please stop hating us
Now that Plone 3 is reaching a wider audience, it's only natural to some we get more feedback - positive and negative. Thankfully, most of it is positive, and it's a release that the whole community is very proud of.
Now, In the past few days, there have been multiple blog posts about how some things that used to be easy to do through-the-web got harder. That's understandable, of course. First of all, anything "new" is an additional overhead, and thus by definition harder. Secondly, we've done quite a lot to the underlying Plone 3 architecture. That has made many things easier, but also some things harder.
However, I'm a bit fed up witih the undertone that this has something to do with the core developers losing touch with (or not caring about) the needs of everyday integrators. An incredible amount of work went into Plone 3 (with five.customerize, plone.app.viewletmanager and plone.theme) to ensure that TTW-customisers and theme authors had a sensible story that didn't involve becoming on par with a core developer. The issue of how something could make life harder for basic integrators/customisers came up in discussions again and again. It was not as if we didn't care.
For the record, some template customisation is now done in the portal_view_customizations tool, because it relates to templates on views and viewlets and portlets which are implemented differently to plain old page templates in skin layers. You can change the header and footer here just as you could in the custom folder before. Using viewlets actually gives us some TTW tools we didn't have before - to easily hide and re-order elements of the UI (just go to http://localhost:8080/myplonesite/@@manage-viewlets to see what I mean). Most of the basic templates, stylesheets and images are still in portal_skins, of course, and work as before.
Why did we do this? Well, some of the old ways of doing things were becoming difficult to manage, impairing our productivity. Some of the things we wanted to do in Plone 3 would have gotten so tangled up in templates and persistent tools and pyscripts in a flat namespace that we probably wouldn't have been able to do it (at least not as well). Views and viewlets and new-style portlets give us the power to make a more robust Plone. For the amount of stuff that went in, Plone 3 has had incredibly few serious bugs post release. That's not accidental.
I'm not saying we're perfect. We got some things wrong, we made some stuff harder. But we certainly didn't do that out of arrogance or ignorance of how most people use Plone, and we tried damned hard not to make things more difficult whenever we could.
So, if you're frustrated, we'd like to hear about your troubles. Post to the mailing lists and tell us what you're struggling with. Maybe there's an easy way that you just haven't found yet, or maybe there's something we need to work on. Chances are we'll try and fix it. If you're lucky, we'll even be able to fix it before the next major release, because some of the pluggability we built into Plone gives us more flexibility to do that kind of thing. For an example of that, you need look no further than plone.browserlayer, which plugs an integrator/third-party product developer gap we hadn't anticipated. Go figure.