Ramon Navarro Bosch and Victor Fernandez de Alba talk about plone.app.multilingual: Next generation multilingual history during the Plone conference 2012.

(Sorry, I missed the first part.)

There is no canonical language in plone.app.multilingual.

There support for a neutral root folder.

We have a translation map. Good for the mental sanity of site managers and translators. It show content and its related translations.

We have support for Google Translation Service. This is a paid service.

There is a migration path from LinguaPlone. It is non-destructive: the original information is still there on the content items. Lookup your code for LP dependencies before you migrate.

Some internals. There is an ITranslatable marker interface. Some adapters. We store the relations in a separate catalog. Unified interface for getting and setting the language of an Archetypes and dexterity item.

Now a demo. Works well.

Roadmap:

• XLIFF support
• remove the catalog patch
• support for Iterate
• LinguaPlus/Linguatools have a set of useful tools
• locator translation policy: allow user to decide in which folder a new translation should show up
• translation workflow support
• plone.app.toolbar support

Thanks to a lot of people who helped us!

Code: https://github.com/plone/plone.app.multilingual

Releases: http://pypi.python.org/pypi/plone.app.multilingual

See also: http://pam.iskra.cat

Alan Hoey talks about security for product developers during the Plone conference 2012.

I'm Alan Hoey. I work for the Code Distillery. I am on the Plone Security team. I will talk about security in your add-on. The Plone core is reasonably secure, with a good track record. Add-ons are usually not audited though. A vast majority of developers probably try to the right thing, but some things may slip through the tracks. This talk is about what happens when you do not pay attention. If you have not thought about it, you may be vulnerable.

What are common vulnerabilities? It can be simple things like ratings on products or pages that get wrong, like getting an average score of 999 out of 5. There can be denial of service attacks. Cross Site Scripting and Cross Site Request Forgery (CSRF). Boxes can be taken over if you don't pay attention.

Why should you care? You don't want those calls from a customer whose server is hacked.

Object publishing in Zope. Zope will publish anything as long as it does not start with an underscore. So use security declarations. If some method is not meant to be published, you can decide not to add a doc string, which will work until someone innocently decides to add a doc string anyway.

Try to look at your code with the mind of an attacker.

Traversal. Look out with importing os as an attacker may be able to traverse to it. Do not use unrestrictedTraverse unless you know what you are doing.

All classes should use ClassSecurityInfo: declarePrivate, declarePublic, declareProtected. There is also ClassSecurityInformation, which is by default closed, but does not work. We should fix it. Monkey patches need security declarations, just like everything else does.

ZMI properties are readable when you can view the object. So not a good place to put API keys. The registry is a nice place: you cannot read it from the web.

The security on BrowserView is very good. If you override the __init__ method and set the context and request, or anything else, you have thrown that security away.

Use plone.protect on all forms that need CSRF protection. Also the postonly attribute.

Acquisition is scary from a security view point. Be aware that a script can be called on any context. It is better to use container instead of context.

Do not give Restricted Python access to untrusted users.

Do not use allow_module. Use ModuleSecurityInfo instead.

Zope Page Templates. Do not use structure if you do not need it.

Deployment. Please do not miss hotfixes. Do not think that you can hide acl_users in Apache and think you are safe.

Steve McMahon talks about Plone Production Deployment: Secrets & Tricks, at the Plone conference 2012.

We are going to have a special version of this talk: no secrets, to tricks!

If you are hear, or reading this blog item, you should be a (Unixy) SysAdmin or Friend of a SysAdmin. This is not going to be an advanced talk. If you want something more advanced, find Martin over in the Disco room.

A PHP programmer may run away screaming when you mention reverse proxying and caching, but if they manage a big site, they will use those technologies too, and will not still be on a five dollar/euro per month server.

A stand-alone is great for development, but you should not use it on production. It lacks versatility, SSL support, and more.

So we add a web server, like Apache or nginX. Modern web servers can be used for reverse proxying. It can handle SSL, efficiently queue requests, handle URL rewrites. They generally have battle-hardened logging and request sanitizing. Lots of people have tried to break it. It probably rejects requests that are obviously meant as an attack. It will play well with other server parts.

You may add other web applications. Plone is your CMS, but you may let another application handle one special part of the site. Single Sign On can be done between the two applications.

Donald Knuth famously said: "Premature optimization is the root of all evil." It was expanded by Elizabeth Leddy: "Measure, measure, measure. Then act." Do not make your stack more advanced than it needs to be. Measure, experiment, measure. If the measurement does not show an improvement, reverse the changes. You may not need load balancing, whatever that person on irc tells you.

Leonardo da Vinci said: "Load balancing means always having a canon ready to fire." We replace canons by zeo clients that can handle a request. Such a ZEO setup can scale to multiple machines. It is a good option, even without load balancing: you can use a second zeo client to handle debugging (hope you do not need it) and to run scripts that take long. The zeo server has different requirements for memory, disk space, CPU, so you can optimize. And of course you regularly do a bin/zeopack on the command line to pack your database.

