Zotero currently stores all data in a zotero directory within the Firefox profile directory.

Zotero is one of the first Firefox extensions to take advantage of the new mozStorage functionality introduced in Firefox 2.0. mozStorage is a database API backed by the SQLite database engine, offering the power of a relational database system within the Mozilla development environment. All system data and item metadata is stored in an SQLite database, zotero.sqlite, within the zotero directory. If the DB doesn’t exist at browser startup, a new one is created from the files system.sql, scrapers.sql and userdata.sql in the extension root, which are then used only during schema updates.

Also inside the zotero directory is a storage directory for snapshots and copied files, which are stored within separate subdirectories named after the id of the attachment item they belong to. Zotero also creates a copy of the Zotero database at every shutdown and stores it as zotero.sqlite.bak in the same directory.

Neither the SQLite database nor the storage directory are meant to be modified outside of Zotero itself. They can, however, be modified via the Zotero data API from within Firefox and accessed in a read-only manner using external tools, offering users and third-party developers unlimited possibilities for analyzing and extracting data.

A common problem in developing Mozilla extensions is figuring out how to pass data between different windows, which have their own scopes and do not by default share the same variables and code. While there are various mechanisms to get around this, the recommended method, and the method used by Zotero, is to use an XPCOM singleton component to store common data, which can then be accessed from any window that imports the component. (XPCOM is the cross-platform component object model—the framework—that forms the basis for the Mozilla application environment.)

The base Zotero service is an XPCOM component written in JavaScript. While normally XPCOM components implement various predefined interfaces themselves, in Zotero the data layer and most of the core functionality are stored within a JavaScript object that is then stuffed into the special wrappedJSObject property of the component. The component itself does not define any XPCOM interfaces. (This is vaguely a hack, but it addresses our needs sufficiently and is an approach used by several other extensions.) Chrome overlays and windows in Zotero import the core object via the script include.js, which calls getService() on the component and assigns the wrapped object to the variable Zotero. Zotero methods can then be called from anywhere within the window’s scope simply by calling, for example, var item = Zotero.Items.get(1).

Access to the Zotero service is not limited to Zotero itself, however. As a standard XPCOM component, the Zotero service—and, specifically, the wrapped JavaScript object—can be accessed from anywhere within privileged code, including other loaded extensions. For more, see Interacting with Zotero from Within Firefox.

See Creating Translators for Sites.

See Creating Citation Styles.

The site translators that Zotero uses to automatically save information from web pages can stop working correctly as the structure of pages change. If Zotero encounters an error while attempting to scrape a page, it will report the error to the Zotero team so that the translator can be fixed as soon as possible.

Once a day, Zotero checks with the Zotero servers for any translators that have been added or updated and updates its own database with the new translators. This allows the software to remain constantly up-to-date with changing sites and new technologies.

Citation styles can also be updated in this manner.