D3lphi

Собственно, практика, практика и еще раз практика. Открываем ЕГЭ по информатике: логические уравнения или, еще лучше, системы логических уравнений. Учимся их решать. После этого, пример, который вы привели, состоящий только из логического сложения и умножения, покажется вам детским лепетом.

Выполняем команду:
composer init

Следуем инструкциям. В результате, получим частично сконфигурированный файл composer.json. Прописываем в этот файл неймспейсы для автозагрузки классов:

{
// Другие опции...
    "autoload": {
        "psr-4": {
            "MySuperApp\\": "src/"
        }
    }
// Другие опции...
}

Это означает, что классы, имеющие неймспейс MySuperApp\ будут находится в папке src. То есть, класс MySuperApp\First должен лежать прямо в папке src, а класс MySuperApp\Test\Second в папке src/Test. Надеюсь, понятно.

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

Далее, переходим на сайт packagist.com, регистрируемся там. В настройках профиля следуем инструкциям и привязываем аккаунт к github'у. Переходим во вкладку submit, вставляем в инпут ссылку на наш github репозиторий, жмем check (В этот момент packagist проверит, что данный репозиторий принадлежит именно нам), затем, снова check, чтобы подтвердить наш выбор. Вот, собственно, и все! Осталось прикрутить автообновление пакета. Информация об этом тоже есть на сайте.

В каталоге, на уровень ниже:

- <папка>
  - index.html
- b
  - assets
    - popups
      - pop1
        - gallery
          - 01.jpg

SELECT `id` FROM `table` WHERE `role_id` IN (5, 6, 1, 3, 8)

Если вы пойдете работать в более - менее серьезную контору именно на позицию back-end developer'а, то да, возможно. Ответственность на вас будет лежать только за серверную часть. Опять же, очень часто и на бэк энд разработчика в требованиях есть, как минимум, базовые знания html, css, js. Так что в идеале, конечно, знать их нужно. Если же вы пойдете работать в фирму, которая пилит "говносайтики" на вордпрессе для дяди Васи из второго подъезда, то тут для вас плохие новости. Там, как правило, нет четкого разделения на back и front end developer'ов. Всю работу там делают "веб-мастеры", которых назвать full stack девелопероми язык не поворачивается (В силу их, как показывает практика, низкой квалификации).

Логическое отрицание. Меняет значение булевого выражение на противоположное.

var_dump(!true); // false
var_dump(!false); // true

1) Отдавать нужно json строку с кодом ответа/статусом и тд, чтобы можно было на клиентской стороне обработать ответ и произвести необходимые действия.
2) В контроллере никакую логику не пишем. Она выносится в сервисный слой. (Это я про эту фразу "есть контроллер, в котором есть метод добавления товара в корзину").
3)

Также непонятно, что должен делать такой метод при обычном запросе не через ajax.. Делать редирект на предыдущий урл или корзину например?

Это уже вам решать. Тут все зависит от потребности. Хотя, я бы вообще не стал этот маршрут приспосабливать для "обычного запроса", создал бы другой специально для этого.

Для этого есть замечательная библиотека - dotenv. Суть в том, что вы храните данные в отдельном файле .env, который добавляете в .gitignore. А в vcs коммитете файл .env.example, в котором присутствует только "скелет" параметров без значений. Тому, кто будет устанавливать ваше приложение будет необходимо переименовать файл .env.example в .env и заполнить необходимые опции. Значения из этого файла можно получить по средствам функции env(). Эту библиотеку, кстати, использует популярный php - фреймворк Laravel.

Это называется рефлексия. Пример:

$class = new \ReflectionClass('Название класса');  // Создаем объект для рефлексии класса
$method = $class->getMethod('Имя метода');   // Получаем метод по имени
$params = $method->getParameters();   // Получаем массив с параметрами
$paramName = $params[0]->getName();   // Берем первый элемент массива, он имеет тип ReflectionParameter, и получаем его имя.

Можно сразу создать объект для рефлексии метода "напрямую":

$method = new \ReflectionMethod('Класс', 'Имя метода');
// Далее, аналогично

С помощью рефлексии можно не только получать имена параметров, но и их типы, значения по умолчанию. Можно получать даже док-блоки для методов/свойств и тд. С помощью рефлексии, например, работает doctrine orm. Он использует аннотации (как один из вариантов конфигурации) для описания сущностей.

Ну так и сделайте:

<form>
    <div>
         <input type="text" name="login">
    </div>
   <!-- -->
    <div>
        <input type="text" name="password">
    </div>
    <div>
        <div>
            <input type="submit" name="go">
        </div>
    </div>
</form>

Post::select()->join('subscribers', 'posts.author_id', 'subscribers.author_id')->where('subscribers.user_id', 1)->paginate(15);

Вместо 15 - число элементов на странице. Вместо 1 - id текущего пользователя. Ну и в select хорошо бы было перечислить нужные вам столбцы.

Отформатируем код, чтобы лучше читалось:

// ...
{
    filter: function(format) {
         return format.container === 'mp4';
    }
}
// ...

Здесь в свойство filter будет из функции возвращено булевое значение true/false в зависимости от того, равен ли format.container строке 'mp4'.
Принцип работы format.container === 'mp4' такой: это оператор сравнения, следовательно это выражение возвращает true - если равенство истинно, и false - если равенство ложно.

'str' === 'string' // false
'str' === 'str' // true

Если я правильно вас понял, это относится не к php, а к sql:

INSERT INTO `table` (`column1`, `column3`) VALUES ('test', 'value')

При таком запросе столбец column1 получит значение 'test', а столбец column3 - значение 'value'. Конечно же, вместо прямого подставления значений нужно использовать плейсхолдеры:

INSERT INTO `table` (`column1`, `column3`) VALUES (?, ?)

А можно и так:

INSERT INTO `table` set `column1` = 'test', `column3` = 'value'