I know that Windows is not officially supported, but I’m looking for some heads to knock together to get Omeka running in a WIMP stack. I know that at least one person seems to have had some success in the past.
Right now, trying to get to the install page throws up the following error:
Fatal error: Uncaught Zend_Cache_Exception: Could not determine temp directory, please specify a cache_dir manually in D:\inetpub\wwwroot\newsite\omeka\application\libraries\Zend\Cache.php:209
Stack trace:
#0 D:\inetpub\wwwroot\newsite\omeka\application\libraries\Zend\Cache\Backend.php(217):
Zend_Cache::throwException('Could not deter...')
#1 D:\inetpub\wwwroot\newsite\omeka\application\libraries\Zend\Cache\Backend\File.php(130):
Zend_Cache_Backend->getTmpDir()
#2 D:\inetpub\wwwroot\newsite\omeka\application\libraries\Zend\Cache.php(153):
Zend_Cache_Backend_File->__construct(Array)
#3 D:\inetpub\wwwroot\newsite\omeka\application\libraries\Zend\Cache.php(94):
Zend_Cache::_makeBackend('File', Array, false, false)
#4 D:\inetpub\wwwroot\newsite\omeka\application\libraries\Zend\Cache\Manager.php(172):
Zend_Cache::factory('Core', 'File', Array, Array, false, false, false)
#5 D:\inetpub\wwwroot\newsite\omeka\application\libraries\Zend\Application\Resource\Locale.php(106):
Zend_Cache_Manager->getCache('locale')
#6 D:\inetpub\wwwr in D:\inetpub\wwwroot\newsite\omeka\application\libraries\Zend\Cache.php on line 209
I have tried setting storage.tempDir in config.ini to a new path, but that didn’t help. I think the problem may actually be a web.config issue or other permissions errors. Attemping to go to admin/index.php (but only the index.php) results in a 403 error.
Ok, so, moving on. I don’t think Zend was reading the Omeka config (which makes me think there’s still permissions errors going on), so I edited cache_dir in line 99 of omeka\application\libraries\Zend\Cache\Backend\File.php and pointed it directly to a temp directory within the omeka structure (omeka\temp in my case.)
Now I can get to Omeka and see all the websites, but there’s no CSS (or JS maybe?) running. Here’s what it looks like in the Omeka instance and the admin site.
Alright now. Figured it out. Guess I should post my web.config in case anyone else wants to try and get Omeka up and running in IIS. This goes in the Omeka base install dir (where the htaccess file is.)
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<!-- per MS's IIS page:
https://www.iis.net/learn/application-frameworks/install-and-configure-php-applications-on-iis/translate-htaccess-content-to-iis-webconfig
-->
<configSections>
<sectionGroup name="system.webServer">
<sectionGroup name="rewrite">
<section name="rewriteMaps" overrideModeDefault="Allow" />
<section name="rules" overrideModeDefault="Allow" />
</sectionGroup>
</sectionGroup>
</configSections>
<system.webServer>
<security>
<!-- this is the stuff I added from htaccess file about ini -->
<requestFiltering>
<fileExtensions>
<add fileExtension=".ini" allowed="false" />
</fileExtensions>
</requestFiltering>
</security>
<!-- these are the redirection rules -->
<rewrite>
<rules>
<rule name="File access not PHP" stopProcessing="true">
<match url=".*" />
<conditions>
<add input="{REQUEST_FILENAME}" matchType="IsFile" />
<add input="{QUERY_STRING}" pattern="^\.(php[0-9]?|phtml|phps)$" negate="true" />
</conditions>
<action type="None" />
</rule>
<rule name="Install path rewrite" stopProcessing="true">
<match url="^install/.*$" />
<action type="Rewrite" url="install/install.php" appendQueryString="false" />
</rule>
<rule name="Admin path rewrite" stopProcessing="true">
<match url="^admin/.*$" ignoreCase="true" />
<action type="Rewrite" url="admin/index.php" appendQueryString="false" />
</rule>
<rule name="Everything else" stopProcessing="true">
<match url=".*" />
<action type="Rewrite" url="index.php" appendQueryString="false" />
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>
Thanks for posting your results.
We don’t have much expertise or experience with ISS, and not too many users using it (at least not too many that come and post about it, bar an ocassional trickle).
I guess the CSS problem was a rewrite issue, directing even the requests for static assets through the PHP entry point?
The PHP problem is an odd one as some default temp directory should be defined. At any rate I’d imagine it could be fixed with server configuration, the php.ini directive sys_temp_dir. Omeka’s setting is used just for uploading and processing files, not a few other things that ask for temporary space, like caching.
At least part of the issue was user error on my part. I had originally written the first rule as action type="rewrite" but then told it not to rewrite, which is a very literal translation from Apache. IIS, however, has the action type="none" rule, which I didn’t realize at first. Changing that was what ultimately solved my problem.
I’ve got a new problem now, though, that maybe someone has some insight into. In Exhibit Builder, when I try to either create or edit a page, I cannot choose any block other than “File with text.” I can click on the “Gallery” icon, for example, but when I select “Add a new content block,” the editable form that appears is always “File with text.”
I’m guessing this is still some lingering permissions/PHP error that stems from the same place as some of my earlier problems. It might be easier just to install Apache and configure it to run alongside IIS, but I’m so close to getting this working, my ego is on the line.
I would hazard a guess that it’s the rewrite rules at work with your Exhibit Builder problem. Those forms are loaded via AJAX, and your rewrites might be doing something like dropping the query string from the request. Perhaps appendQueryString should be true for those rewrites?
You’re absolutely right! I had forgotten that I even changed those settings when I was experimenting early on. I ended up with three copies floating around with different edits, so I never merged them back together. Thank you!
So for anyone looking here’s the up-to-date web.config:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<!-- per MS's IIS page:
https://www.iis.net/learn/application-frameworks/install-and-configure-php-applications-on-iis/translate-htaccess-content-to-iis-webconfig
-->
<configSections>
<sectionGroup name="system.webServer">
<sectionGroup name="rewrite">
<section name="rewriteMaps" overrideModeDefault="Allow" />
<section name="rules" overrideModeDefault="Allow" />
</sectionGroup>
</sectionGroup>
</configSections>
<system.webServer>
<security>
<!-- this is the stuff I added from htaccess file about ini -->
<requestFiltering>
<fileExtensions>
<add fileExtension=".ini" allowed="false" />
</fileExtensions>
</requestFiltering>
</security>
<!-- these are the redirection rules -->
<rewrite>
<rules>
<rule name="File access not PHP" stopProcessing="true">
<match url=".*" />
<conditions>
<add input="{REQUEST_FILENAME}" matchType="IsFile" />
<add input="{QUERY_STRING}" pattern="^\.(php[0-9]?|phtml|phps)$" negate="true" />
</conditions>
<action type="None" />
</rule>
<rule name="Install path rewrite" stopProcessing="true">
<match url="^install/.*$" />
<action type="Rewrite" url="install/install.php" appendQueryString="true" />
</rule>
<rule name="Admin path rewrite" stopProcessing="true">
<match url="^admin/.*$" ignoreCase="true" />
<action type="Rewrite" url="admin/index.php" appendQueryString="true" />
</rule>
<rule name="Everything else" stopProcessing="true">
<match url=".*" />
<action type="Rewrite" url="index.php" appendQueryString="true" />
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>
To anyone looking at this in the future, this is not a good fix: [quote=“awlibrarian, post:2, topic:1630”]
I edited cache_dir in line 99 of omeka\application\libraries\Zend\Cache\Backend\File.php and pointed it directly to a temp directory within the omeka structure (omeka\temp in my case.)
[/quote]
Instead, specify sys_temp_dir in your php.ini to a directory within inetpub. (For example C:\inetpub\temp) Then change the permissions of that directory so that both “IIS_USRS” and “Users” can read, write, and modify.
