Verification: a143cc29221c9be0

Openserver php ini где лежит

Openserver php ini где лежит

Сравнение XAMPP и OpenServer

Если сравнивать XAMPP с OpenServer, то у каждого проекта есть свои плюсы и минусы.

XAMPP — это практически «голый» сервер, где нужно владеть азами знаний Apache, чтобы подстроить  его под себя, создать руками виртуальные хосты. Зато работает он быстро и наиболее близок к нормальному хостингу. В последних версиях даже сделали заглушку для тестирования отправки почты, что часто требуется при создания всяких форм обратной связи.

OpenServer более автоматизированная сборка для разработки. К ней еще идут дополнительно программы в расширенном пакете, которые работают без инсталляции. А управлением сервером сделано из своей оболочки, которая позволяет автоматически создавать виртуальные хосты для отдельных сайтов, настраивать сервер под себя без лазанья в кучи конфигов. Однако запускается он существенно дольше, да и работает он тоже медленнее XAMPP (и то, и другое обычно не критично для разработки).

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

Очень много людей ушли именно с Denwer на XAMPP именно из-за того, что конфиги часто были не оптимальны и генерировались скриптами «на лету», так что править косяки было очень сложно и вместо работы, нужно было «раскапывать» проблемы.

Проблемы OpenServer, мешающие жить

Вот и я на днях столкнулся с такой же проблемой: на OpenServer неправильно работал движок KodiCMS Павла Бучнева (недавно статья была о этом движке даже на habrahabr.ru). И косяк был в том, что для работы с требовался не только обработка обработка запросов GET/POST, но и PUT, DELETE. Ошибка не сразу выяснилась, но даже когда я её обнаружил к консоли и пошел искать решение, его не обнаружилось даже на форуме сборки. Нет, топик был и есть, вот только решения не подходило. Максим писал, что это типа защита от взлома (на локальном сервере, на локальной машине ?!).

Поскольку я еще изучаю Laravel, там тоже есть такие запросы (хотя я до них еще не добрался), так что проблема есть и её надо решать.

В XAMPP это все прекрасно работает «из коробки».

Понятно, если бы я был «гуру» в Apache, я бы разобрался что и где подписать/подправить, но я такими знаниями не обладаю, поэтому мне проще сменить сборку.

Ну и не зря я уже писал о настройки OpenServer и PHPStorm из-за путей конфигов в предыдущих статья.

Так что все эти проблемы привели меня опять к XAMPP, которым я пользуюсь от случая к случаю.

Какую версию XAMPP ставить.

Для пользователя Windows предлагается только один инсталлятор на 32 бита. А вот версий предлагается 2: 1.8.3 с php 5.5 и 1.8.2  c php 5.4. Особой разнице вроде бы нет, так что я ставил последнюю версию.

И вот тут-то меня подстерегала большая птица ОБЛОМИНГА! Сервер ставился, сайты работали. Вот только страницы генерировались В РАЗЫ МЕДЛЕННЕЕ, чем на OpenServer.

«Ты же только что говорил, что XAMPP быстрее OpenServer?» — спросит меня внимательный читатель. Отвечаю: я сам был в шоке и искал причину в конфигах Apache, php, Windows. Но так я и не понял в чем дело.

Тогда я взял версию 1.8.2. и все стало просто летать! Так что новое не всегда лучше, чем проверенное старое ?

Да, еще хотел бы сказать о интересной особенности Apache, который я откопал случайно.

Параметр DocumentRoot в сервер Apache

При создании виртуального хоста, в httpd.conf прописывается DocumentRoot, где хранятся все хосты физически.  Казалось бы, такая незаметная настройка, но вот если попробовать в сервере прописать виртуальный хост не в этой директории, то он работать не будет. От слова совсем!

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

Так что если вы хотите создать для себя отдельную папку для сайтов где-нибудь в корне, как это сделано в OpenServer, то либо экспериментируйте с этой настройкой. Либо делайте как я:

  1. В парпе XAMPP/httdocs я создал папку localhost и перенес туда все файлы с папками из этой папки.
  2. Хосты создаю в папке XAMPP/httdocs в отдельных папках
  3. Прописываю названия в файле host в c:\windows\system32\drivers\etc
  4. А в настройках апача смотрим xampp\apache\conf\extra\httpd-vhosts.conf раскомментируем пример хоста и сначала создаю localhost, а потом уже копирую и добавляю свой хост. Получается что-то такое:
80="">
    ServerAdmin jean179@mail.ru
    DocumentRoot "D:/xampp/htdocs/localhost"
    ServerName localhost
    ErrorLog "logs/localhost-error.log"
    CustomLog "logs/localhost-access.log" common

 
 
