Alla Plone Conference 2006, Stefan Holek ("lurker") ha presentato un applaudito seminario intitolato "Top Twenty Plone Pitfalls". Si può  leggere l'intera presentazione o guardarla online. 

Alcuni dei trabocchetti da lui suggeriti sono molto utili agli sviluppatori di prodotti Plone, in questa pagina sono stati adattati in una serie di "cattive norme" di programmazione, o cose da evitare.

Non sviluppare la logica dell'applicazione in TALES.

I template sono progettati per presentare, e solo per questo. Tutta la logica della propria applicazione dovrebbe essere scritta in Python (script, tool, ecc.). Se ci si trova a creare complicate strutture nei propri template, è meglio fermarsi un attimo e pensare a come fare in modo di far funzionare tutto grazie a uno script scritto in Python. Con espressioni scritte in TALES sarà difficile eseguire operazioni di manutenzione e di debug, oltre a rendere il prodotto poco comprensibile per gli altri.

Stefan suggerisce scherzando di fare una piccola donazione alla Plone Foundation ogni qual volta si usa codice Python in un Page Template. ;-)

Non imporre un modello relazionale ad un database ad oggetti.

Non ci si deve aspettare che lo ZODB lavori come MySQL.  Non è così. Lo ZODB è un database ad oggetti, non un database relazionale. Quindi è bene progettare la propria applicazione ad oggetti, piuttosto che come righe di dati in una tabella. Viceversa, non c'è nulla di sbagliato nell'utilizzare un RDBMS con Plone, se i propri dati lo richiedono. Il modo più comune per far ciò è usare un connettore di database e metodi ZSQL per leggere/scrivere dati dal proprio RDBMS

Utili fonti su come fare queste operazioni sono:

• http://www.plope.com/Books/2_7Edition/RelationalDatabases.stx
• http://plone.org/documentation/how-to/add-file-system-zsql-method
• http://plone.org/documentation/how-to/mysql-connectivity-in-zope-plone

Non controllare i ruoli, ma i permessi.

• Perché gli oggetti e i metodi sono protetti dai permessi, e non dai ruoli
• Usare portal_membership.checkPermission.

Non usare REQUEST.AUTHENTICATED_USER.

• AUTHENTICATED_USER non è sicuro, da molto lo si sa e si cerca di non usarlo mai
• Usare portal_membership.getAuthenticatedMember

Non usare il ruolo "Autenticato" per configurare la sicurezza del proprio sito.

• Il ruolo "Autenticato" ("Authenticated") è un ruolo che serve al sistema, ma non a gestire la sicurezza.
• Aggiungere i propri ruoli personalizzati.

Non usare ruoli proxy.

• I ruoli di tipo "proxy" ("Proxy roles") sono simili agli script SUID in *nix.
• Fare molta attenzione ai propri script basati su Proxy; si stanno probabilmente creando buchi nella sicurezza del proprio sito.

Non dimenticare di aggiungere dichiarazioni di sicurezza ai propri metodi, di default sono (!) pubblici.

• Perchè Item, che è la classe fondamentale per la maggior parte degli oggetti in Zope2, permette di accedere ad attributi non protetti.
• Essere sempre particolarmente attenti con i tool. I metodi potrebbero richiedere di essere pubblici e di dover eseguire propri controlli di sicurezza.

Non richiamare getObject in risultati da catalog.

• getObject usa internamente restrictedTraverse.
• Aggiungere tutto ciò che serve come metadati in catalog.

Non usare né contentValues né objectValues.

• contentValues/objectValues "risveglia" subobjects, per esempio, caricarli dal disco nella memoria.
• objectIds può essere usato, eventualmente, ma non contentIds.

Non ritornare oggetti dagli scripts, ritornare (liste di) dizionari.

• Gli oggetti non possono essere messi nella RAM-cache.
• La sicurezza degli oggetti verrà controllata.
• Gli script Python sono i primi obiettivi della RAM-cache.

Non elaborare nulla al volo mentre si sta visualizzando.

• Elaborare solo al momento giusto, quando i dati vengono inseriti, e salvare tutto.

Non "toccare" gli oggetti mentre li si sta visualizzando.

• Visualizzare un oggetto non deve causare una modifica dei dati del database.
• È facile causare accidentalmente una modifica; usare il tab Undo per controllare.