Дмитрий Евграфович

почитайте о prepared statements на хабре, а об этом движке забудьте, как о страшном сне.

Используйте канвас библиотеки, например Paper.js, php тут вообще неуместен, разве что данные в json формате передавать для отрисовки.

Использовать очереди. Добавлять задачи в очередь, котоыре будут запускаться из командной строки без лимита времени.

На insales заведите. Либо на shopify, если для зарубежного клиента. Там только шаблон надо сверстать.

Nginx и apache умеют. lmgtfy.com/?q=%D0%BD%D0%B5%D1%81%D0%BA%D0%BE%D0%BB...

Добавить поле с типом дата и назвать его, например 'betting_until'. Записывать туда точное время закрытия и далее либо сразу выборку делать по бд такую, чтобы текущее время было меньше этого поля, либо в логике писать аналогичную проверку этого поля.

Чистить память как вариант. Обнулять переменные после отработки.

От одной формулировки вопроса у меня волосы зашевелились.

У любой cms в опенсорсе функционал предоставляет больше возможностей как минимум в силу того, что вы сможете сами его дописать. В инсейлзе же приходится для сторонних интеграций заводить еще один сервер с прокладкой и общаться через апи, либо извращаться с js в шаблоне и то не факт, что получится как надо.

Код в методе modal() не проверял, но если там все верно, то почистите кэш опенкарта и vqmod, посмотрите htaccess (мало ли, может там были какие-то изменения внесены, но вряд ли), в крайнемм случае перезапустите сервер. Должно работать, я подобным образом писал модуль быстрого заказа в свое время, только в отдельном контроллере.

1. создаете файл наподобие config.php с массивом "параметр" => "значение", 2. создаете таблицу в базе с двум столбиками "параметр" и "значение". 3. При инициализации приложения читаете сначала массив из конфига, затем все настройки из базы (с конвертацией их в такой же массив) и сливаете эти два массива в один, перезаписывая значениями из базы данных значения из конфига в случае, когда настройки одинаковые.

Вроде никаких подводных камней нет.

Плюсую за vcs. Попробуйте использовать интеграцию с тем же гитом. Насчет дополнительных возможностей - зарегистрируйтесь в инсейлз, поредактируйте шаблон, а затем посмотрите, как там отображаются изменения в истории. Интеграция с системой контроля даст такие возможности и куда больше.

Я не знаю задач, которые перед вами стоят, но может просто дать пользователя доступ к данным по апи и пускай на своих серверах творят, что им вздумается?

Есть много статей, может неявно, но рассказывающих о проектировании подобного типа приложений, надо лишь зайти в гугль. Вот несколько хороших, которые пришли на ум: https://habrahabr.ru/company/latera/blog/280196/ https://habrahabr.ru/post/231213/ https://www.insight-it.ru/highload/2011/arkhitektu...

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

Тут уже отвечали на этот вопрос, посмотри в поиске, там есть хорошие советы по книгам. То, что ты будешь учить php 5.6 вместо 7 абсолютно несмертельно, о различиях между ними потом прочтешь, благо их не так много. А php right way хорош, наверное даже обязателен, но читать эти рекомендации придется в оригинале, ибо половина русского там сделана каким-то автопереводом (может сейчас доработали, не знаю)