Php test php ini

ButlerCC Webhosting

This guide is intended to help you configure PHP for your local test server, and includes details for configuring PHP in XAMPP for both Windows and Mac OSX. Before you configure your php.ini file, you should first check your current settings and note the settings you need to change.

Recommended PHP Core and date directives for test server

This table contains the recommended test server settings for PHP Core and Date directives for XAMPP (both Win and Mac).

Recommended Test Server Settings for PHP

Directive	Local Value
allow_url_fopen	On
allow_url_include	Off
display_errors	On
error_reporting	32767
file_uploads	On
log_errors	On
short_open_tag	Off
upload_tmp_dir	(Win) C:\xampp\tmp (OS X) /Applications/XAMPP/xamppfiles/temp
date section Default timezone	America/Chicago

Check Your PHP Settings with XAMPP:

1. Open your XAMPP Control Panel (Manager-OSX) and Start the Apache server.
2. In a browser, type http://localhost in the address bar to open the XAMPP dashboard page.
3. Click PHPInfo in top navigation bar to display your current settings. The PHP Core and Date directives sections are the ones to focus on.
   
4. Compare your Core and date values to those in the recommended test server settings for PHP Core table and note the ones that need to be changed. Your PHP directives should look similar to the old screenshot below.
   
5. Open XAMPP Control Panel and Stop Apache server before editing PHP directives.

Where Is My php.ini File?

• In XAMPP (Windows), the php.ini file is in the C:\xampp\php folder.
• In XAMPP (Mac OSX), the php.ini file is in the /Applications/XAMPP/xamppfiles/etc folder.

Tips Before Editing php.ini File

Important points BEFORE editing your php.ini file:

1. IMPORTANT! Open your XAMPP control panel and Stop Apache server before editing the php.ini file.
2. Make a backup copy of the php.ini file before editing in case anything goes wrong (Name the backup copy php.ini.bak or something similar).
3. The php.ini file is huge—use a text editor with line numbering, like Brackets (or Notepad++ for Win).
4. Lines that begin with a semicolon (;) are comments and are ignored by PHP.

Modify php.ini for XAMPP 7.4.8

In this version of the php.ini file, there are only two directives that must be modified. (Three directives in Mac OS X) However, you should still verify all the following directives are correct in your php.ini file. Directives in the following table are organized by line number.

1. Open your php.ini file in Brackets (or other text editor with line numbering) and make the necessary changes.
2. (Mac OS X only) Line 228 (short_open_tag) should be as follows:
   short_open_tag = Off
3. Line 463 or 516 (error_reporting) should be as follows: (Note: the value is case sensitive so be sure to type in all caps. Use the pipe character SHIFT + \ for separator.)
   error_reporting = E_ALL | E_STRICT
4. Line 1969 or 1040 (date.timezone) should be as follows:
   date.timezone = America/Chicago
5. Save and close the php.ini file.
6. In XAMPP Control Panel, restart your Apache server.
7. To check the changes to your PHP configuration settings, type http://localhost in address bar of a browser to open the XAMPP dashboard.
8. In the XAMPP dashboard, click PHPinfo link to display your current settings. Compare your values to the Recommended PHP Core directives table.
9. When your php.ini file is configured correctly, you’re ready to work on projects in your htdocs directory.
   • c:\xampp\htdocs (Win)
   • /Applications/xampp/htdocs (Mac OSX)
10. (Optional) If you want to use PHP includes and site root relative links in your projects, review Setup Virtual Hosts with XAMPP.

Disclaimers: Butler is an “Equal Opportunity Employer/Program” and “Auxiliary Aids and Services are available upon request.”

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

Источник

Test framework tests

The easiest way to test your PHP build is to run make test from the command line after successfully compiling. This will run the all tests for all enabled functionalities and extensions located in tests folders under the source root directory using the PHP CLI binary.

make test basically executes run-tests.php script under the source root (parallel builds will not work). Therefore you can execute the script as follows:

TEST_PHP_EXECUTABLE=sapi/cli/php \ sapi/cli/php [-c /path/to/php.ini] run-tests.php [ext/foo/tests/GLOB]

Which php executable does make test use?

If you are running the run-tests.php script from the command line (as above) you must set the TEST_PHP_EXECUTABLE environment variable to explicitly select the PHP executable that is to be tested, that is, used to run the test scripts.

If you run the tests using make test, the PHP CLI and CGI executables are automatically set for you. make test executes run-tests.php script with the CLI binary. Some test scripts such as session must be executed by CGI SAPI. Therefore, you must build PHP with CGI SAPI to perform all tests.

NOTE: PHP binary executing run-tests.php and php binary used for executing test scripts may differ. If you use different PHP binary for executing run-tests.php script, you may get errors.

Which php.ini is used?

make test uses the same php.ini file as it would once installed. The tests have been written to be independent of that php.ini file, so if you find a test that is affected by a setting, please report this, so we can address the issue.

Which test scripts are executed?

The run-tests.php ( make test ), without any arguments executes all test scripts by extracting all directories named tests from the source root and any subdirectories below. If there are files, which have a phpt extension, run-tests.php looks at the sections in these files, determines whether it should run it, by evaluating the SKIPIF section. If the test is eligible for execution, the FILE section is extracted into a .php file (with the same name besides the extension) and gets executed. When an argument is given or TESTS environment variable is set, the GLOB is expanded by the shell and any file with extension *.phpt is regarded as a test file.

Tester can easily execute tests selectively with as follows:

