3.0.2 and I18n.php prevent use of error reporting

I've seen that reported elsewhere as well, but in those cases they were using NGINX so I didn't spend much time debugging. I haven't seen this on Apache2 before. When did this start happening for you? What build of the code do you have?
---
Problems? Check gallery3/var/logs
file a bug/feature ticket | upgrade to the latest code! | hacking G3? join us on IRC!

I also have this problem. I had to force display of errors to even get any hint what was going on (every visitor just got a blank page).
In the following code (in system/libraries/l18n.php), I18n::get_locale(FALSE) returns an empty string.
Therefore $locale[1] doesn't exist, causing the line with Kohana::find_file to give an error.

I don't know what causes this to go wrong and I hope a developer knows, otherwise I have to dig deeper in the code or abandon gallery3 and try to make my own gallery.

Sounds like your user you have connecting to your database doesn't have proper permission.
____________________________________________
Like Gallery? Like the support? Donate now!

OK... now I have to insist... I cannot release a new version of the theme unless I can ensure there are no errors...

Ok, digging into it now. Backtracking the error from:

Notice: Undefined offset: 1 in /.../gallery3/system/libraries/I18n.php on line 60

That's in this code:

    55                          $locale = explode('_', I18n::get_locale(FALSE));                                          
    56                                                                                                                    
    57                          // Get the translation files                                                              
    58                          $translation_files = Kohana::find_file('i18n', $locale[0]);                               
    59                                                                                                                    
    60                          if($local_translation_files = Kohana::find_file('i18n', $locale[0].'/'.$locale[1]))       
    61                                  $translation_files = array_merge($translation_files, $local_translation_files);   

So I18n::get_locale(FALSE) must not be returning a value with an underscore in it. get_locale() just returns a value from I18n::$locale and that's set via I18n::set_locale() which is called from system/core/Kohana.php in Kohana::setup(). That code looks like this:

   149                  // Load locales                                                                                   
   150                  $locales = Kohana::config('locale.language');                                                     
   151                                                                                                                    
   152                  // Make first locale the defined Kohana charset                                                   
   153                  $locales[0] .= '.'.Kohana::CHARSET;                                                               
   154                                                                                                                    
   155                  // Set locale information                                                                         
   156                  Kohana::$locale = setlocale(LC_ALL, $locales);                                                    
   157                                                                                                                    
   158                  // Default to the default locale when none of the user defined ones where accepted                
   159                  Kohana::$locale = ! Kohana::$locale ? Kohana::LOCALE.'.'.Kohana::CHARSET : Kohana::$locale;       
   160                                                                                                                    
   161                  // Set locale for the I18n system                                                                 
   162                  I18n::set_locale(Kohana::$locale);                                                                

We set the locale.language config setting in modules/gallery/config/locale.php:

    24   * Default language locale name(s).                                                                               
    25   * First item must be a valid i18n directory name, subsequent items are alternative locales                       
    26   * for OS's that don't support the first (e.g. Windows). The first valid locale in the array will be used.        
    27   * @see http://php.net/setlocale                                                                                  
    28   */                                                                                                               
    29  $config['language'] = array('en_US', 'English_United States');                                                    

That has an underescore in it so after line 153 in Kohana::setup() $locales[0] should be en_US.UTF8. After that, it's less clear to me because it's system dependent. What does Kohana::$locale get set to after line 156 and line 159? If you can tell me those values I can probably figure out what's going wrong. Also, it would help if you gave me the output from running "locale -a"
---
Problems? Check gallery3/var/logs
file a bug/feature ticket | upgrade to the latest code! | hacking G3? join us on IRC!

   155                  // Set locale information                                                                         
   156                  Kohana::$locale = setlocale(LC_ALL, $locales);                                                    
   157                  Kohana_Log::add("error",__LINE__. ":".print_r(Kohana::$locale,1));                                
   158                                                                                                                    
   159                  // Default to the default locale when none of the user defined ones where accepted                
   160                  Kohana::$locale = ! Kohana::$locale ? Kohana::LOCALE.'.'.Kohana::CHARSET : Kohana::$locale;       
   161                  Kohana_Log::add("error",__LINE__. ":".print_r(Kohana::$locale,1));                                

Tweak Kohana.php like the above, or replace it with this version:
http://www.menalto.com/.outgoing/gallery/Kohana.php.txt

To run locale -a, create a script like this:

<pre><?php system("locale -a") ?>

Or copy it from: http://www.menalto.com/.outgoing/gallery/locale-a.php.txt

---
Problems? Check gallery3/var/logs
file a bug/feature ticket | upgrade to the latest code! | hacking G3? join us on IRC!

Hm. Ok, that locale value looks reasonable.. not what I was expecting! You don't have the en_US.UTF-8 locale on your system, and that's probably the real issue so if you add that locale the problem will go away. But even so, the code should work. Leave Kohana.php the way it is and replace system/libraries/I18n.php with http://www.menalto.com/.outgoing/gallery/I18n.php.txt and try again.. now what's in your log?
---
Problems? Check gallery3/var/logs
file a bug/feature ticket | upgrade to the latest code! | hacking G3? join us on IRC!

