timezone settings

We moved our Omeka archive to a new dedicated server. We have it basically working but on the bottom of the items display we are getting:
Warning: date() [function.date]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/New_York' for 'EST/-5.0/no DST' instead in /home/pateam/public_html/application/helpers/ItemFunctions.php on line 251
Line 251 reads:
$accessDate = date('F j, Y');
I have set the Apache PHP configuration in /etc/php.ini to America/Los_Angeles (Pacific Time) but it is still throwing that error. What should I be changing?

I find that sometimes figuring out the correct php.ini file can be confusing, depending on the server settings.

Another way at it is to add it into the .htaccess file's php settings. There should already be something that looks like:

<IfModule mod_php5.c>
    php_value display_errors 1
    php_flag register_globals off
</IfModule>

you can add in the setting there:

<IfModule mod_php5.c>
    php_value display_errors 1
    php_flag register_globals off
    php_value date.timezone "America/Los_Angeles"
</IfModule>

patrickmj:

I tried your solution and now I seem to have an even bigger problem. An ordinary user gets this when they try to view items:
Access denied for user 'pateam'@'localhost' (using password: YES)

#0 /home/pateam/public_html/omeka/application/libraries/Zend/Db/Adapter/Abstract.php(448): Zend_Db_Adapter_Mysqli->_connect()
#1 /home/pateam/public_html/omeka/application/libraries/Zend/Db/Adapter/Abstract.php(782): Zend_Db_Adapter_Abstract->query('SELECT name, va...', Array)
#2 [internal function]: Zend_Db_Adapter_Abstract->fetchPairs('SELECT name, va...')
#3 /home/pateam/public_html/omeka/application/libraries/Omeka/Db.php(82): call_user_func_array(Array, Array).....etc.

I tried removing that line from .htaccess and still have the problem. I don't know if this is related but the first time I changed .htaccess, I uncommented the part suggested here:

# Uncomment the lines below in order to enable caching of some files via Apache (after a finished site has gone live)
<IfModule mod_expires.c>
#  <FilesMatch "\.(js|css|gif|png)$">
#       ExpiresActive on
#       ExpiresDefault "access plus 10 day"
#   </FilesMatch>
</IfModule>

I recommented them and even commented out the new date line, but the behavior did not change.

That one looks like a problem in the db.ini settings for the database, or perhaps that the mysql user doesn't have all the permissions to access the database.

Don't think that that additional change to .htaccess would cause the problem.

Patrick

I found the right php.ini and got the date fixed. But I still have this access denied issue. Changing anything in db.ini made it worse. I can get into our first Omeka screen, but the items, exhibits etc throws this same error. Any idea why the first screen would work and not the items?

BTW - If I login as an administrator, everything seems fine.

Joe

I am at a bit of a loss. That looks like a MySQL authentication error, so I wouldn't expect to see differences between the admin side and the public side.

So, a couple questions to try to figure out what's happening:

When logged in and looking at the admin side, can you browse around items and exhibits?

When logged in and looking at the public side, can you see items and exhibits?

And, what did you change in db.ini (without publicizing security credentials), and what became worse?

Patrick:

Thanks for staying with this.
Yes. In the administrative side we can browse items. But although the home page comes up on the public side, Omeka throws the error when trying to display items, exhibits etc. We have a further glitch on the admin side, the CSV upload starts to work normally, but now says the uploaded .jpgs are not valid files. This may or may not be a related issue.

The same db.ini file as was originally in there and allowed the public to see items, is still there. It was changing the .htaccess file that caused the errors I am seeing now. My suspicion is that changes to FilesMatch parameters in .htaccess (which are now reset) triggered Apache to disable some user permissions.

There is a further complication in that the user names for administrator and public are the same with different passwords (I didn't do that part but have control of it now). I am going to experiment changing users and permissions now that the DNS points to the old site while we fiddle with the new one. The Omeka user name relations to the Linux FTP user and Administrator logins is unclear to me. I'd like advice on that and will report any breakthroughs on this end.

Omeka user names are totally separate from Linux/Unix system names, SSH names, or FTP names.

Omeka also doesn't allow you to have two users with the same name, usernames must be unique.

MySQL "access denied" errors on the frontend, but not the backend, don't really make any sense. The database credentials are the same for both. Is it possible that your server's set up with two different Omeka installs, and your "public" URL is pointing to a different one?

John:

Thanks for clarifying that for me. There is only one installation on this server, but it is one that was moved from a previous installation, not installed from scratch. We have 10 gigabytes of data and 14700 images and didn't want to start from scratch. Furthermore the internal domain name and users are different on this new server and there are duplications involved between user names and the domain name on both the server and in Omeka. I am working to eliminate the duplications now that I control the server but it is a steep learning curve.

Meanwhile we are having trouble getting thumbnails of the images we upload on the new server. I checked and the Imagemagick directory path is a valid path but when I press the "Test" button, it "fails". I suspect that is the source of the thumbnail problem and is probably related to the access problems. Do you agree?

PS: We should probably rename the topic here to something like "Moving an Omeka site" since the timezone issue is not visible any more since I changed it in a second copy of php.ini.

Patrick and John:

With the help of some other topics on this forum we have successfully moved our site. I think it might be worthwhile to recount what seems to have happened.

As a big set of images, backing up the archive from the old server to the new server did not work directly. What worked was to backup the archive to a single file on the server where it was, then copy the single file to the new server and restore it from there.

It opened at first with a small error about the date. There were two php.ini files on the new server in directories etc/bin/ in the root and in the set of directories associated with the restored website. Setting the date in the php.ini within the archive's set of directories fixed the timezone problem. But trying to fix it with a change to .htaccess caused inscrutable problems, apparently due to activating the FilesMatch function. We overcame whatever happened there by restoring the whole archive again.
it ran smoothly but would not convert uploaded images with ImageMagick, the clue being that the test under general settings for the ImageMagic directory path said false. We fixed that by installing ImageMagick on the new server with a utility called YUM. But that gave us huge errors which we traced to the fact that YUM had overwritten the PHP.ini file - erasing the timezone setting and changing the session.save.path.
Now that we have reset the PHP.ini file to our path and our timezone. Omeka seems to be working for us. Thanks for your help. I would advise changing .htaccess only as a solution of last resort. Our FTP program could not see any file in the Public directory that did not have something in front of the ".whatever" so I could not make a backup. I was able to give it a name like "name.htaccess" and FTP it to the directory, then rename it and delete the "name". Not having seen the original file, I engaged FilesMatch inadvertently and that gave us errors that seemed to say the user permissions were wrong, which led us down the wrong paths.
I hope this helps someone in the future and for now I would consider it fixed.

Thanks for the update.

Some of this is only problematic because of the vintage of your Omeka installation, the timezone and session save issues in particular come to mind.

As for the problems with FTP and moving from server to server: it's perfectly fine to zip up or otherwise archive the site's files to move them around.

Files that start with a "." like .htaccess are "hidden" files. Usually your FTP client or other software will have an option somewhere to make hidden files visible.