What do I really need to know about ZOPE?

That depends on your needs (obviously). Here just a quick list (probably in the order you'll encounter them) - also check the Glossary for definitions and links. This page is meant to give a subjective interpretation as part of ZopeInAnger.

ZCML you need to configure the webserver and set user/role permissions - which is unavoidable. The ZCML can be confusing, in particular as it uses dotted path conventions and not all tags make sense from day one. Read the ZCML API carefully -it packs a lot of power for binding components.

ZODB the ZOPE Object Database is truly wonderful. There is no need to study it, as it is pretty transparent to ZOPE objects. Essentially it stores all objects as you create them and allows for querying and finding objects through so-called factories. The root of the (locatable) objects can be found through (guess) root.

[ZMI]? the ZOPE Management Interface allows for accessing ZOPE objects/interfaces through a web interface. Less important than in ZOPE2 - but very useful as interfaces expose their workings as documentation - and allows for manipulation of those same objects. Meanwhile do not think the ZMI is ZOPE. It is merely a convenience that is tightly integrated with the architecture of ZOPE. But it is quite possible to not use the ZMI - in general.

[Zope FTP]? ZOPE FTP allows for putting and getting textual representations of objects stored in the ZODB (as long as they are locatable). It is definitely a feature of great convenience. One can use ncftp/ncftpget/ncftpput utilities or the midnight commander (mc) - usually on the same localhost. ZOPE FTP is not a complete implementation - so you see errors/warnings sometimes. But in reality it works rather well.

ZPT Zope Page Templates allow for writing HTML pages quickly by providing a template language that fetches parameters/iterates over Python/ZOPE objects. Unlike Rails - which uses Ruby - it demands the programmer to master a different language/syntax. The advantage is that ZPT is XML compliant and pretty easy to learn. Also for webmasters knowing nothing of Python. The only annoyance is that (unlike the also XML compliant ZCML) it uses no dotted path notation. Try and avoid embedding Python in ZPT.

[Skins]? are a powerful concept in ZOPE3. You can take an existing skin (like the Rotterdam skin) and override it by stacking yours over it. Like the ZCML study skins carefully before starting a project (or implement one early) as it allows for saving of work. Skins are important!

[Formlib]? generates forms from the schema's you define. A schema is (part of) an interface definition and tells Formlib how to treat the data of an interface. An automated form can save a lot of work!

[Unit tests]? you need when you start to develop your own components. It is best practise to develop unit tests for all your code (as is prescribed by, for example, extreme programming). As Python is not a strict programming language unit tests are extremely useful signalling problems with parameter passing and method behaviour. But just to be clear, it is not obligatory to write unit tests (unless you wish to submit code to the main ZOPE source tree). Usually it is possible to write unit tests without bringing up the full ZOPE framework.

[Doc tests]? are (usually) nicer unit tests as they double as documentation. In the ZOPE3 source tree you'll find many doc tests really documenting how the components work. Apart from reading the source code check out the accompanying docstests. Important.

[Functional tests]? are used often in the component framework as they allow for integration testing and functional testing of generated web pages. Unfortunately they are slow to execute (they need ZOPE to be up) and tedious - and often brittle - to write. Depending on your needs they can be very useful, but initially it may not be worth getting in to.

Baiju compiled a page on the Component Architecture.

etc. etc.