Imported from Trac ticket #847 reported by jboggs on 2009-11-03:

We currently set, for example, the width and height of files to specific sizes, depending on what their file type is, instead of relying on the default width and height for the file itself. This is a problem if a movie's dimensions are 300px wide by 600px tall; the display_file helper distorts the movie. Passing 'width' => '', 'height' => '' to the properties array doesn't work, because it still uses the hard-coded width and height in the Media helper.

We should use the file's properties for width, height, and other relevant properties when displaying the file whenever possible.

Imported from Trac ticket #351 reported by kris on 2008-02-20:

Roles and privileges in the ACL are now hard-coded in Omeka, to reduce the need for writing data migrations as the permissions requirements change over time.

Now that permissions are stable, these hard-coded lists should be transferred to the database in the form of 3 tables:

roles, privileges, and roles_privileges (join table)

each table should have ID, role name (or privilege name), and possibly a description field.

In order to avoid pulling down the entire contents of 3 databases for every request, the entire mess should be pulled down only once and stored in a session for each user who accesses the site. Or alternatively we can cache this data if we have a caching mechanism available.

Imported from Trac ticket #1007 reported by wsg4w on 2011-01-21:

The default MySQL engine is generally fine, but the InnoDB engine has some much better features for OLTP (better locking, etc.). Attached is a patch to change the default database engine to InnoDB, as well as add indexes to just about everything that is queried by core.

Imported from Trac ticket #620 reported by jsafley on 2008-12-12:

I have the following code in plugin.php:

<?php
add_filter('custom_filter', 'plugin_custom_filter_foo');
add_filter('custom_filter', 'plugin_custom_filter_bar');

function plugin_custom_filter_foo($array)
{
    $array['foo'] = 'foo';
    return $array;
}

function plugin_custom_filter_bar($array)
{
    $array['bar'] = 'bar';
    return $array;
}

And in the plugin's controller I have the following code:

<?php
$array = array('baz' => 'baz')
$array = apply_filters('custom_filter', $array);
print_r($array);

The resulting, filtered array is as follows:

Array
(
    [baz] => baz
    [bar] => bar
)

I was expecting the following array:

Array
(
    [baz] => baz
    [foo] => foo
    [bar] => bar
)

It seems that subsequent add_filter() calls overwrite the previous call. Or, within the plugin.php file, the plugin API and/or the filter architecture only allows one add_filter() call to every filter.

Imported from Trac ticket #490 reported by kris on 2008-09-22:

The data retrieval helpers like get_item_by_id() and get_items(), etc. should be available to plugin writers so that they can be used outside the scope of view scripts. All of the helper functions in the application/helpers directory are meant to be called in view scripts, but since there are no requirements for use of get_item_by_id() other than that the database and ACL are properly loaded, there is no reason why these functions shouldn't be available for use in various plugin hooks that are not related directly to view scripts.

Imported from Trac ticket #1012 reported by jboggs on 2011-01-27:

Since Omeka brands itself as a "web publishing system," it seems to make sense that we provide a date when items are actually made public. We currently have two timestamps for items: Added and modified. Neither of these clearly indicates when an items was actually made public.

Imported from Trac ticket #843 reported by jboggs on 2009-10-25:

The current implementation of the nav() helper does not allow for additional attributes on either the li tag or the a tag. The 'class' attribute is hard-coded on the li tag (and is the only attribute), and the a tag only uses the href attribute.

We should provide arguments in the nav() helper to allow for additional attributes. The recently-developed AccessKeys plugin, for example, could use this added functionality to add the accesskey attribute directly to the primary navigation links, instead of creating separate, empty a tags with this attribute that replicates the primary navigation.

Imported from Trac ticket #409 reported by jsafley on 2008-06-04:

Currently we use a custom flash messenger action helper that does not extend Zend's FlashMessenger. This is because Zend's helper does not distinguish between error and non-error messages. Nevertheless, it is better to extend Zend's helper and add functionality by overwriting certain methods.