Ok, all the values look fine. $locale is an array with two values, but it claims that there's no value at offset 1. What's the error you're getting now? We need to close the gap between line 61 (in the modified file) saying that $locale is an array with two values, and line 63 saying that $locale doesn't have a values at position 1.
---
Problems? Check gallery3/var/logs
file a bug/feature ticket | upgrade to the latest code! | hacking G3? join us on IRC!

Any chance I can get SSH access here? It's hard to debug these issues remotely :-/
---
Problems? Check gallery3/var/logs
file a bug/feature ticket | upgrade to the latest code! | hacking G3? join us on IRC!

and in the end ... what would be a solution? uninstall, roll back to 3.0.1?

Hey Serge-- Still waiting on FTP access. I suspect that we can resolve this pretty quickly if I can just get in there and debug the problem directly.
---
Problems? Check gallery3/var/logs
file a bug/feature ticket | upgrade to the latest code! | hacking G3? join us on IRC!

any luck?

Thank you
really appreciate your help with this

Ok, thanks to access to SergeD's box I managed to sort some of this out. It's an issue with the timezone detection code that appears to only surface on PHP 5 with strict mode enabled. This test code shows the error:

<?
error_reporting(-1 & ~E_STRICT);
ini_set("display_errors", true);
printf("<pre>%s</pre>",print_r(date_default_timezone_get(),1));flush();
?>

I get this error:

Strict Standards: date_default_timezone_get() [function.date-default-timezone-get]: It is not safe to rely on the system's timezone settings. Please use the date.timezone setting, the TZ environment variable 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 'EDT/-4.0/DST' instead in /homepages/24/d373257762/htdocs/gallery3/test.php on line 4
America/New_York

I am not 100% sure what the correct fix is. It sounds like the right answer is to set the date.timezone setting in php.ini and/or set it in the code before we call the date_default_timezone_get() function. Or you can turn off E_STRICT warning levels.

I've got to run for now, but I think that this is something that really needs to be fixed on the server's PHP settings-- anybody who calls this function is going to have a problem until the config is fixed. I'll work on a way to make G3 fail more gracefully when this happens.
---
Problems? Check gallery3/var/logs
file a bug/feature ticket | upgrade to the latest code! | hacking G3? join us on IRC!

Would you like shell access to my machine as well?

I am using WordPress and there is no problem there
So it could be managed on app level and I think it is proper way to do it
but... it works and this what counts

I've tried just about everything and can't get this to work. I can't use my gallery and I need to get it working as soon as possible. Please help? The solutions above don't seem to work for me. I will add that I downloaded the entire folder and moved it to a new server, then restored the database. Essentially nothing changed but the server. Could this be a permissions issue and when i uploaded the files, the permissions changed?

http://199.167.200.101/~ddeg10/myersgallery/

Can anyone help? No one seems to know how to fix this?

The config located here?: gallery/application/config/config.php

Also where specifically should this code be added inside the file? Is the php.ini edit also required? if so, where specifically should that code be added? Is it the php.ini located in the main gallery directory or the global server php.ini?

The post cited seems vague and maybe I'm adding the code in the wrong place(s)? Please help.

Unfortunately i made those changes but they did nothing.

This is kind of weird, but here's what happened to me. I had updated the my.cnf to enable networking in Ubuntu 11.04 in /etc/mysql/my.cnf I uncommented the line that has

#bind-address = 127.0.0.1

Then I got those same errors that are mentioned in this thread. So, I commented that back out, restart mysql and things are fine.

Now here's the weird part, I have 2 gallery3 installs on this server, one one of them the error never occurred! The one that had problems is at a different URL: http://www.dantesinfernophotography.com/gallery3 The one that didn't have the problem is at http://www.cocoanet.us/dantepasquale/gallery3.

http://www.cocoanet.us/dantepasquale/gallery3
http://www.cocoanet.us/dantepasquale/blog
http://www.dantesinfernophotography.com/gallery3
http://www.twitter.com/DantePasquale

Any status on this? I have 3.0.2 on my server box, and wanted to upgrade from 2.x. I have the local.php error reporting file in the directory. I tried the config and ini workarounds and when I use both, I get a blank page. When I use just the config workaround, I get no error code, but the "Dang! ...." message. With neither workaround, I get the I18n.php line 60 error others are reporting here. No SSH available on my server, as I have to pay extra for it.

I am facing same problem...
I did all the above timezone related changes in config.php and php.in and but that did not help to solve the problem.

I can provide SSH access.
Or let me know what all I should check out for.

Any clue is appreciated.
--------------------------------------------------------------------------------
my wings of love - work, experince, learnings, open source, technologies on my way to God

hi Dave,

The experimental version has file name issues. The filenames with all lower case is not matching with Source code where the file names starts with upper case.
Like bootstrap.php is referred as Bootstrap.

I started changing few, but it seems, its with all the files.
Is there any script that corrects it?
--------------------------------------------------------------------------------
my wings of love - work, experince, learnings, open source, technologies on my way to God

Hi dave,

The experimental version also did not fix it.

It seems to be upgrade issue to me... If i install the latest code separately it all runs fine.
But when I copy the old var folder to new installed location, this happens.
Running upgrader also gives the same error.

I see that the following tables are missing, which are present in newly installed gallery

any clue? anything that you want me to check out?

-gopu

--------------------------------------------------------------------------------
my wings of love - work, experince, learnings, open source, technologies on my way to God