After some Googling, I ran in to some directions on how to fix the problem for Windows users. Basically you copy the file, rename it as a zip file, expand the directory, and resize the files. On my OS X box, I resized the images with ImageOptim (I use it when I need a quick and dirty image compressor). However, when I re-compressed the files with the Compression utility, I kept getting errors in Word that it could not open the file. Again, panic and a lot of swearing (we are talking about 30 pages here).

Turns out I just needed the zip utility. I just went in to the directory that had my expanded zip files and recursively zipped all the files back in:

cd ch10
zip -r ch10.zip *
mv ch10.zip ch10.docx

I opened the file back up in Word and after some complaining that the file format wasn’t correct, the file open with all the content in it! Hopefully you will never run in to this, but if you do, the fix isn’t that difficult.

<ul>
    <li>
        <%= link_to_unless_current "Home", root_path do
link_to "Home", root_path, :class => "current"
        end %>
    </li>
</ul>

In my research, I saw different ways of going about this, but this apparently is the recommended method as it’s in the documentation (see the URLHelper).

I have to say this seems a bit counter-intuitive and not as “easy” as it should be. I kept expecting to be able to do something like:

<%= link_to "Home" {home_path}, current_page? ? (:class => 'current') : nil %>

Anyway, if you want to add a highlight class, this works.

The fix was pretty quick, but took a couple of minutes to locate. On top of installing the new package, you also need to run the vboxdrv setup to recompile the kernel module.

sudo /etc/init.d/vboxdrv setup

After you run this, everything runs wonderfly again

CoreContainer cc = new CoreContainer(solrCoreDir, configFile);
solrCore = cc.getCore(solrCorename);

Ok, so that was more of an update, but it got me to reindex the our marc content. Our 001 fields don’t always have info, so our Systems Librarian told me just to use the 035a for the id field. There was only one problem…they had a “(Sirsi)” as a prefix to the actual number. This wouldn’t be that big of an issue, but it was causing the queries sent to Solr to be off, and I wasn’t getting any results for a detail view.

Fortunately, Solrmarc already has a facility to deal with this: PatternMaps! To pull out just the number, I changed the id definition in the vufind.properties file to

id = 035a, (pattern_map.id), first

This basically maps the id field in the schema.xml file to the 035a, using a patternMap named pattern_map.id, and only takes the first of the 035a if there are multiples. I know, there shouldn’t be, but I’ve seen funky things

Now, to add the PatternMap definition:

pattern_map.id.pattern_0 = \\(Sirsi\\)\\ (.*)=>$1

It’s just a simple regex pattern definition that takes out the “(Sirsi)” and the space between it and the actual id we’re using.