Vitsliputsli

В разных ОС разные форматы исполняемых файлов, т.к. ОС должна понимать как загружать и выполнять файл.
Java такой же компилируемый как и PHP, это интерпретируемые языки, но за счет JIT-компиляции их, наверное, могут называть компилируемо-интерпретируемыми.

Для локального использования (разработка/отладка), проще всего запускать Apache/nginx от пользователя под которым работаете.

Вам нужно будет получать данные изнутри json прямо из БД? Если не нужно, то вполне нормальное решение. Даже если нужно и БД поддерживает json, то можно, если, конечно, вы не будете делать отбор по этим сущностям.

dialog

Как делать запрос зависит от того, как хранятся данные в БД.
А если вы хотели спросить как это хранить в БД, то если количество рек и перевозчиков может быть любое, то можно использовать модель Attribute Entity Value. Но собирать данные по такой модели сложно, а при неопределенном кол-ве столбцов нужно будет динамически собирать запрос. Как уже написали используется для этого pivot, это очень затратная операция, так что если есть возможность лучше рассмотреть другие варианты.

prefer - это предпочтение, если не будет выбранного, загрузит другой.
source - исходники, то что нужно, если вы хотите править компонент (git).
dist - дистрибутив, то что нужно, если подключаете в прод, подключается быстрее (zip).
А будет ли там документация, тесты и примеры зависит от того, положат их туда при сборке или нет.

Примерно так:

$sel = mysql_query("
    SELECT DISTINCT(`seller_id`)
        FROM `oc_ms_seller`  
        WHERE categ REGEXP '(^|,)$cat_id($|,)'", $link);

очень плохое решение хранить в таком виде, весь смысл реляционных СУБД теряется. И переменные лучше байндить.

$message = 'Сообщение';
$dann = require 'app/view/patch/' . $patch . '.php';

Тогда все работает, но файл подключается сразу в скрипте а не в нужном месте сайта. В переменную $dann содержимое не заносится.

Не очень понятно что хотите сделать. А в $dann ничего не приходит, потому как в подключаемом файле должен быть return возвращающий то, что вам нужно.

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

Master = production, то что в master, то должно быть и в продакшн, не может быть никаких непроверенных коммитов в master, иначе это уже не master. Поэтому пересмотрите свою работу с git. И, как правильно замечено, прочитайте про gitflow, имхо, оптимальная система ветвления.

Listener не запущен, его нужно запускать отдельно.

Прочитайте про KPI, а параметры зависят от вашего производства и что конкретно вы хотите получить. Четко сказать сложно, потому как есть такой закон в экономике, когда вы вычислили параметры влияющие на нужную вам величину и начинаете контролировать эти параметры, связь исчезает. На практике выглядит так: вы хотите увеличить скорость обработки заявок, вычислили, что заявки долго никто не берет в работу и потому скорость низкая. Начинаете контролировать этот параметр, и заявки начинают браться в работу быстро, но их по-прежнему делают долго, т.к. время теряется на других стадиях. Кажется, что нужно просто повесить на контроль еще один параметр, но и там обнаруживается, что не все просто.
Проще, если сотрудники выполняют одинаковую работу, время которой четко определено, тут можно установить норму труда и от нее отталкиваться.

На скорость получения данных не влияет, т.к. это инструмент контроля целостности. И находится он должен в БД, т.к. вынести его оттуда проблематично, представьте как вы будете делать проверку на уникальность поля добавляемой записи в таблице с миллионами записей.

JOIN users S on S.id=IF(93=sender_id, sender_id, recipient_id)
JOIN users R on R.id=IF(93=recipient_id, sender_id, recipient_id)

По-моему первый IF всегда будет давать 93 и в нем нет смысла.

Проверьте план запроса, почему-то мне кажется, что оптимизатор будет некорректно анализировать неоднозначные условия соединения, из-за того что в разных ситуациях нужно выбирать разные индексы, он скорее всего предпочтет full scan. Но надо проверить.
Я бы все-таки соединял по однозначному условию, а уже вывод делал условным, через CASE.

А приватный ключ? По хорошему на другой машине надо создать новую пару ключей.

Можно еще так:

{if $smarty.session.current_user_group_name|in_array:['admin','realtor']}

в принципе, in_array можно и в чисто php-шном синтаксисе использовать

Redmine, когда пользовался мне показался оптимальным инструментом для управления проектами. Сейчас более популярна Jira, хотя это баг-треккер и до системы управления проектами его можно развить плагинами. Хотя, имхо, в Redmine тоже самое работает лучше и из коробки.
Ну и не маловажный фактор, Redmine - бесплатен, Jira - платная, причем платить нужно практически за каждый плагин.