Good load balancers distribute the load very well over the zeo clients that are live. This helps to avoid service interruptions. The balancing scheme can matter. Default is round robin. If sticky sessions are into effect, you usually end up at the same zeo client all the time, which helps for the caches that this zeo client has. But you can change your balancing scheme and measure if that improves responsiveness and stability.

Someone around 1566 said: "Good caching makes light work." You can add a server cache, a reverse proxy cache. Typically this weill be between the web server and the load balancer. It can be on a separate machine. You cache in memory or on disk. A good cache is usually varnish or (poor you) squid. David Glick, during the Cioppino 2012 sprint, said: "Caching is hard." If you expect a lot of traffic for a day, then you may need more aggressive caching."

plone.app.caching is how to do caching in Plone 4. There is cache invalidation, but that is hard. A page may show a portlet that shows a collection, which may need to be invalidated at random times, not having to do anything really with that page, which may not have changed this year. My general strategy is to start conservative with caching and then slowly turn it up. You handle anonymous and authenticated requests differently. Dylan Jay said during his lightning talk yesterday that he simply cached one minute. You do not need an invalidation scheme then.

Choosing some tools. Take care of your tools and they will take care of you. You can do the best of breed approach:

• web server: probably Nginx, maybe Apache
• proxy cache: our community chooses varnish. It makes incredibly good use of memory. It will make really good decisions about memory and swapping.
• load balancer: I love HAProxy. It allows you to use several different schemes. Sticky sessions are a bit tricky to setup, but it can be done. SSL can be a problem, but latest version has improvements.

A perfectly reasonable alternative in some circumstances, is to let the web server do it all. William of Occam, translated to modern speak, said: "Keep it simple, stupid." Having everything in one web server may make that web server too complex though.

Read about hosting here: http://collective-docs.readthedocs.org/en/latest/hosting/ You can edit that document, or propose changes.

Elizabeth Leddy: "Backup is serious shit." Restoring is serious too. You need to test a restore scheme, otherwise you do not actually have a backup. There are horror stories about that. So what you do is: backup, rsync to another server, restore. Use collective.recipe.backup.

Eric Steele: "Rotate your logs, or your server will do." Florian: "At some point, move the old logs as well, as they still keep up space." sudo apt-get install logrotate. Rotate your Z2.log, event.log (instance/zeoclient.log), do it weekly, postrotate do a kill -USR2 on the zope process so the logs are reopened. On the topic of log files: read your event logs. They have important information. Some tracebacks you may know about, and they drown out the nasty stuff. Read them regularly. Try to get the noise in the logs down. Look at mailinglogger for this, which is already in zope, or Sentry. Maybe set the log level to warning instead of info. That helps a bit for performance too.

ZODB packing: use the bin/zeopack script, installed by plone.recipe.zeoserver. Set it up in a cronjob.

Elizabeth Leddy, Cioppino 2012: "These days, I use system packages as much as possible. You should, too." I want my routine security updates of the operating system to apply without me needing to do much about it. The least used feature of the UnifiedInstaller: --with-python=/usr/bin/python2.7. If it meets the requirements, it will use it.

Last advice: never run buildout as root. Always create a separate user and run buildout and run zope as that user. If hostile code ended up in a setup.py of a package and you run buildout as root, then your server is owned by others.

Read about deployment here: http://collective-docs.readthedocs.org/en/latest/deployment/ You can edit that document, or propose changes.

If you edit this, put the complex information in the hosting docs and the beginner documentation in the deployment docs. And own that document as a community.

Elizabeth Leddy talks about Plone as a Development Platform during the Plone conference 2012.

This is a highly opinionated talk about the future of Plone from a Framework Team member, developer, project manager, consultant, loud mouth and general advocate of change, also known as Elizabeth Leddy. (Those are her words, but you knew that.)

This is the third time I give this talk this year. Sorry, but each time I do this it gets more positive, which never was the original idea.

In the Plone 4 series there are two trends. We have been and are busy with modernizing the user experience and modernizing the architecture.

A PLIP is a Plone Improvement Proposal. Plone is almost perfect, but people keep wanting to improve it. There is a Roadmap Team, but they do not decide what happens. People still need to give ideas and write code. They do not do that by themselves. So if you have an idea for Plone that you think should be in Plone, go ahead and make a PLIP, also if you are not a core developer.

There are 1132 open tickets on http://dev.plone.org/. We have fixed lots of tickets this year, but this still means 8 tickets per core developer. And we still get 3.4 tickets per day. If you are a core contributor and can fix 4 tickets during the next 12 months, that would be awesome. If you are sprinting this weekend and do not know where to start, grab a ticket! Ask me if you do not know which one to pick.

In January 2012 29 new add-ons were registered on http://plone.org/. The Plone collective on github has 680 repositories, and rising, which is pretty amazing. The number of core packages are actually going down a bit, making things simpler.

