Developer Transitioning from Wordpress

[Walkingmiller]

Hello! I am a Wordpress developer, and one of my clients has said that they are interested in creating an "Institutional Repository" in Omeka. I have looked over the documentation, but I wanted to hear other people's thoughts. I am mainly a front-end developer (html, css, javascript, some php) who has quite a bit of experience with Wordpress. Any thoughts on how difficult it will be for me to develop a custom Omeka site? Are there significant limitations that I should be aware of before jumping in? Anything else that would be good to know in the beginning? 

Thanks for your help!

walkingmiller

[Patrick Murray-John]

Walkingmiller,

Interesting question! I hope lots of people will jump in with their thoughts. I hope this will be a rich thread that we can distill into a basic response in our documentation.

On the PHP side, some concepts, like 'the loop' will be recognizable in Omeka's structures (see functions like 'set_loop_records', 'current_record'). A major difference, though, is the many different record types that could exist in an Omeka site, where you will find 'Items', 'Collections', 'Simple Pages', and many more. Omeka 2 did a great job of normalizing the patterns for working with them, but you will see more than 'pages' and 'posts' ala WordPress.

So, in general, lots of the same skills from WordPress will apply. For CSS styling, the classes will be different, of course, and reflect the different record types in places.

Some things that Omeka doesn't have that might be familiar are the different ways of inserting new templates into different parts of a theme. We also don't have the concept of a subtheme, except for default views that most themes just style differently.

It's also worth noting that the jobs of plugins and themes are kept a bit more distinct in Omeka, so generally a theme doesn't add new functionality.

As afar as good-to-know things, this probably moves much more into the PHP side, but Omeka is built on the Zend Framework, so reading their intro documentation, especially about the MVC pattern, might be helpful.

The question of how difficult it will be to develop a custom Omeka site is pretty hard to respond to directly without knowing details of the customization. If you are talking about a theme that just uses existing plugins, that should be pretty straightforward. If the customization calls for new workflows, functionality, relationships between record types, etc., then that's wide open, especially since IRs tend to have a lot of different requirements. I'd say trying to get details about the specs as early as possible would be best.

Hope that helps,
Patrick

--
You received this message because you are subscribed to the Google Groups "Omeka Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to omeka-dev+...@googlegroups.com.
To post to this group, send email to omek...@googlegroups.com.
Visit this group at http://groups.google.com/group/omeka-dev.
For more options, visit https://groups.google.com/d/optout.

[Erin Bell]

Hi, here are a couple things tips that have made my life easier as I've gotten to know Omeka. Some of these are in comparison to WordPress, but others are just general advice...

• Like WordPress, existing themes can be a really good resource for reusable code. If you're unsure how to do something, have a look at another theme or especially the default theme views in application/views/scripts. They usually have reusable code that will help clarify your issue. 
• Also note that some themes omit certain seemingly essential templates altogether, falling back to the application defaults. This can be confusing if you can't find, say, an items/show.php template in a particular theme. It just means they're using a default.
  
• The admin theme templates at admin/themes/default, as well as existing plugins, can also be useful resources for slightly more complicated issues.
• A passing knowledge of MVC and Object-Oriented PHP is very helpful, though you can get by without it for typical/basic sites.
  
• In comparison to WordPress, you're more likely to get a quick and thorough response on the Omeka forums (since it's a much smaller community). That being said, googling for help is not nearly as likely to yield helpful Omeka-specific information (outside of the forums and documentation-related results).
  
• Partials/includes can be really helpful in customizing the items/show.php template (which is the one used for all item records). Work with your client to find out what kind of content they'll be publishing and how they want it displayed. Chances are they have different expectations for different types of content. Unless you're using the default file helpers (e.g. files_for_item()) and a very basic layout, it's often helpful to have an if or switch statement that loads a custom template for, say, a PDF or a video or a specific item type (example). You could always keep all of them in items/show.php, but as clients ask for more customization, it can start to get pretty hairy.
• Plugin views often need some customization to better integrate into a custom theme. Basically, you just create a directory in your theme for any plugin that contains customized views. See details here: http://omeka.org/codex/Theming_Plugin_Pages 
• I like to hide all the geeky librarian stuff by default (I'm a librarian myself, but few users really know or care what "Dublin Core" is) and present the essential information in a cleaner, more intuitive manner. See for instance the "Show Complete Metadata" button on this site: http://voices.clevelandhistory.org/items/show/54 
• Also, it helps if someone on your team is familiar with metadata standards like Dublin Core. You'll want to be sure to structure data according to common conventions used by libraries and archives. Most clients using Omeka have some experience with this so lean on their expertise.

Anyway, those are just a few tips off the top of my head. Hope it helps a bit.

Cheers -- E