80="">
    ServerAdmin jean179@mail.ru
    DocumentRoot "D:/xampp/htdocs/ kodi.dev"
    ServerName kodi.dev
    ErrorLog "logs/ kodi.dev-error.log"
    CustomLog "logs/ kodi.dev-access.log" common

Таким образом я полностью контролирую создание виртуальных хостов, все настройки стандартны и понятно где их искать. А каждый сайт лежит в своей папке и для резервного копирования легко можно настроить архивацию на конкретную папку.

Причины для поиска php.ini

Изменения в php.ini для сайта производятся тогда, когда нужно расширить или снять ограничения на некоторые операции – например, объем импортируемых или экспортируемых данных. Снятие ограничений полезно, когда вы переносите сайт вместе с его содержимым с одной платформы на другую, так как настройки по умолчанию могут этому помешать. Продвинутые пользователи могут настроить здесь все, что связано с исполнением команд на языке PHP.

Как найти данный файл

Первый шаг в поисках подойдет для случая, когда сайт уже запущен на виртуальной машине или хостинге (или вы как раз собираетесь это сделать). Создайте в корневой папке сайта файл с расширением PHP, куда скопируйте следующий простой код:

phpinfo();
?>

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

Основное правило при использовании Apache, Denver и других оболочек для виртуального сервера: вы фактически работаете с тем же Linux’ом, поэтому пути находятся стандартными для этой системы (и для самого PHP) способами, и, скорее всего, содержат соответствующие названия в именах папок. Если советы, касающиеся конкретных CMS, не помогли, просто ищите файл стандартным способом через создание страницы с phpinfo().

Ищем файл настроек PHP в популярных CMS

Даже пользователю-новичку может быть нужно найти, где находится php ini в Wordpress или Joomla. Эти CMS дружелюбны к новым пользователям, но изменения параметров PHP все равно могут потребоваться по разным причинам. Файл обычно располагается в \usr\local\php5 относительно корневой папки, которую вам предоставляет хостинг, или папки, которая является рабочей для вашего внутреннего сервера. Метод с созданием проверочного файла, описанный выше, отлично работает в этом случае. Сами CMS обычно не вносят изменения в расположение php ini.

Будьте внимательны, когда заказываете хостинг веб сайтов – в некоторых случаях провайдер может ограничить или запретить изменение важных файлов, в том числе конфигурационных файлов PHP. Если возникают проблемы с поиском или открытием файла, есть смысл обратиться в техподдержку хостинга напрямую и уточнить, какие возможности вам доступны. В работе с собственным виртуальным сервером на Denver/Apache вас никто не ограничивает.

Если вы работаете в CMS Bitrix, вы можете и не найти файл настроек PHP в привычных директориях. Файл php ini в Bitrix лежит в разных папках в зависимости от версии самого Битрикса, поэтому создавайте тестовую страничку из первого примера и узнавайте точный путь оттуда. На некоторых хостингах вы можете найти путь /home/login, но туда обычно загружаются собственноручно созданные файлы, исходник для которых берется из /home/login/etc.

Расположение php.ini в ОС Linux разных версий и сборок

ОС Linux считается самой подходящей системой для регулярной работы с хостингом, сайтами на PHP и сопутствующими процессами. Если вы имеете непосредственный доступ к файловой системе сервера (являетесь его владельцем, например), то ищите php.ini по адресам /etc/, /usr/local/lib или /usr/local/php/etc/ – это самые распространенные места. PHP Zend размещает ини файл в /usr/local/Zend/etc/, учтите это, если используете данную оболочку. Вы можете задать и обычный поиск файла в системе, но так вы не узнаете, какой из нескольких файлов php.ini реально используется в данный момент для задания настроек сервера и сайта.

Вряд ли сложным исключением станет сборка ОС на базе Ubuntu. Место, где лежит php.ini в Ubuntu, определяется через phpinfo() и зависит от того, какой именно тип сервера вы используете. Для Apache это может быть /etc/php5/apache2, например. Если файл вовсе не удается обнаружить, то его можно создать вручную или скопировать из другого места, но только если знаете примерную структуру файла.

Общая информация о планировщике заданий cron OpenServer

Если вы являетесь пользователем UNIX-подобных систем, то программа «cron» должна быть вам знакома, т.к. это стандартный планировщик задач для данного класса операционных систем.

Первое, что бросается в глаза после общения со стандартным планировщиком задач Windows, – это то, что cron лишён графического интерфейса, и расписания задач нужно вносить в специальный файл crontab в соответствии с внутренним синтаксисом cron.

Скорее всего, это обстоятельство и стало причиной для интеграции данного планировщика задач в OpenServer, т.к. данный шаг лишал разработчиков необходимости выдумывать графический интерфейс.

В плане функционала лично я никаких отличий от стандартного cron Unix не заметил. Повторюсь, что cron OpenServer служит для создания расписаний выполнения различных задач (скриптов, программ и т.д.), как и стандартные планировщики на уровне ОС. Поэтому без него вполне можно обойтись 🙂

