PHP ngettext() error on Macbook M1 - 13.1 - MAMP Server - php

I have an fatal error that breaks my website and output
500 Internal Server Error
I did debug the issue and found out that the former dev used ngettext to get the singular or plural of text.
$day = 2;
printf(ngettext("%d day", "%d days", $day, $day);
// Expect output: 2 days
I have check all the log, no log in PHP, but there is one in Apache log everytime I try to run ngettext() somewhere in my source.
The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec().
Break on __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__() to debug.
I did:
Check the gettext module enabled.
I run the code on PHP CLI:
$ php -r 'printf(ngettext("%d day", "%d days", 2, 2);'
// Output: 2 days
Deploy the source code into hosting server, it ran well.
Deploy the source code into another Macbook with Intel chip, v12. Ran well.
What am I missing? Please advise me. TIA

Related

Correctly setting date.timezone on Windows 7 for PHP 5.4.35 binary only install

I am writing unit tests for a series of PHP classes in NetBeans (testing with PHPUnit).
These classes rely on a nusoap script that I don't want to mock.
When I run tests that rely on nusoap as a dependency, I get the seemingly common "It is not safe to rely on the system's timezone" error for this method in the nusoap script:
function getmicrotime() {
if (function_exists('gettimeofday')) {
$tod = gettimeofday();
$sec = $tod['sec'];
$usec = $tod['usec'];
} else {
$sec = time();
$usec = 0;
}
return strftime('%Y-%m-%d %H:%M:%S', $sec) . '.' . sprintf('%06d', $usec);
}
So, I have gone into my php.ini file and added:
[Date]
; Defines the default timezone used by the date functions ;
; http://php.net/date.timezone
date.timezone = "America/New_York"
I am only using PHP binaries. There is no web instance so there is only 1 ini file to modify, as far as I know.
When I rerun these tests I get errors from PHPUnit right away and no tests run. If I remove the edit to the ini file my tests run normally. "Normally" is defined as the tests return a failure with the same timezone error
Many of the other answers around the web suggest editing the ini file in two places, one for the web and one for the CLI. However, since I have only 1 ini file, I am not sure what else I need to modify in order to get the time zone correctly recognized.
How, on a Windows 7 machine with PHP 5.4.35 binaries installed (no IIS at all), would I make this work? I've also tried adding date_default_timezone_set( 'America/New_York' ); to the nusoap script, but this seemingly had no effect.
Thanks.
This was a red herring, and a tough one to find too.
I went back to basics and dug around in my PHP.INI file and discovered I was using the test/prod version, so I decided to try the development version.
Running the tests in both NetBeans and the CLI, I was now able to see the "real" root cause, which was related to the class I was testing. There's just no information at all displayed to the user unless configured in PHP.INI.

Syntax difference between MAMP and Ubuntu Server

I have the following function to account for Sundays in business day calculations. It works on my test server which is MAMP running on a Mac. When I move the code to an Ubuntu server running LAMP, it stops working (manifested as the page not loading anything).
I can't work out why, and have tried all different combinations of single quotes and double quotes.
The function is:-
// function to account for Sundays, and public holidays. Add holiday dates in $holidayDays variable
function get_next_business_date($from, $days) {
$workingDays = [1, 2, 3, 4, 5, 6]; # date format = N (1 = Monday, ...)
$holidayDays = ["*-12-25","*-12-26", "*-01-01", "2014-12-24"]; # variable and fixed holidays
$from = new DateTime($from);
while ($days) {
$from->modify("+1 day");
if (!in_array($from->format('N'), $workingDays)) continue;
if (in_array($from->format('Y-m-d'), $holidayDays)) continue;
if (in_array($from->format('*-m-d'), $holidayDays)) continue;
$days--;
}
return $from->format("Y-m-d"); # or just return DateTime object
}
$today = date("Y-m-d", strtotime("today"));
$tomorrow = get_next_business_date("today", 1);
$twodays = get_next_business_date("today", 2);
$yesterday = date("Y-m-d", strtotime("yesterday"));
I'm lost as to why this could be.
you may have version changes between the machines.
on ubuntu, you can check the file /var/log/apache2/error.log
tail -f /var/log/apache2/error.log
to see what error was thrown.
To check for the current PHP version on your machine, you could use
php -v
from the command line (requires php5-cli module installed)
another way is to put a PHP file with:
<?php
phpinfo();
?>
in your web dir, and open it with your browser.
As per the responses in the various comments, this was a server version issue. The version of PHP on my test box was more recent than the version on the live.
If it's of any use, I am using MAMP on a Mac Mini as my test environment which had 5.5.3, and LAMP on an UBUNTU 12.04 server box which had 5.3. I didn't want to upgrade the Ubuntu version, just the PHP version and did so as per this http://phpave.com/upgrade-php-5-3-php-5-5-ubuntu-12-04-lts/
Things to be aware of (if you don't know) are that the default directory for your php code will change from /var/www to /var/www/html. You can either move your PHP to the /var/www/html folder or change the default folder as per the link above. I suspect that changing the default may have repercussions to future versions as they will be expecting code to reside in /var/www/html.
There will also be some permissions issues for that folder that you may wish to be aware of if you are copying into and creating sub folders.
Hope this is of use to someone.

PHP command line error : Timezone database is corrupt

My date.php is -
<?php
echo date('Y');
When I execute php -f date.php on my staging machine, I get error -
PHP Fatal error: date(): Timezone database is corrupt - this should *never* happen!
in /home/staging/test/date.php on line 2
But when I execute the same on my local / dev machine it works. Although on both staging and local machines, permissions on /etc/localtime and /usr/share/zoneinfo/ are the same.
But output of file /etc/localtime vary on both machines.
Local (php5.3.5) :
/etc/localtime: timezone data, version 2, 4 gmt time flags, 4 std time flags, no leap seconds, 4 transition times, 4 abbreviation chars
Staging (php5.3.10) :
/etc/localtime: timezone data, version 2, 1 gmt time flag, 1 std time flag, no leap seconds, no transition times, 1 abbreviation char
While trying to find what the issue is I found this link from SO. I am confused over the accepted answer. My apache user is not executing the script.
What seems to be the problem? How do I resolve this issue?
For various reasons, PHP ships with its own timezone database - it is possible to use the system TZDB by configuring the software differently at compile time.
The PHP timezonedb is implemented as C code (lots of defines) - hence you need to recompile PHP to get it working.
If your PHP interpreter is not explicitly configured to use the OS timezoneDB, then you really need to investigate why the executable is corrupt.
Please check permission of your timezone files.It might have changed when you have install some rpms.
change the permission to 655
Also check following files:
/usr
/lib
/share
/etc
My problem was that I was running php-fpm in chroot mode. I changed it to run without a chroot, and then the error went away.

Inconsistent results in special characters with Apache/PHP/FreeTDS, but not with PHP/FreeTDS from command line

I have two identical servers (called test and production) with Linux Red Hat Enterprise Linux Server release 6.2 (Santiago), PHP version 5.4.2, Apache Apache 2.4.2, OpenSSL/0.9.8s, freeTDS 0.92-dev (not the best thing but I cannot change that for the moment), and a separate Windows server with Microsoft SQL Server.
I have a PHP script called testfs1.php that reads a string from the database, always the same, and prints the length: nothing else. Of course, the initial situation was much more complex, but I did any effort to simplify.
The database field is NVARCHAR, all the components are set to use UTF-8.
Normally everything works: the script displays the expected string length. But once every several hours or even days, on the production server only (which hosts several heavily used applications), the bug "activates": the web server starts displaying special characters extracted from database wrong. Sometimes the bug "deactivates" by itself after some minutes; last time, it lasted several hours, then I run
service httpd restart
and the bug deactivated.
In the time frame when the bug is active, it is consistent: all requests to the web server for the page testfs1.php display the wrong result; however, when I manually run
php testfs1.php
on a command line of the server, the bug never appears, even when it is active.
This is the Bash script I leave running day and night to monitor the activation of the bug:
#!/bin/bash
while : ; do
echo -n `date +%H%M%S`
wget https://www.mydomain.org/testfs1.php -o /dev/null
echo -n "("
cat testfs1.php
echo -n ") "
rm testfs1.php
sleep 2
done
The PHP script I use to reproduce the issue:
<?php
$Conn = mssql_connect( 'PROD', 'user', 'password' ) ;
mssql_select_db( "DBPROD", $Conn ) ;
$Ret = mssql_query( "SELECT lname FROM people WHERE people_key=123", $Conn ) ;
list( $s ) = mssql_fetch_row( $Ret ) ;
print strlen( $s ) ;
?>
Here is locales.conf used by freeTDS:
[default]
date format = %b %e %Y %I:%M:%S:%z%p
language = us_english
charset = UTF-8
[en_US]
date format = %b %e %Y %I:%M:%S:%z%p
language = us_english
charset = UTF-8
[es_ES]
date format = %b %e %Y %I:%M:%S:%z%p
language = us_english
charset = UTF-8
[pt_BR]
date format = %b %e %Y %I:%M:%S:%z%p
language = us_english
charset = UTF-8
[it_IT]
date format = %b %e %Y %I:%M:%S:%z%p
language = us_english
charset = UTF-8
Summary of the most puzzling particularities of this issue:
Bug never happens when the script is run with PHP from the command line, only from Apache
Bug "activates" at different moments, once every several hours or few days, and either "deactivates" by itself or with a "service httpd restart"
When in the locales.conf used by freeTDS, the line [default]/charset was missing the bug was activating and deactivating spontaneously much more often (every few seconds)
When another application on the same server used gettext, the bug was activating and deactivating spontaneously much more often (every few seconds)
A colleague hints that it could be a memory problem, which makes some sense considering that restarting Apache could have freed memory, and explains why it does not happen on the test server, where the traffic is minimal. I am not convinced.
Can you imagine possible causes and solutions for the situation?
Frankly i have no idea what makes such kind of inconsistent work. but i would like to advice you to change FreeTDS & unixODBC to stable releases. since FreeTDS lack of documentation & support. i am using v0.82 for along time. and it works fine.
https://gitorious.org/freetds/mars-freetds/source/52e59affc0110c5ddd379ef1e45c4554123f27b5:README#L2
Another way to look for problem detailed is using PDO MsSQL in testfs1.php. by this way you can address the problem better if native mssql extension has any effect on this inconsistency.

Why is my PHP error log lagging behind by 2 hours?

When checking php.ini, from both phpinfo and php -i on the command line, my timezone is set to Africa/Johannesburg. So my timezone is GMT +2.
I wrote a tiny snippet to check the time is right as follows:
echo date('h:i A', time());
echo '<br />' . ini_get('date.timezone');
and this outputs the correct time, matching with my localmachine's system time.
However, when I look at my php error log, the time on each error log item is behind by exactly two hours? Why is this, and how can I fix this.
Also having issues with Zend Cache, and i think this time issue is causing it.
It sounds like PHP is configure with one timezone, and the server it is running on is set to a different time zone (possibly GMT / UTC). This means all file operations etc will be working on a different timezone to your PHP scripts.
Check the system timezone of your server.
Google-fu: read what the PHP official site writes.

Categories