What will Plone 5 be? It is whatever the release manager says it is. We will see what gets in it and whether all the shiny new goodness is in it.

There is a bitterness factor in development that keeps Plone 5 too far in the future. Plone 3 introduced a regression. There was less development going on. There was more complexity. Some people were leaving the community. There is a popular stackoverflow question from 2008 that basically asks: "I may want to use Plone, but is the steep learning curve worth it?"

I want to focus more on making the easy things easy. Keep the syntax simple. plone.api is a great start. Reduce the number of files needed to start. Reduce the number of imports needed.

We need feedback and if you are a newbie you are perfect for giving feedback. Documentation is a scapegoat: if we write better APIs, then we need less long documentation. We need developer driven development. Think about that fellow developer that you drank a beer with last night: is he going to be pissed if he reads your code and needs to use it?

Plone 5 has the potential to make happy developers! A thriving community of happy developers makes it easier to hire new people, getting people enthousiastic about working daily with Plone. I usually get some dot NET developers or old Java developers to start working with Plone, as for them Plone is easier. A large community of happy developers also makes it easier to fire someone, or get rid of a client: they can get new developers.

The add-on self certification checklist should get a 'Certified by Spanky' checkbox: can a self-professed average developer like Spanky use this add-on?

Yes, we hear you and we are serious about fixing it. At the Plone Konferenz we started a Plone Pain Top 10. A few of them:

• Getting site root is too hard. Use plone.api.
• Getting a component or view versus getting a tool. Planned in plone.api.
• Cleanup of documentation in core. Help needed.
• Move more code to Python instead of skin templates and scripts.

Plone 5 todo items:

• Make Archetypes optional. Widgets in dexterity should get better. Recreate the default Plone content types in dexterity.
• No more KSS used in core.
• Javascript date formatting.
• plone.api in core

Summary: Plone 4 modernizes the user experience. Plone 5 should modernize the developer experience.

Please decide to commit yourself to Plone the community. Too many people sitting on the fence, waiting for new stuff to land in core, or for the next CMS written in Pyramid, just means we have a busted fence. Nothing happens.

Make it a policy in your company that new employees sign up for Plone on day one. Do the paperwork: get them to sign the Plone contributor agreement, make sure they get a plone.org account. Persist the Plone culture. Pre-install an irc client and configure it to connect to the #plone channel. New developers should not just get to know the code, but also the community. Teach them how and when to file bugs and properly contribute fixes. Do mentorship in your company. You get good developers that way.

Resolve to travel. Hosting a sprint is a great way to contribute back to the community. Ploners love to travel. Send a person to a conference, also non-technical people. You get them to a conference, we get them to stay. Have someone give a talk, for example present a case study. And let them stay to sprint. Form an alliance with other developers or companies. Show what you have done for clients that is not publically available as open source. Maybe you can share.

Resolve to encourage. Test a new version of Plone. Put it on the staging server of a client and test it yourself or even have your client test it. Make a policy to stop forking packages if possible. Have your fixes end up upstream so you do not need your fork. Set aside time for a company sponsored PLIP.

Resolve to sprint this weekend. I will work on two sprints. For beginners: finish the Plone Contributor Agreement process. For advanced developers: goodbye .cpy.

Plone has the potential to make happy developers, but only you have the power to make Plone!

The Plone 5 code name should be: No excuses.

Rok Garbas finally talks about Deco at the Plone conference 2012.

We have been talking about Deco for at least four annual Plone Conferences in a row. I got introduced to it during the Living Statues Sprint here in Arnhem in 2010.

Let's first have a definition for clarity: Deco is a layout editor. Tiles are something different, they can be used outside of Deco.

You need to install the Deco package. You get a toolbar at the top, in an iframe. You add a Deco page and add tiles there, for example just some tiles with rich text, using TinyMCE. You can drag and drop tiles around on the page.

So, the toolbar at the top is an iframe. It should work fine, stretching if needed. With iframe.js this is easy to do, also if you need to put other parts of the DOM in an iframe. We use this to show both the back-end and the front-end on the same page, without needing to worry about how the back-end looks and whether your Diazo theme conflicts with it.

The next thing is tiles. Tiles are mean and lean. If you use Grok instead of zcml, one file is enough. Tiles are a brower view with an extra interface. There are persistent tiles (stored in ZODB, compare portlet settings) and transient tiles.

Then the third part is the real Deco part. The communication between the Deco iframe and the main frame (the front-end page) was hard to get right and was the main reason why Deco took so long to develop.

Current integration in Plone is: Deco Lite. This is a dexterity behavior, so only available for dexterity content types. It works only on the content area. Portlets are still working as before.

If you want to use tiles without Deco, you can install plone.app.tiles.

Deco is really close for production use. A few bugs need to be fixed. I will sprint on it at the end of the conference and hope people will join me.

A few weeks ago I was frustrated with the code, because the Javascript code was untested. Now it is 50 percent tested. If you want to know more about automated testing of Javascript, come to the Sea Sprint talk, later today.