Omeka now looks terrible because there are missing/insecure javascript/css elements. It was installed as a subdirectory of an http-based website. Now we’ve had to switch from http to https. IT put a load balancer in front and that’s how redirects from http to https traffic are happening (it’s not using Apache for either the ssl or redirections, so I’m not clear on the configuration / how to troubleshoot from that end).
The problematic installation is at http://library.ccsu.edu/dighistFall16/.I even tried upgrading to the latest v. of Omeka and upgrading the db and it made no difference. I poked through the db and can see no evidence of where the urls are being pulled from. When I go to whynopadlock.com, I get a list of files that are being referenced as though they are http, not https, still, such as several files under the following directories: application/views/scripts/css/, themes/seasons/css/, application/views/scripts/javascripts/, files/square_thumbnails/
This is super urgent now, as the class has begun and this installation is not functional for their needs. So how do I change our Omeka so that all files are referenced at the appropriate ssl address (and yes, I have also tried changing the default in application/config.ini to be ssl = always and that totally bombs out the site, so I had to recomment it)? I’ve poked through the .ini and other files and see no easy answers. I feel like this should be dead simple. As of October, everyone had to change to https to avoid the Google penalties, so I’m frustrated that it was so easy in drupal and wordpress installations and not at all working with omeka (no simple base url settings that I could find). That’s really disappointing and frustrating. I’ve tried a bunch of directives in .htaccess, but none worked and I think it’s useless due to the load balancer, but I’m open to any ideas that people have. Oh yes, and I saw paths.php and routes.ini suggested in older Omeka discussions and the former doesn’t exist anymore I guess and the latter doesn’t seem to apply at all.
I don’t know if your problem is the same as the one I ran into recently (some features simply did not work in our custom theme when accessed through https), and I finally tracked down the culprit in the header.php file (theme\common\header.php). I updated http://code.jquery.com/(older version number) to https://code.jquery.com/(new version number), and the lightbox and image display issues cleared up immediately!
I also found and corrected a ‘mixed content’ error by updating http://fonts.google.apis to https in the main.css file (theme\css\main.css).
So, the problem here is that Omeka tries to detect that you’re using HTTPS and select the right scheme accordingly. In your case it’s the load balancer part of the configuration that’s probably confusing us, because the HTTPS connections are getting terminated at the load balancer which is just making plain HTTP connections to Omeka itself. (This is also why ssl = always didn’t work: nothing’s actually using HTTPS/SSL to connect to Omeka in your setup, so when you try to force that with the ssl configuration setting, it fails trying to redirect you for eternity).
There’s changes we can make to make this less of a problem, and I’ll look into those. For your immediate needs, the best option is probably to just override Omeka’s URL detection. Right here in your bootstrap.php file (in the Omeka root directory), you can add the line:
Wow, thank you for understanding the issue and offering that solution. I made one minor tweak that I think may have made a difference (I noticed suggestions to do this in the apache rewrite statement examples back when I was looking through those as a potential solution before understanding that it would probably be related to the load balancer setup):
I used the following (per your recommending at line 72 of the bootstrap.php found in the root of the omeka installation directory:
The first time I tried without the trailing slash, it didn’t seem to work (though in retrospect, my browser may have had too much info cached to be a clean test). But since it’s working with that, I may just leave it alone. The digital history professor is much happier now, so I don’t want to create any new issues! Thank you again.
I’m having the same issue… I added the line, it seems to have temporarily worked, but I have to say that it seems like the whole browser drags and I can’t figure out why. I added the line that @jflatnes suggested.
…wish I could help, Amanda, but not sure what to offer.
In fact, I have a new problem. I needed to install a new Omeka instance on another subdirectory. I did the installation after having copied that bootstrap.php mod from the other subdirectory, assuming it wouldn’t cause any problems, but if that line is in there, the script then strips out that segment of the base url that includes the library.ccsu.edu and leaves only the https://subdirectoryname/etc.
When I comment out that line, I get the version of Omeka that doesn’t include the “insecure” files, so the ugly version, no css styling, js, etc (on Chrome).
so I’m wondering if I need to insert this in a different location in the bootstrap.php or make some other modification to bootstrap.
Ideas?
Just in case @jflatnes or someone else checks in who is familiar with that bootstrap file checks in, here is what I hope makes sense to you for diagnosis of this new issue with this new subdirectory-based installation
I add the line to the bootstrap.php of my new Omeka installation:
$base_url = $base_root = ‘https://library.ccsu.edu/’;
I will note that you really shouldn’t need the trailing slash, on either install. Slashes get appended later in the bootstrap so having one there will result in double slashes where there should be only one.
Actually, that’s a fair bet as to what you’re seeing: if you’ve got an extra slash and Omeka tries to generate a URL like /latinohistoryharvest/admin/items it will instead be //latinohistoryharvest/admin/items. The first is just a normal relative URL, but the second is actually a protocol-relative URL, which would cause the effect of “stripping out the hostname” that you’re describing. I’d definitely start with getting rid of that slash on the end of the $base_url = $base_root line.
As for the problem more generally, earlier I mentioned changes to Omeka to improve this situation and one should be arriving soon with Omeka 2.6: all the local CSS/JS/etc. will be loaded with relative paths so this mis-detection of HTTPS won’t matter nearly as much. I’ve also gone in and done some simplification in the bootstrap so variable names and things should be less confusing (and less duplicated).
Perfect, once again you’ve gotten me all fixed up! I should have know about the relative base url, as I’ve been switching to those in other parts of our site for various inclusions and reasons. I just didn’t quite understand the bootstrap code, either. But I am also extraordinarily appreciative of the fact that you all will be including some fixes for those of us running behind load balancers (or any other unusual setups) in the upcoming Omeka 2.6 release. Thank you for your work!!!