Единственный его плюс – это возможность использовать планировщик cron на ОС Windows, что может порадовать фанатов Unix-систем, которые вынуждены работать на детище Билла Гейтса и компании Microsoft.

Также cron OpenServer может подойти тем, кому не очень нравится стандартный планировщик задач Windows. Основной причиной может служить бедность настроек времени выполнения, т.к. возможности Task Scheduler (стандартный планировщик Windows) ограничены фиксированным списком, в котором нельзя вводить произвольные значения (несколько раз в час, день, периодичность и т.д.).

Кроме всего прочего, лично я открыл ещё один плюс cron OpenServer, который касается процесса тестирования и отладки скриптов, запускаемых с помощью OpenServer. Это возможность приостановки работы планировщика банальным выключением OpenServer.

Насколько я знаю, в стандартных планировщиках такой возможности нет. Если в UNIX cron задачу ещё можно приостановить, закомментировав её расписание в файле crontab, то в Windows вам придётся попросту удалять задачу и создавать её каждый раз, когда необходимо выполнять снова – всё это крайне неудобно.

Поэтому если вы, как и я, являетесь разработчиком, работающим с ОС Windows, то планировщик задач cron OpenServer будет для вас удобнее стандартного Task Scheduler.

Давайте теперь рассмотрим, как же его настроить и пользоваться.

Настройка cron OpenServer

Для начала нам необходимо запустить сам OpenServer, для чего запускаем OpenServer.exe из директории, в которую у вас был установлен данный софт. Если вы вдруг забыли, куда его устанавливали, напомню, что по умолчанию OpenServer устанавливается в директорию «C:\OpenServer».

После старта программы в панели инструментов Windows, рядом с часами, появится красный флажок OpenServer, сигнализирующий о том, что программа запущена, но сервер ещё не работает.

Перед запуском веб-сервера нажимаем на флажке любой кнопкой мыши и выбираем пункт «Настройки» для конфигурации планировщика задач cron OpenServer:

В открывшемся окне находим вкладку с названием «Планировщик заданий», которая выглядит так:

Как видите, интерфейс весьма незамысловатый. Для добавления новой задачи вам необходимо ввести периодичность запуска задачи, указать путь к скрипту или исполнительному файлу программы и нажать на кнопку «Добавить». После данных действий задача появится в блоке со списком всех запланированных заданий.

Теперь поговорим о синтаксисе заданий более подробно. Он такой же, как и для cron UNIX, т.е. для указания времени можно использовать цифры и символ «*», который означает «для всех».

Синтаксис cron OpenServer сильно упрощён, т.к. в оригинальном UNIX-планировщике, к примеру, для дней недели и месяцев доступны сокращённые варианты названий на английском. В нашем же случае такая запись приведёт к ошибке. Дни недели, к примеру, нужно будет указывать только цифрами, где 1 – это понедельник, а 7 – воскресенье.

Если поговорить о реальных примерах, то:

  • запись типа «1 * * * *» будет означать запуск задачи каждую первую минуту часа, т.е. она будет выполняться каждый час;
  • запись «*/2 * * * *» будет запускать задачу через каждые две минуты;
  • запись «2-4 * * * *» будет соответствовать запуску задачи 3 раза в течении каждого часа во 2,3 и 4 минуту;
  • запись «* * 1 * *» будет соответствовать ежемесячному запуску задачи первого числа месяца.

Думаю, что логика понятна. Если вы хотите больше примеров, то можете обратиться за помощью к Википедии, где есть очень неплохая и понятная (что редкость для вики 🙂 ) статья на русском языке по данному поводу.

Также хотелось бы посоветовать вам хороший сайт для тренировки написания времени запуска заданий cron, где отображаются все параметры для каждого временного блока, а после ввода данных выдаётся периодичность выполнения (правда, на английском).

При пользовании ресурсом не забывайте, что в качестве параметров времени запуска cron OpenServer принимает только числовые значения.

С временными параметрами выполнения задач cron OpenServer мы разобрались, теперь поговорим о том, как правильно задавать путь к запускаемому объекту.

Запуск php-скриптов с помощью планировщика задач cron в OpenServer

Объектом может быть как исполнительный (.exe) файл программы и php-скрипт, так и обычные файлы, которые будут открываться в тех программах, для которых они предназначены. ОС определяет последнее по ассоциациям расширений файлов и указанных для них программ, которые хранятся в системном реестре.

Поскольку планировщик задач cron встраивался в OpenServer для разработчиков (равно как сама WAMP-сборка создавалась для них же), то он, в первую очередь, предназначен для запуска программных скриптов.