See: http://framework.zend.com/manual/en/zend.controller.actionhelpers.html#zend.controller.actionhelpers.flashmessenger

Imported from Trac ticket #1040 reported by kris on 2011-02-18:

When the naming of archived files changed to randomized 32 character ascii filenames, the change was not retroactive. Files uploaded before that time retain their old names, which consisted of a "sanitized" version of the original filename with a short string of random characters appended.

These files ought to be renamed under the same logic as the original filenames. That line of logic includes: security (filenames are dangerous user input), consistency, and issues with non-ascii filenames.

This fix was also never applied to files uploaded during theme configuration, so those filenames need to be fixed regardless of what happens with this ticket.

The main problem with renaming files that are already publicly available is that it breaks URLs to files on existing (older) installations. A counterpoint might be that it is rarely a good idea to hardcode references to dynamically stored data, nor is it particularly good in many cases to allow inline linking or direct bookmarking of files, as it tends to be a bandwidth burden.

Such a fix may or may not make it into trunk, but should be done on omeka.net either way, as it will only affect a relatively small number of files.

Imported from Trac ticket #941 reported by jflatnes on 2010-06-03:

The current plugin architecture encourages an unnatural mix of object-oriented and procedural code.

Transitioning from the current system to one where plugins must be classes will potentially eliminate some current odd behaviors.

'''Details of architecture (as I see it):'''

• The structure of folders with the name of the plugin will remain the same.
• Within each folder, there will be a .php, which contains a class
  • This class will extend an Omeka_Plugin_Abstract class or implement an Omeka_Plugin_Interface.
• Hooks and filters
  • Currently, we have several hooks that operate on a plugin-specific basis (install, uninstall, initialize). Converting these to required instance or static methods of the plugin class would eliminate the confusion between different hook/filter types
  • The remainder of the hooks and filters would essentially remain the same, except that add_plugin_hook/add_plugin_filter calls would be all contained within one specific method, say addHooksAndFilters(). This lets us avoid mixing procedural code in with our plugin definitions, which causes the cited problem with testing.
  • The add_plugin_hook and add_plugin_filter functions could be converted to methods of the abstract plugin class.

'''Benefits:'''

• We avoid the current practice of namespacing a whole bunch of functions by prepending the name of the plugin to each function name.
• Fixes a current problem/annoyance with hooks and filters when testing.
• Would allow globally-useful functions for plugins to be members of the parent abstract class.
• Plugins which define theme helpers could still do so, by including another file which defines the functions.
• Should be a relatively painless port for most plugins.

'''Disadvantages:'''

• Incurs at least minor changes in every plugin.

Imported from Trac ticket #972 reported by jflatnes on 2010-09-28:

The Files form is hardcoded to echo the forms for only the Dublin Core and Legacy element sets. It should instead check for all element sets that apply to Files, and display forms for those.

Imported from Trac ticket #973 reported by jflatnes on 2010-09-29:

Right now, we include all possible plugins in the script paths all the time, allowing the possibility that one might want to use a view or asset on any page through a hook.

This has the effect of meaning that views and assets used in this way actually need to be uniquely named across all plugins, since we can't predict what order the paths will be in.

An alternative: instead of adding the paths for all plugins all the time, only add those paths that are actually necessary (core and theme paths for core controllers, core, theme, and plugin paths for plugin controllers), and then, upon calling a hook, add the script paths for that specific plugin that is executing the hook.

Imported from Trac ticket #857 reported by jboggs on 2009-11-17:

The link to files currently uses the Original Filename field for the link text. We should try to use the Title field for the file first, if the user enters a value for it, so users can customize the link for each file.

Imported from Trac ticket #566 reported by jsafley on 2008-10-20:

The general utility of entities/relations is under question as a core part of Omeka. It's great to record the date an item was added, the entity who added it, the date an item was modified, and the entity who modified it. But an audit trail of all modifications to an item seems better suited for a plugin.

