WordPress and Omeka are, at a high level, very similar in the way that they integrate plugins into the regular processing, and the environment they create for them. For background, the way plugin development for content management systems works is roughly as follows: The CMS itself is code written in PHP, parts of which are called every time that a request is made to the server. While the system is processing the request, it periodically makes checks to all the plugins that are installed to see if they have registered any hooks or filters. Filters are events that fire at specific points during the system’s processing, and they are used by the plugins to modify data that is moving through the system at those points. Each filter corresponds to a specific stream of data. For example, if your plugin adds metadata to every item that is saved to the database, you would register it with a filter that fires whenever data is being set to the database. Your plugin can then take that data, modify it by adding the metadata, and then send it back to the regular processing. Hooks work similarly, but they do not need to pass any data along. Instead, they fire at certain points during the systems processing and allow plugins to perform their own processing and make changes at those specific points. They can be used to add content to a page as it is being generated or create additional database entries. WordPress and Omeka both follow this general structure, but there are syntactical differences in the ways that they expect plugins to be formatted and functions to be named. Learning those is pretty straightforward once you understand the basic structure of how plugins work in both cases.
The above images illustrate some of the syntactical differences between WordPress and Omeka, specifically the way in which functions are registered with hooks.
The single biggest difference I’ve noticed between WordPress and Omeka plugin development is the level of documentation. WordPress is incredibly well documented, and perhaps more importantly, Stack Overflow questions and answers about common development issues abound. Plugin development for Omeka, especially at a beginner level, is substantially slowed by the lack of effective documentation for built-in functions, hooks, filters, and classes. The Omeka developer documentation provides a minimal reference of the objects that exist, but detailed descriptions and examples on how to use them are lacking. Often you merely find confirmation that a function you are trying to use exists, without finding any guiding information on how it actually works. When developing for WordPress, it is typically easy to Google an issue and quickly find either a section of the WordPress Codex, a forum post or some other resource that answers your question. When working on the Omeka plugins, on the other hand, you seem to usually end up answering your own questions with extensive var_dumps and echo statements. Luckily, it seems as though the core plugin functionality of Omeka, once you understand the MVC structure and some of the quirky hook/filter mechanisms, is fairly consistent and straightforward, so it is usually not terribly difficult to figure out what a function does or what kinds of data are contained in an object, you just need to be prepared to use a lot of trial and error.
Nice Post! Thanks for sharing amazing information with us!
Keep sharing…