This term I started my work as the back-end development intern. I dove into plugin development for content management systems, specifically WordPress and Omeka. I was able to gain lots of experience learning and coding in PHP, and better understand the capabilities of the language as a back-end development tool. Before starting plugin development, I had to familiarize myself with both WordPress and Omeka, which involved installing and setting up instances of both on my local MAMP environment, and playing around with the admin sides of both sites. Halfway through the term, I was also able to upgrade our omeka-development server to the latest version of Omeka so that we could test the new AccessibilityPlus features, which was great server administration experience for me. I also watched lots of tutorials on how to build websites with WordPress, and to learn how the WordPress code itself is structured and how plugins fit into it.
Once I was prepared to start coding, I learned that plugin development for content management systems is a fun and rewarding process, after an initial learning curve. Understanding how plugins fit into the regular processing of a CMS like WordPress using hooks and filters was a new kind of programming for me, and definitely took some getting used to. It was disorienting but also refreshing to not have to code every piece of functionality from scratch, but rather just use all of the functions and variables that already exist within the plugin’s environment. It makes the plugin code seem deceptively simple, because the real work is figuring out exactly which hooks or filters you want to use, which arguments you want to modify, and how built-in functions can make your life easier.
I created a simple heads up display that appears on the dashboard of your Omeka site and displays information about the number of exhibits and pages on the site.
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. Hooks are events that fire at specific points during the system’s processing, and they are used by the plugins to perform additional processing at those points. 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. They can be used to add content to a page 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 was pretty straightforward once I understood the basic structure of how plugins work.
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. When developing for WordPress, it was easy always easy to Google an issue and quickly find either a section of the WordPress Codex, a forum post or some other resource that answered my question. When working on the Omeka plugins, on the other hand, usually I had to answer my 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 was usually not terribly difficult to figure out what a function did or what kinds of data were contained in an object.
Over the course of the term, I created a simple heads-up display plugin for both WordPress and Omeka, that each display relevant information about your site. Coding a similar plugin for each CMS side by side allowed me to compare the structure, environment, and documentation surrounding plugin development for both WordPress and Omeka. I also fixed bugs for and extended the functionality of our AccessibilityPlus Omeka plugin. With these changes in place, AccessibilityPlus works with Omeka 2.7, and we should be able to move forward with our contacts at NYU who are putting the plugin to use.
This is the new AccessibilityPlus settings page that I updated to manage the new features for the plugin.