Instead we should simplify this process by, one example, recording the date added, the ID of the user who added it, the date last modified, and the ID of the user who last modified it in the item table itself. In other words the entities/relations tables should somehow be deprecated in favor of a streamlined process.

See the following (invalid) ticket for more information:
https://omeka.org/trac/ticket/491

Imported from Trac ticket #1037 reported by kris on 2011-02-14:

There is currently no way to share validation error messages between Zend_Form implementations, so there tends to be some duplication across the forms, e.g. the simple phrase "Invalid email address" must be typed in for each form that makes use of the Zend_Validate_EmailAddress validator. Since there are 9 different error messages for EmailAddress alone, this amounts to significant duplication.

Potential ways to reduce this:

1. Create custom Zend_Form_Element subclasses that encapsulate the entire form element configuration, including error messages. This may be overkill and may also be fragile.

2. Zend Framework documentation (1) suggests using Zend_Translate_Adapter and providing translations for the default error messages. There are a couple of problems with this: aside from the added overhead of uncached translations, it adds an extra step for future internationalization efforts, i.e. whether to just translate the message itself or to translate the translation.

Imported from Trac ticket #1038 reported by jboggs on 2011-02-14:

We should allow theme writers to specify the media handler for displaying a particular file. This could go in the options array that already exists for display_files() helper. An option called 'callback' or 'handler', with a value of a function would suffice.

This would be very useful when our automatic display of files based on the MIME type doesn't work for particular files.

Imported from Trac ticket #848 reported by kris on 2009-11-05:

Theme helpers are currently split up into different files based on loose categorization such as "ItemFunctions" or "LinkFunctions". This was supposed to make it easier for developers to locate helper functions, but it fails in that respect because the categories are arbitrary. For example, should a function that creates a link to an item be in "ItemFunctions" or in "LinkFunctions"?

In order to make this less confusing, the best solution would be to put all theme helper functions into one file, sorted alphabetically.

Helper functions must be in a single file because the dependencies between various helper functions are not clearly defined. The only advantage to having these in separate files would be for performance reasons, e.g. in the event that a theme developer could use the "ItemFunctions" without also needing to include the "LinkFunctions". As this is currently not possible, it calls into question the efficacy of having these functions live in separate files.

Imported from Trac ticket #864 reported by kris on 2009-12-04:

For reference, the table alias corresponds to the u in the following example query:

SELECT `u`.* FROM `omeka_users` AS `u` WHERE `u`.username = 'foo'

Table aliasing is important in that it allows query writers to avoid having to write out the table prefix when writing SQL queries. For example, coding the above query without aliasing would require something like the following:

$sql = "SELECT `{$db->User}`.* FROM `{$db->User}` WHERE `{$db->User}`.username = 'foo';

The current behavior of Omeka is to assign a default table alias consisting of the first letter of the model name, e.g. 'i' for items, 'u' for users, etc. This convention falls apart when SQL queries require joins between multiple models with the same first letter. The current workaround is to define a unique alias, like if joining UsersActivations against Users, the former might be assigned an alias of 'ua' to avoid conflicts.

This pattern actually hampers rather than improves usability for two reasons:

• makes it difficult to predict what aliases are used for which tables
• since MySQL requires that queries use an alias if one has been defined, it actually requires that query writers do significant manual debugging to ensure that the queries are coded correctly. This reduces extensibility by making the SQL writing process non-intuitive.

The proposed solution involves making the alias into the table name. This would result in queries that look like the following:

SELECT `users`.* FROM `omeka_users` as `users` WHERE `users`.username = 'foo'

The advantage to the above is that query writers do not need to make sure that the database table prefix is hard coded into their queries. It also marginally increases the text size of the query, has no effect on query performance, and vastly increases the readability of SQL queries for plugin writers and core developers.

Breaks backwards compatibility with nearly all plugins that involve custom SQL queries, so is marked for 2.0 release.

