May 11th, 2010 § Wayne Graham
Stemming from a Twitter conversation last month, I thought it would be a good idea to describe — in more than the 140 character bursts that Twitter allows — why we at the Scholars’ Lab often promote Ruby, opposed to one of the other 4 or 5 languages we develop with. This isn’t an attempt to declare one language “the best,” but is meant to lay out some of the fundamental reasons why we use Ruby in the context of our digital humanities work and why we think it’s a nice language to suggest to folks just starting to program. » Read the rest of this entry «
April 20th, 2010 § Wayne Graham
If you’ve done much web development, you’ll know that deploying applications can be a real pain. Typically you get some code (like Omeka), FTP it to your server, run the install, then go grab some plugins and themes and FTP them to your server. If you’re a bit more sophisticated, you may have put this in to an source code management (SCM) system like git, mercurial, or subversion, which then changes your workflow to editing on your local machine, committing the changes to your SCM, logging on to the command line interface for your server, running an update on the code, praying nothing breaks; if it does, you then try to roll back to a working version (you remembered to run svn info on the code before updating so you know what number to go back to). Even if everything goes swimmingly, that’s a lot of steps and way more applications than I like to fool with, and since it’s essentially doing the same thing over and over again, wouldn’t it be nice to automate this process? » Read the rest of this entry «
April 14th, 2010 § Wayne Graham
As part of our ongoing efforts on our Neatline grant, we needed to include a way of displaying temporal information and interacting with other data stored in Omeka. Just about the time we were starting to write this code, CHNM announced their Plugin Rush which pays an honorarium to give folks some incentive to pitch in and develop a plugin or two. Since we were going to develop the plugin anyway, we’re donating this back to the Omeka project, but we thought this might be a good opportunity to talk a little more about the development cycle for Omeka plugins, and hopefully inspire others to get involved. » Read the rest of this entry «
December 16th, 2009 § Wayne Graham
This issue came up for a friend of the Scholars’ Lab today on Twitter, but it’s hard to answer in 140 characters. It’s a question about allowing for larger file sizes in Omeka and there are a few ways to handle this. (Because we want our new blog to be a combination of thoughtful essays on digital scholarship and quick answers to real-world technical problems, I thought I’d post here.)
Since Omeka runs on PHP, this is actually a PHP configuration issue and not something you can currently tweak in Omeka. Basically, you just need to tell PHP to allow larger files sizes that are larger than the default. A very easy way to do this is to edit the .htaccess file that Omeka ships with along the following lines:
php_value upload_max_filesize 20971520
php_value post_max_size 20971520
I’ll note here that doing things this way only affects your Omeka project. Another way to go about this is to add the above to the Apache configuration that defines from where Omeka should be served. For example:
<VirtualHost *:80>
ServerName www.coolomeka.org
DocumentRoot /var/www/omeka
<Directory "/var/www/omeka">
Options FollwSymLinks
AllowOverride All
Order allow,deny
Allow from all
</Directory>
ErrorLog logs/omeka_error_log
TransferLog logs/omeka_transfer_log
php_value upload_max_filesize 20M
php_value post_max_size 20M
</VirtualHost>
Lastly, you can edit the php.ini file (usually in /etc/php.ini or /etc/php5/apache2/php.ini). Just do a search in the file and change the following settings:
memory_limit = 32M
post_max_size = 20M
upload_max_size = 20M
You typically don’t need to reload Apache (as long as you did not edit the Apache configuration file) to get these settings to work.
For more info on this, check out these resources