./sapi/cli/php run-tests.php ext/mbstring/* ./sapi/cli/php run-tests.php ext/mbstring/020.phpt

Test results

Test results are printed to standard output. If there is a failed test, the run-tests.php script saves the result, the expected result and the code executed to the test script directory. For example, if ext/myext/tests/myext.phpt fails to pass, the following files are created:

ext/myext/tests/myext.php - actual test file executed ext/myext/tests/myext.log - log of test execution (L) ext/myext/tests/myext.exp - expected output (E) ext/myext/tests/myext.out - output from test script (O) ext/myext/tests/myext.diff - diff of .out and .exp (D)

Failed tests are always bugs. Either the test is bugged or not considering factors applying to the tester’s environment, or there is a bug in PHP. If this is a known bug, we strive to provide bug numbers, in either the test name or the file name. You can check the status of such a bug, by going to: https://bugs.php.net/12345 where 12345 is the bug number. For clarity and automated processing, bug numbers are prefixed by a hash sign ‘#’ in test names and/or test cases are named bug12345.phpt.

NOTE: The files generated by tests can be selected by setting the environment variable TEST_PHP_LOG_FORMAT. For each file you want to be generated use the character in brackets as shown above (default is LEOD). The php file will be generated always.

NOTE: You can set environment variable TEST_PHP_DETAILED to enable detailed test information.

Automated testing

If you like to keep up to speed, with latest developments and quality assurance, setting the environment variable NO_INTERACTION to 1, will not prompt the tester for any user input.

Normally, the exit status of make test is zero, regardless of the results of independent tests. Set the environment variable REPORT_EXIT_STATUS to 1, and make test will set the exit status («$?») to non-zero, when an individual test has failed.

Example script to be run by cron:

========== qa-test.sh ============= #!/bin/sh CO_DIR=$HOME/cvs/php7 MYMAIL=qa-test@domain.com TMPDIR=/var/tmp TODAY=`date +"%Y%m%d"` # Make sure compilation environment is correct CONFIGURE_OPTS='--disable-all --enable-cli --with-pcre' export MAKE=gmake export CC=gcc # Set test environment export NO_INTERACTION=1 export REPORT_EXIT_STATUS=1 cd $CO_DIR cvs update . >>$TMPDIR/phpqatest.$TODAY ./cvsclean ; ./buildconf ; ./configure $CONFIGURE_OPTS ; $MAKE $MAKE test >>$TMPDIR/phpqatest.$TODAY 2>&1 if test $? -gt 0 then cat $TMPDIR/phpqatest.$TODAY | mail -s"PHP-QA Test Failed for $TODAY" $MYMAIL fi ========== end of qa-test.sh =============

NOTE: The exit status of run-tests.php will be 1 when REPORT_EXIT_STATUS is set. The result of make test may be higher than that. At present, gmake 3.79.1 returns 2, so it is advised to test for non-zero, rather then a specific value.

When make test finished running tests, and if there are any failed tests, the script asks to send the logs to the PHP QA mailinglist. Please answer y to this question so that we can efficiently process the results, entering your e-mail address (which will not be transmitted in plaintext to any list) enables us to ask you some more information if a test failed. Note that this script also uploads php -i output so your hostname may be transmitted.

Specific tests can also be executed, like running tests for a certain extension. To do this you can do like so (for example the standard library): make test TESTS=ext/standard . Where TESTS= points to a directory containing .phpt files or a single .phpt file like: make test TESTS=tests/basic/001.phpt . You can also pass options directly to the underlaying script that runs the test suite ( run-tests.phpt ) using TESTS= , for example to check for memory leaks using Valgrind, the -m option can be passed along: make test TESTS=»-m Zend/» . For a full list of options that can be passed along, then run make test TESTS=-h .

Windows users: On Windows the make command is called nmake instead of make . This means that on Windows you will have to run nmake test , to run the test suite.

Источник

Посмотреть настройки PHP

Проверить настройки PHP актуальные для сайта можно обратившись к скрипту, содержащему одну специальную PHP функцию.

Как проверить настройки PHP и функция phpinfo

Из консоли для пользователя от имени которого выполняются скрипты (имя пользователя можно найти в php.ini о чём ниже) настройки можно посмотреть так:

В случае с www-data, например:

Однако, это будут настройки для CLI, скрипты же выполняются в режиме CGI, задействуется другой бинарный файл. Как следствие, могут отличаться версия PHP, лимиты и список подключенных расширений.

Точную информацию дает только результат выполнения скрипта с функцией phpinfo() в нем.

Скрипт можно разместить в корне сайта, затем обратиться к нему через браузер. Результатом будет страница с настройками.

На странице отдельными блоками приведены все подключенные расширения и информация по ним. Чаще всего здесь приходится на практике смотреть путь к php.ini, в котором задаются все настройки.

В таблице это значение, соответствующее Loaded Configuration File

Loaded Configuration File

/home/web/etc/php/php.ini

Этот файл нужно менять чтобы подключить или отключить какие-то расширения.

Также может быть задан какой-то каталог с .ini файлами, каждый из которых будет учитываться. Обычно это конфигурационный файл для каждого расширения в отдельности.

Scan this dir for additional .ini files

(none)

Если результат выполнения скрипта размещенного в корне сайта не отображается можно попробовать временно (на несколько секунд, которых достаточно чтобы обратиться к странице) переименовать .htaccess.

Иногда мешают директивы, заданные в нем. После проверки настроек нужно вернуть .htaccess прежнее имя, в файле задаются все перенаправления, файл считывает и обрабатывает веб-сервер.

phpinfo() представляет служебную информацию, которая может использоваться для получения сведений о системе. Из соображений безопасности файл в корне сайта лучше не оставлять, а удалить когда требуемые сведения получены.

Источник