Imported from Trac ticket #932 reported by jboggs on 2010-04-26:

Currently the show_empty_elements option only governs elements for items. It should also cover elements for collections, and possibly other types of records (like Exhibits).

Imported from Trac ticket #1023 reported by jboggs on 2011-02-02:

Update the admin interface, keeping the following in mind:

• Convert to HTML5 and CSS3 where appropriate.
• Implement a fluid layout. Removes limitations/issues with fixed widths
• Vertical orientation for main navigation to removes issues with adding buttons to its current horizontal design (width, number of buttons, etc).
• Ensure the admin panel is usable from a variety of devices.

Imported from Trac ticket #882 reported by kris on 2009-12-22:

This refers to a type of design flaw in which exceptions are thrown to indicate failed validation of forms and/or models being saved.

Commonly-held design principles indicate that exceptions only be thrown for conditions that are uncommon or unlikely, e.g. failure to connect to the database, logical errors made by plugin or theme writers, etc. On the other hand, common or expected situations, such as forms failing to validate, should not result in thrown exceptions. For more information on why this is bad, google "exceptions control flow" and read some of the extensive literature on the topic.

Omeka violates this principle primarily with respect to validating forms and saving models to the database. At least two methods in Omeka_Record are designed to throw exceptions:

• Omeka_Record::saveForm() will throw an exception if the form submission failed to validate.
• Omeka_Record::forceSave() will throw an exception if the record failed to save properly.

In addition to that, most of Omeka's controller actions are designed to explicitly catch the exceptions thrown by these methods and use it to flash form validation errors.

For example, Omeka_Controller_Action::addAction() contains the following code:

try {
    if ($record->saveForm($_POST)) {
        $successMessage = $this->_getAddSuccessMessage($record);
        if ($successMessage != '') {
            $this->flashSuccess($successMessage);
        }
        $this->redirect->goto('browse');
    }
} catch (Omeka_Validator_Exception $e) {
    $this->flashValidationErrors($e);
} catch (Exception $e) {
    $this->flashError($e->getMessage());
}

The problems with this design are many:

• always flashing an exception error message on a form, as opposed to allowing it to bubble up to the main error handler, makes it so that developers cannot debug the various types of exception messages that might arise.
• it always flashes every exception message back to the form when it may in fact be inappropriate to display these messages to users (security reasons or otherwise).
• exceptions that are being flashed back to the user are not being logged. If allowed to bubble up, these exceptions would be automatically logged.

The ideal solution would be something simpler, like:

if ($record->saveForm($_POST)) {
    $successMessage = $this->_getAddSuccessMessage($record);
    if ($successMessage != '') {
        $this->flashSuccess($successMessage);
    }
    $this->redirect->goto('browse');
} else {
    $this->flashError($record->getErrors());
}

Omeka_Record::forceSave() should continue to throw an exception when a record fails to save properly, but it should not be used to indicate failed form validation. If used properly, forceSave() is primarily a tool for developers to catch logic errors in plugins before such errors present to the user of the plugin. Following is an example of incorrect usage:

try {
    $record->name = $_POST['name'];
    $record->forceSave();
} catch (Exception $e) {
    $this->flashValidationErrors($e->getMessage());
}

Here is a better example of how it might be used:

if (!$this->_validateName($_POST['name'])) {
    $this->flashValidationErrors("Name is not valid.");
    return;
}

// No validation errors can occur at this point.
// Only something catastrophic would cause this to fail.
$record->name = $_POST['name'];
$record->forceSave();

This is marked for 2.0 because changing the behavior of Omeka_Record and Omeka_Controller_Action will create incompatibility with existing plugins, including the way that plugins can currently invalidate a form submission by implementing a 'before_save_form' hook that throws an exception. There may be other incompatible changes required to implement this.

Imported from Trac ticket #1018 reported by jboggs on 2011-02-01:

Our current system for user roles and permissions is very rigid. We should add some methods and interfaces for creating user roles, managing their permissions, etc.

Imported from Trac ticket #1025 reported by jboggs on 2011-02-02:

Given the degree to which people would like to customize the display of theme content, we should develop widgets for various pieces of content, that can be organized by view from the administrative panel. Some examples:

• Organize/add/remove content on the homepage.
• Display item metadata and files, to specify display of certain fields or elements sets, and their order.
• Widgitize the navigation, so users could more easily add/remove/reorganization the main navigation. Could also have widgets to add any random navigation, like in the footer.
• Widget for a random text or content block. Use this instead of relying on the theme configuration to add, say, an introductory text on the homepage.

This would also make it easier for users to organize content added by plugins, instead of relying on hooks placed in specific spots in theme files.

Should likely be completed after #1023 is completed.

Imported from Trac ticket #1009 reported by jboggs on 2011-01-24:

One common request is to hide or remove certain fields from Dublin Core element set when adding items. While we shouldn't actually delete fields, we could find a solution for managing display of specific fields from the administrative panel.

Accomplishing this would require some way to filter the display of the entire element on the form, and not just the input for the element.

Imported from Trac ticket #668 reported by kris on 2009-03-05:

Blocked by/dependent upon #642.

The current behavior of the Omeka_File_Transfer_Adapter_Url class is to derive the filename from the URL that is passed in. For instance, ingesting 'http://www.nytimes.com' will provide the original filename as 'http://www.nytimes.com' (correct), but it will provide the archival filename as something like 'httpwwwnytimes_0402e7d4e8.com'. Note the .com extension, which tricks the browser into thinking that the file does not contain HTML.

Thus the Omeka_File_Transfer_Adapter_Url class should try to detect the Content-Type of the file and provide the appropriate filename. The down side to this would be that the original filename would be instead be listed as 'http://www.nytimes.com.html'.

The other alternative is that the archive filename renaming filter (Omeka_Filter_Filename) could try to detect the MIME type of the file and rename it accordingly so that it displays properly in the browser. That might be a better solution because then all subsequent transfer adapters would not have to rely on the same MIME type detection code.

Imported from Trac ticket #572 reported by jsafley on 2008-10-27:

The config plugin hook should not have the $_POST passed to it. This is redundant and stupid:

add_plugin_hook('config', 'example_plugin_config');
example_plugin_config($post)
{
    set_option('example_plugin_input', $post['input']);
}

Should be:

add_plugin_hook('config', 'example_plugin_config');
example_plugin_config()
{
    set_option('example_plugin_input', $_POST['input']);
}

Imported from Trac ticket #992 reported by jflatnes on 2010-12-17:

People are often unaware that an Omeka login persists from the admin to the public side.

Something like a bar across the top that shows the current user and has links to the admin side and to logout could be displayed when a user is logged in.

Among other things, this should help short-circuit all those people on the forums who are doing cross-browser testing with private items.

Imported from Trac ticket #1022 reported by jboggs on 2011-02-02:

Add methods for users to install and update addons directly from the Omeka admin interface.

This would involve checking the Omeka.org site for available plugins and themes, sorting based on minimum required versions of Omeka. Omeka.org would need to provide a JSON output of available addons that could be parsed by individual Omeka installations.

This feature would require that the plugins and themes directory be writable by the server, and that the server could unzip files. If either of those requirements is not met, the install/update option would not be available.

Imported from Trac ticket #1039 reported by jboggs on 2011-02-14:

We should provide a way for theme developers to find out which callback a particular file will use. That way, developers could pass options to display_files() helper based on whether the file will be displayed as 'audio', 'image', 'mov', 'wma', or 'wmv', instead of checking against dozens of different MIME types.

Imported from Trac ticket #1015 reported by wsg4w on 2011-01-31:

I couldn't figure out how to split tickets in trac, but I'm reworking the creation of indices that was included in patch 1007 (https://omeka.org/trac/ticket/1007) to switch the database engine to innoDB. The creation on indexes was hard-coded in to the SQL which would only provide these indices for new installations. This patch uses a migration to add indexes to existing tables, with an eye toward indexing fields that do not have key constraints.

I am in the process of generating fixtures to simulate this on a large Omeka collection (need to ensure the migration will not time out) with DBUnit (will release code for that).

Imported from Trac ticket #876 reported by jsafley on 2009-12-17:

Currently when updating an item, the process deletes all the element texts and then reinserts them. While straightforward to program, this breaks referential integrity, preventing features like relationships between element texts and direct linkages to element texts. Instead of deleting and reinserting element texts, we could update them to maintain referential integrity (ID persistence).

Imported from Trac ticket #776 reported by kris on 2009-06-01:

To reproduce, attempt to add a user with a name that already exists. The resulting form (with a validation error message) will also display the users table as empty and say that there are no users.

This happens because Omeka_Controller_Action::browseAction() makes use of all parameters passed to the request, not just the GET parameters. The POST contains 'active' and 'status' keys, which indicates to the search filters that the number of users to display should be based on those values.

This indicates a minor design problem with browseAction(), where it should only look for GET parameters instead of also examining POST parameters. This would be in keeping with REST principles that GET should be used for retrieving data and POST only for modifying.

Imported from Trac ticket #965 reported by kris on 2010-09-21:

Table classes (extend Omeka_Db_Table) that override applySearchFilters() should be using class constants instead of strings for parameter keys.

For example, code like the following:

#!php
public function applySearchFilters($select, $params)
{        
  if(isset($params['public'])) {
    $this->filterByPublic($select, $params['public']);
  }
}

Should actually look more like the following:

#!php
public function applySearchFilters($select, $params)
{        
  if(isset($params[ItemTable::PUBLIC])) {
    $this->filterByPublic($select, $params[ItemTable::PUBLIC]);
  }
}

This sort of thing is viewed as a best practice to prevent typos during development and to make it easier to refactor in the future if necessary.

Imported from Trac ticket #1032 reported by wsg4w on 2011-02-09:

I've expanded the .htaccess file quite a bit to provide the following:

• Provide more granular control over expiring content types (much more targeted)
• Remove ETags
• Force IE to not fall back to previous versions for rendering HTML
• Stub for cross-domain ajax requests
• Allow access for web-fonts
• Provide proper mimetypes for web files
• Prevent CSS flicker in IE for CSS rollovers
• GZip compress content (if mod_deflate is available)
• Force UTF-8 encoding for appropriate mime types and file extensions
• Ensure 'hidden' files (e.g. .svn) are not available

While most of these settings ''should'' be in the httpd.conf, those on shared hosts may not have access to these settings (or unaware they should set them).

Imported from Trac ticket #978 reported by jflatnes on 2010-10-13:

Exceeding the POST size for an item save (basically means you had a large item) causes the update to fail, but we print no error to the user.

Imported from Trac ticket #964 reported by kris on 2010-09-21:

Method signature for TaggingsTable::findBy() is different from all other tables' findBy() methods. This is a design flaw and could lead to developer confusion. Solution is to refactor this method into an implementation of applySearchFilters() so that the behavior of this class will match the other table classes.

May cause a small BC break for plugins that rely on the existing method signature.

Imported from Trac ticket #849 reported by kris on 2009-11-05:

Zend Framework supports grouping application code into modules to create what amounts to sub-application within the context of the larger application.

Omeka currently has a single set of controllers to handle both administrative and public interfaces. The net effect of this is to mirror the application structure for public and admin interfaces. In other words, you can perform any action via the public site that could be done in the admin (subject to permissions checks).

This has been useful when developing Omeka plugins and customizing themes, but there are some downsides to this approach. The main disadvantage is an increased potential for security flaws: if an action that manipulates sensitive data is added to any of the controllers, it must also be added to the ACL list at the same time. If not added to the ACL, it could be used in an attack by a non-authenticated user via the public interface, because all controller actions are exposed to the public interface.

A solution to this would be to separate the admin and public into modules, essentially making each a self-contained application. The problem of overlapping actions would be solved by having the admin controllers inherit from the public controllers where applicable.

For example, the public/ItemsController might have 'browse' and 'show' actions, and the admin/ItemsController would inherit from that and extend it with 'add' and 'edit' actions.

Imported from Trac ticket #571 reported by jsafley on 2008-10-27:

The exec() function is an alias for the more common, Zend compliant query() function. All instances to exec() in the code should be replaced with query().

Imported from Trac ticket #670 reported by kris on 2009-03-05:

There should be more options for update_item() that make it possible for plugin writers to remove or replace existing data like tags and files. The scope of what update_item() should be able to do is TBD.

Imported from Trac ticket #894 reported by kris on 2010-02-08:

head() and foot() are currently used to insert header/footer HTML into views. This is a redundant implementation of Zend Framework's perfectly good Zend_Layout component. In addition to being well-supported, more flexible, and more powerful than the current solution, Zend_Layout allows for a single view script to encapsulate an entire layout, which will result in simpler theme design (easier to prevent mismatched tags) as well as being more readable and maintainable.

Imported from Trac ticket #642 reported by kris on 2009-01-23:

The File::getMimeType() method should return the most accurate MIME type that is available for a given file.

Currently it just returns the MIME type that was detected by the browser (stored in the mime_browser column in the files table).

That MIME type can occasionally be ambiguous though, which is why the MIME type is also retrieved via the mime_content_type() function (stored in the mime_os column).

Yet a third MIME type value can be obtained from the getID3 library, though this is not stored in the database.

The getMimeType() method does not check all of the retrieved or available MIME type values, which can lead to ambiguities and unexpected behavior when displaying files within Omeka, as helpers like display_files() and parts of the plugin API like add_mime_display_type() depend on correct detection of MIME types for files.

This is a blocker as those helpers can't be expected to behave properly in all cases until this is fixed.

A partial solution would be to modify getMimeType() to check through all available MIME types for a unambiguous one, though may be too expensive to set up getID3 for every request to display a file.

A better solution would be to determine the unambiguous MIME type during file upload and store that in a column in the database. That would make MIME type retrieval less ambiguous overall.

Imported from Trac ticket #353 reported by kris on 2008-02-21:

As one of our most recent software reviewers was kind enough to point out, our present form of name storage (first/middle/last) does not carry over well to other cultures. So instead, we should migrate existing data to a single 'full name' field as well as offering users/entities/whatever an opportunity to provide a preferred form of address.

This also obviates the need for an 'institution name' field in the entities table, as that can also fall under full name. I'm not sure if there are any real problems with this approach, but the benefits for the international community probably outweigh the drawbacks.

Imported from Trac ticket #534 reported by kris on 2008-10-07:

Seems pretty reasonable that users would want to have access to HTML besides bold/italic/underline and different kinds of headings, so they need to be able to modify the default WYSIWYG editor settings (either via plugins or via the admin interface, though modifying it makes more sense on a project-by-project basis than it does as a plugin).

Imported from Trac ticket #883 reported by kris on 2010-01-06:

This singleton perpetuates the same problems as Zend_Registry: it introduces mutable global state, which increases the difficulty of debugging code, makes it more difficult or impossible to test, generally reduces reusability of code that is written to depend on those singletons.

That said, it provides no significant advantages over Zend_Registry, which does the same thing and happens to be built into Zend Framework. In fact, Zend_Registry is used in many places when global state is "necessary" but adding new methods to Omeka_Context is deemed inconvenient, which is pretty much all the time.

The likely solution involves removing all references to Omeka_Context and removing the class itself. A corollary involves removing as many references to Zend_Registry as possible. Resources that are commonly needed by plugin writers should still be available as entries in Zend_Registry.