In our use case Omeka is embedded in a larger website. I installed it in a folder called omeka; e.g. /var/www/omeka, and the omeka-based content is accessed as http://site.org/omeka. Now the users have decided they want a more descriptive URL; e.g http://site.org/jma-presiding-bishop
It does not seem possible to just change the folder name. I snooped through the database a little, and an absolute URL seems to be embedded all over the place. So the question is, is there any way to change the omeka folder name after the fact, say by exporting the data and importing to an installation in a new folder?
It should be possible to just switch the folder name. A quick test of that on my system didn't produce any surprises, at least.
I'm a little surprised that absolute URLs are showing up in the database -- Omeka generally relies on a routing system that doesn't store URLs. In what tables are they showing up?
Hi Patrick --
Thanks for the speedy response. This could very well be a user issue, as I'm not sure how resources are added to an Omeka collection; i.e. the main user could be entering resources with absolute URL references in them, or something like this.
In any case, when I change the name of the folder from omeka to the requested jma-presiding-bishop, the front page displays properly, but everything from the tabs at the top to resources on the page result in a 404 error when clicked.
It looks like we will be using Omeka fairly extensively going forward, so I will need to dig in to this and get it straightened out.
One table which contained absolute URL's is omeka_exhibits, but it does appear that these might be coming from the user.
It's helpful to know that Omeka uses relative links by design -- this narrows down the problem.
I also found absolute references under themes in css/style.css files, but again, I don't how this CSS is being generated or created.
Perhaps I should make this a separate post, but in anticipation of converting absolute URLs to relative ones in the Omeka database, is there a convenient way to do this? I suppose I can mysqldump the collection and then filter through the resulting data file with a perl script, but they don't have that much stuff in the collection yet, so if I knew which Omeka DB tables contain user generated data, maybe we could just edit these entries by hand.
Ah! My bad...I should have thought of that possibility, regarding the tabs at the top.
It sounds like it might be that the navigation settings under Appearance - Navigation might have been saved so that they are 'remembering' the old folder name. The default navigation setting carried over when I made the switch, but if those have been customized, it wouldn't surprise me at all if they still followed the old links. Those aren't absolute, but would still assume the old folder name.
If that's right, it'd just be a matter of going into the details in the navigation settings to change the url to the new one.
Yeah, there's not much we can do about user-entered content with absolute URLs. I'm guessing that the absolute URLs in omeka_exhibits are in the description column?
Regarding the css/style.css absolute urls...are those in the default omeka styles, under application/views', or in your theme's css folder? If under the theme, which theme is it (or based from?)
looks like our posts crossed while I was writing.
User-generated content can show up in a few places, especially when plugins get involved. element_texts is one of the most likely places to look. Anything related to exhibits will have a column with user-generated content of some sort, same with Simple Pages.
If the amount of content is still pretty low, it might indeed be easiest to run through the site by hand (or apply something that checks for dead links)
Hi -
The css/style.css are customized, but based on the berlin theme (I think this a default Omeka theme, but frankly have no idea).
I'm going to try the upgrade regime I posted under the Installing and Upgrading Forum and will play around with the content there.
Again, perhaps this should be a different post, but is the Omeka design paradigm to put all manners of exhibits inside a single Omeka installation (and hence one database) or is it common to have multiple Omeka installations for different collections? (I'm wondering if we should have called the Omeka database something other than omeka.)
That question about having one or multiple installations is somewhat subjective, and I think usually comes down to how they are better managed on a case by case basis. I've certainly seen both options.
This is one of the major things that the newest Omeka product, Omeka S, is designed to tackle. It's still in alpha, but definitely tries to solve that issue.
Patrick,
I just got this response from the user:
When uploading the item/image, we don't specify any URL, that's all automatically created by the system. The navigation bar has absolute URLS because it gives an error if we put in a relative URL (I expected to have to change those manually and a few that are in the HTML in the exhibit pages). When I look at the source code on the home page for the items, it shows a relative URL, with the changed directory, so I'm not sure exactly what the issue is.
Most of that sounds about as expected. Omeka will generate the relative URLs to items and files, and the URLs in the content of the exhibit pages is out of Omeka's hands.
The navigation thing sounds like what I mentioned above, and not surprising that those would have to be manually changed, too. The system can be a little touchy in what it accepts as the link, though, which might explain why they entered absolute URLs. If you follow the pattern in the default navigation data, that should show what it should look like. From what you described, something like
/jma-presiding-bishop/
should be the start to the links given. Absolute or relative, manually editing them should be the easiest fix.
Thanks will all your help on this. Before bothering you with further questions I need to sit down with the user to see what she's done first hand.