Вообще идея написания сегодняшней статьи возникла у меня после моего недавнего знакомства с CMS/CMF Magento, в рамках которого мне необходимо было реализовать автоматическую отправку писем на email покупателей порциями через равные промежутки времени.

В самом Magento есть встроенный планировщик cron, задачу для которого я создал в коде сайта. Соответственно, моей задачей было запускать скрипт, отвечающий за автоматический запуск задачи в Magento, на веб-сервере через равные промежутки. Вот такая вот петрушка 🙂

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

Для того, чтобы произвести его запуск, потребовалось помимо пути к файлу прописать в описании задачи ещё и путь к PHP-интерпретатору, а также файлу конфигурации PHP. В итоге, получилась следующая строка:

%progdir%\modules\php\%phpdriver%\php-win.exe -c %progdir%\userdata\temp\config\php.ini -q -f %sitedir%\sitename.com\cron.php

Первая её часть – это путь к интерпретатору PHP, вторая – ссылка на файл конфигурации, а третья – это путь к самому скрипту, который нам необходимо будет запускать.

Соответственно, для запуска своих скриптов, расположенных на OpenServer, вы будете менять лишь третью часть данной задачи – остальные две будут неизменными, т.к. расположение интерпретатора и файла конфигурации во всех версиях продукта одинаково.

Также создатели OpenServer учли ситуацию, когда через cron необходимо будет запустить удалённый скрипт, т.е. доступ к нему будет осуществляться по url.

В данной ситуации необходимо будет воспользоваться встроенной в OpenServer утилитой WGet. Пример такой задачи будет выглядеть следующим образом:

%progdir%\modules\wget\bin\wget.exe -q --no-cache http://sitename.com/cron.php -O %progdir%\userdata\temp\temp.txt

В данном случае файл cron.php будет запрашиваться по протоколу http и ответ будет сохраняться во временный файл temp.txt, чтобы не скапливать мусор.

Таким образом, возможно будет у себя на локальном сервере запускать удалённые скрипты и сохранять результаты их выполнения для дальнейшего анализа.

Возможность заманчивая, но в реальной практике её использование встречается не так уж и часто. Просто имейте ввиду, что данное действие возможно 😉

Возвращаясь к синтаксису задач cron OpenServer, вы могли заметить, что при описании задач допускается использовать предопределённые переменные. Они записываются в формате %переменная% и служат в качестве указателей различных директорий (каталога OpenServer, системного диска компьютера и т.д.)

С полным списком переменных и их значений вы можете познакомиться в официальной документации OpenServer.

Итак, на данном этапе вы ввели все необходимые данные для создания задачи для планировщика cron.

Перед сохранением конфигурации планировщика проверьте ещё раз список всех задач на экране настройки cron OpenServer и убедитесь, что объект с указанными вами ранее данными там присутствует.

Теперь нам остаётся нажать на кнопку «Сохранить», чтобы занести введённую нами информацию в файл конфигурации cron. После этого веб-сервер автоматически перезагрузится.

Если веб-сервер на этапе ввода задачи был остановлен, его необходимо будет запустить вручную, после чего все изменения сохраняться и задача начнёт выполняться.

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

Для доступа к нему необходимо в меню OpenServer выбрать пункт «Просмотр логов»:

В открывшемся окне ищем вкладку «Планировщик заданий» и видим там следующее:

Как видите, задача запустилась, причём, в путях к указанным файлам вместо внутренних переменных OpenServer появились реальные объекты.

К сожалению, на этом ценность данного лога исчерпывается, т.к., несмотря на различную информацию, информативности в ней нет никакой.

Не зависимо от результатов выполнения задачи в логах постоянно пишется ошибка при чтении taskinfo.txt и выдается «result: 0».

Так что при возникновении каких-либо проблем с запуском задачи под cron OpenServer на логии надежды нет – можете не тратить время на их изучение и не прикреплять их к сообщениям на форумах и блогах 🙂

О запуске скриптов и отдельных файлов через определённые промежутки времени с помощью планировщика задач cron, входящего в комплект OpenServer, мы поговорили. Самое время рассмотреть, как можно запускать приложения с его помощью. И возможно ли это?

Где находится php.ini?

Местонахождение файла php.ini зависит от операционной системы, на которой работает сервер хостинг-провайдера. Чтобы узнать где он находится выполняем 4 простых шага:

  1. Создаем php-файл (имя может быть любое, но мы берем для примера myphpinfo.php), и добавляем в него следующие строки:
    phpinfo();
    ?>
  2. Загружаем этот файл на сервер, где расположен ваш сайт (в корневую папку).
  3. Запускаем через браузер (вводим URL https://yoursitename.com/myphpinfo.php).
  4. В появившемся окне ищем путь к php.ini (для начала смотрим "Loaded Configuration File", если там написано "None", то смотрим "Configuration File (php.ini) Path").

Путь к файлу php.ini