Oleg

Зачем их запоминать, скажите пожалуйста?
Определили задачу -> Написали запрос в поисковик -> Нашли подходящее решение.
То, что часто используется запомнится само, редко используемое запоминать и не нужно.

Сделайте проще.
Стартуйте апач от своего имени.
В консоли:
sudo nano /etc/apache2/envvars
Поменяйте переменные:

export APACHE_RUN_USER=login
export APACHE_RUN_GROUP=login

А то я однажды с этими правами и прочим, группами, замучался)

Ну а по поводу группы то так добавить:
sudo adduser {your-user} www-data
И дать права рекурсивно:
sudo chmod 775 -R /path/to/project

https://stackoverflow.com/questions/30854013/vagra...

Проблема не только в правах, но и в том, кто ими владеет. Например, если с файлами вы работаете под www-data, а сервер апач или какой то иной, под apache, то их нужно поместить в одну группу, чтобы групповые права на запись были к нужным объектам.

В общем:
- redux популярнее (больше работы)
- redux должен быть стабильнее (так как слишком широкое внимание к себе привлекает)

Технически: обе библиотеки берут свое начало от реализации flux, но имеют разницу в деталях. Судя по документации reflux - у них тоже (как и flux) несколько store-хранилищ. У redux - store един.

Суть библиотек одна: однонаправленный поток управления данными. Если говорить простым языком: как управлять всеми данными в приложении: кто-то куда-то кликнул, что-то где-то изменилось.

Лучшее объяснение Redux что я видел.
getinstance.info/articles/react/learning-react-redux

/path/to/project/ это путь к проекту и данный путь нигде не фигурирует, это та директория из которой запускается основной index.php

Нет. Этот корневая директория проекта. Из нее запускается композер. В ней же обычно лежит DOCUMENT_ROOT каталог, в котором уже и находится точка входа index.php. Также здесь лежат директории vendor (для сторонних пакетов) какой нибудь application/ для ваших файлов.

Давайте попробую объяснить на примере.

Пусть будет такая структура, например.



в vendor - вам ничего самому писать не нужно. Этот папка для композера.
public_html - в ней только index.php и все ваши css, images, js. Это папка на которую указывает DOCUMENT__ROOT в настройках домена вашего сервера. Только эти файлы доступны "по интернету".
application - здесь все ваши самописные php файлы.
(На остальные каталоги не обращаем внимания, в корне проекта можно располагать все что вам удобно, это не будет доступно из web)

Под такую структуру написан подобный composer.sjon

{
  "require": {
    "php": ">=5.5.9",
    "slim/slim": "2.*",
    "twig/twig": "~1.18",
    "slim/views": "^0.1.3",
    "robmorgan/phinx": "^0.4.4",
    "illuminate/database": "^5.1"
  },
  "minimum-stability": "stable",
  "autoload": {
    "psr-4": {
      "MyName\\MyProject\\": "application"
    }
  }
}

Тут вроде бы все просто. В require перечислены используемые пакеты. Поясню только autoload. Автозагрузка по стандарту PSR-4. Указано пространство имен ваших файлов и папка в которой они лежат.
Если ваш класс MyClass лежит в папке application - то у него должно быть пространство имен \MyName\MyProject (полное имя класса получается \MyName\MyProject\MyClass). Если ваш класс MyController лежит в папке application/Mvc/Controllers, то, соответственно \MyName\MyProject\Mvc\Controllers\MyController.

При этом вам не нужно заморачиваться и писать автозагрузчик. Просто выполните команду php composer.phar install (или php composer.phar dumpautoload для пересборки аавтозагрузчика) и подключите файл автозагрузчика в index.php
include '../vendor/autoload.php';

Не использовать композер не имеет смысла, т.к. это очень просто. Просто скачайте файл https://getcomposer.org/composer.phar в корень проекта и пользуйтесь (см выше).

Нууу давайте разбираться.

Для начала почитайте про HTTP на той же вики. Досканально знать не нужно, но стоит минимально понимать структуру запросов/ответов, понимать что у запроса и ответа есть заголовки и тело (тела может и не быть, зависит от типа запроса/ответа).

Так вот. Куки. Куки живут на стороне браузера. Они передаются HTTP заголовком на каждый запрос на сервер (даже если вы за картинками полезли). Есть просто куки, есть http-only куки. Куки могут быть разграничены по хосту и пути. Все это дает нам гибкость и помогает с секьюрностью. В PHP содержимое $_COOKIE предоставляет нам SAPI. Когда PHP получает на обработку запрос, SAPI используемое (php-fpm, cgi, mod_php имеют свои реализации SAPI) в данный момент берет заголовки и тело запроса, парсит их и заполняет все эти суперглобальные массивы типа $_SERVER, $_GET и в том числе и $_COOKIE. Все что прислал нам клиент (что-то что делает запросы это клиент, что-то что их обрабатывает - сервер), а куки шлет нам браузер только те что можно исходя из того куда шлется запрос. Устанавливаются куки заголовком Set-Cookie в ответе, то есть тут больше нужно читать в принципе про HTTP а не про PHP. PHP просто позволяет вам работать с этим добром. Вы можете сэтить куки напрямую работая с заголовками ответа при помощи функции header. Более того, если выставить время жизни куки в 0, то как раз таки они а не сессия будет сбрасываться при закрытии браузера так как тот будет забывать все такие куки.

Вот... сессии... В PHP сессия обычно это файл. Просто какой-то файл с рандомным именем. Если скажем в php.ini указано session.autostart или делается вызов session_start то создается файл под сессию пользователя (можно переместить в рэдис или мемкэш, свое хранилище и т.д в зависимости от нужд. Так же данные можно шифровать, что по умолчанию и происходит). Этот файл имеет ID, просто какая-то рандомная строка. И если при обработке запроса не нашлась сессия с предыдущего запроса - создается новая.

И вот мы подошли к самому интересному - как PHP связывает сессию с предыдущего запроса с текущей. И тут все довольно просто - куки. Когда пользователю присваивается сессия, автоматически сэтится http-only (что бы нехорошие люди не могли из js увести нашу сессию) кука, в которую записан идентификатор сессии. В дебагере браузера можете посмотреть есть ли у вас кука PHPSESSID (название можно менять в настройках, да и вообще сессии можно не только через куки связывать, но это уже загоны по секьюрности) когда будете эксперементировать с сессиями.

Когда запрос обрабатывается SAPI, при наличии session.autostart, перед тем как начинать создавать новую сессию, пых все же смотрит а есть ли у нас кука с идентификатором сессии, проверяет есть ли у него такая, и если есть успокаивается и не создает новую. Поскольку сессия привязывается через куки, то можно выставить время жизни этой самой куки (в php.ini) и таким образом регулировать время жизни сессии.

Вот... когда использовать куки а когда сессии? Желательно понимать, что чем больше данных в куках (а у них есть лимит к слову) - тем больше данных мы передаем на каждый запрос. То есть это не круто когда что бы получить 1 килобайт данных мы должны в заголовках передать пару килобайт кук. Люди, повернутые на оптимизации, даже картинки хранят на отдельных cookie-less доменах что бы уменьшить количество трафика и пакетов (обычно простенький HTTP запрос влазит в размеры одного TCP пакета). Если вам нужно работать с этими данными из JS на любой странице, например локаль выбранноую пользователем для того что бы применять переводы еще и в JS, то стоит использовать куки. Для всео остального лучше конечно же использовать сессии. Во всяком случае на начальных этапах когда что-то сильно сложное вам делать не придется.