Поднимаем PHP/Nginx под WSL(Ubuntu)

Устанавливаем nginx

sudo apt install nginx

По умолчанию создается конфигурация с пользователем www-data. Меняем его на текущего пользователя.

sudo sed -i 's/www\-data/seligoroff/g' /etc/nginx/nginx.conf

Устанавливаю php

sudo apt install php7.4
sudo apt install php7.4-dev
sudo apt install php7.4-mysql
sudo apt install php7.4-zip
sudo apt install php7.4-fpm

По умолчанию php-fpm тоже сконфигурирован для пользователя www-data.

seligoroff@NB-SELIVANOV:~$ grep www-data /etc/php/7.4/fpm/pool.d/www.conf
user = www-data
group = www-data
listen.owner = www-data
listen.group = www-data

Заменяем на текущего пользователя.

sudo sed -i 's/www\-data/seligoroff/g' /etc/php/7.4/fpm/pool.d/www.conf

Запускаем сервисы

sudo service php7.4-fpm start
sudo service nginx start

Создаю laravel-проект.

composer create-project laravel/laravel mylaravel

Генерируем ключ приложения

cd mylaravel/
php artisan key:generate

Создаем конфигурационный файл /etc/nginx/sites-available/test.conf

server {
    listen 80;
    root /home/seligoroff/mylaravel/public;
    index index.php index.html index.htm index.nginx-debian.html;
    server_name test.test;
 
    add_header X-Frame-Options "SAMEORIGIN";
    add_header X-Content-Type-Options "nosniff";
 
    index index.php;
 
    charset utf-8;
 
    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }
 
    location ~ \.php$ {
        fastcgi_buffering off;
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
    }
 
    location ~ /\.ht {
        deny all;
    }
}

Добавляем конфиг в используемые и рестартуем nginx:

sudo ln -s /etc/nginx/sites-available/test.conf /etc/nginx/sites-enabled/
sudo service nginx restart

На windows добавляем в файле hosts

127.0.0.1 test.test

Заходим в браузере под указанным доменом:

Zend_Tool подключение кастомных провайдеров

1. Пишем кастомный провайдер (-ы) и манифест

class PS_Tool_RouteProvider extends Zend_Tool_Framework_Provider_Abstract
 
{
 
      ......
 
}
 
class PS_Tool_Manifest implements Zend_Tool_Framework_Manifest_Interface
 
{
 
    public function  getProviders()
 
    {
 
        return array(         
            new PS_Tool_RouteProvider         
        );
 
    }
 
}

Создаем конфиг для утилиты zf

zf --setup config-file

 3. Открываем создавшийся (скорее всего в домашней папке файл .zf.ini)

 4. Добавляем пути к библиотеке с провайдером в include_path

 php.include_path = "C:/xampp/php/pear;C:/xamp/phtdocs/shared;C:/xampp/htdocs/diclon/application/library;"

 5. Подключаем кастомный провайдер (добавляем строку в .zf.ini)

basicloader.classes.0 = PS_Tool_RouteProvider
basicloader.classes.1 = PS_Tool_Manifest

Всё, можно использовать.

Zend_Tool пакет в Zend Framework, который предназначен для программирования консольной утилиты zf.

По умолчанию в zf уже встроены ряд операций, но их модно расширять кастомным провайдером.

Формы в Laravel

Многие фреймворки имеют встроенную поддержку генерации форм. В Laravel так было изначально, но затем формы выделили в отдельный компонент laravelcollective/html. В самом Laravel осталось буквально несколько элементов: защита от CSRF и поддержка дополнительных методов HTTP в HTML-формах.

Для установки этого компонента выполните эту команду:

composer require "laravelcollective/html"

SoapClient не передает заголовки Basic Authentication

Столкнулся на проекте с необычной штукой. SOAP-сервер находился под http-аутентификацией. На development машинах код работал без ошибок. Но при выгрузке на production стал давать при инициализации клиета ошибку:

SOAP-ERROR: Parsing WSDL: Couldn’t find  

 Поставил сниффер на машину с сервером. Оказалось, что  SoapClient, которому в options задавались логин и пароль не передавал заголовок Authentication. Причем было это, как я уже сказал, только на production сервере, где стояла Gentoo. Проблема была решена сменой версии php

5.3.8-pl0-gentoo на 5.3.25-pl0-gentoo

Вероятно, к этой версии баг был пропатчен.

WordPress 2.6.1 под php 5.3

Пришлось перетаскивать старый сайт сделанный на WordPress 2.6.1. Тут  же повылетали сообщения, что передача по ссылке уже запрещена. Обновляться до новой версии 3 не хотелось, поскольку может обернуться необходимостью тратить еще кучу времени на фиксирование несовместимостей, а времени особо нет.

Починил пока при помощи sed:

find -name *.php -exec sed -i 's/=&/=/g' {} ;

Осталось  пофиксить ругань на eregi в админке, а так, вроде запустилось. 

Ошибка в меню Joomla

При переходе на php5.3 сайт на старой Joomla стал выкидывать warning.

modMainMenuHelper::buildXML() expected to be a reference, value given

Лечится простым фиксом  в /modules/mod_mainmenu/helper.php. Меняем:

function buildXML(&$params)

на

 function buildXML($params)

Потеря сессии в IE

Пришлось столкнуться с идиотическим багом, портящим кровь. Информации по нему не так много, поэтому публикую на всякий случай.

Предыстория:
Руководитель проекта сообщил, что пользователь жалуется. Он логинится, передвигается по сайту и вдруг оказывается снова на странице авторизации. Проверили production-сервер и development . Никаких проблем не обнаружили. Но при добавлении очередной фичи , понадобилось проверить production-сервер в IE. И вот оно… Все как говорил пользователь, проходишь авторизацию, начинаешь бродить или даже просто делать refresh страницы — оказываешься на странице аутентификации, куда попадает только незалогиненный пользователь. Делаем вывод, куда-то потерялась сессия. Причем, проблема повторялась на всех доступных версиях IE.

Проверяю на development-сервере и на рабочей машине. Проблем нет. Значит дело 100% не в коде, нужно смотреть настройки сервера. Начинаю искать проблему. В основном попадается околотхенический бред. В конце концов натыкаюсь на то, что нужно.

http://swfupload.org/forum/generaldiscussion/1206

http://simply.com.au/blog/2009/11/flash-uploader-drops-the-session-in-internet-explorer/

Рецепт прост, меняем конфигурацию патча для php suhosin:

suhosin.session.cryptua = off
suhosin.session.encrypt = off

Если вы не имеете доступ к php.ini, вы можете внести эти изменения через .htaccess или в самом коде через ini_set

По умолчанию эти опции включены. То бишь, проблемы возникли именно из-за suhosin и его шифрования сессии на уровне движка php. К сожалению не нашел более полного описания этой проблемы и возникает она не со всеми версиями. На машине, где возникла проблема стоял suhosin patch 0.9.32.1 На моей рабочей машине 0.9.10, на ней никаких проблем не возникает.