adano wrote: Форумное комьюнити мертво.

И только всякие зомби пишут об этом на форуме, да?
В общем, это сильное преувеличение.

Мессенжеры это совсем не о том. В них невозможно накапливать и сохранять знания.

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

http://www.youtube.com/embed/**** - надо править ссылки на ролики. Чем у вас они делаются вам виднее, возможно просто в контенте поправить, возможно какой-то модуль генерирует ссылку по id, тогда его приводить в порядок.

Вы, похоже, совсем не понимаете, что я предлагаю. Возможно я много просто слишком написал, конечно...

У автора вопроса всё уже на VPS, облачном. У амазона нет просто хостинга же.
C ec2 не получиться просто так работать по smtp с чем-то снаружи. Там тупо заблокированы порты.
Есть amazon ses, с которым можно. Ещё можно снять ограничения через техподдержку, и тогда поднять свой почтовик, или использовать как предложено внешний сервис.

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

Амазон это не какой-то готовый хостинг, там можно хостинг создать, и довольно разными способами, при том.
Вообще, с уровнем знаний, о которых говорит вопрос, на AWS легко выстрелить себе в ногу и потратить дофига денег. Советую вам взять просто классический VPS у какого-нибудь DigitalOcean - ваш бюджет будет куда предсказуемее и сохраннее...

Не правильный вопрос.
Правильный: Как отправляется почта в вашем случае? Может-ли так отправляться почта на вашем хостинге?

Вот такая команда выполненная в консоли на том хостинге что-то скачивает?
curl -o admin_toolbar_version.xml https://updates.drupal.org/release-history/admin_toolbar/current
Если да, что именно оказывается в файле admin_toolbar_version.xml?

Такое разделение обязанностей возможно где-то в крупной компании.
К тому же, специализация не должна быть в принципе начальным этапом - основы знать надо всё равно. Иначе будут постоянные проблемы. Правильнее учить математику, программирование, и только потом углубляться в обработку данных, и начинать на этом специализироваться. А не проходить какой-то обзорный курс и думать, что с этим можно будет полноценно работать...

Google collab это песочница для запуска python скриптов, насколько я понимаю. Возможно там есть какой-то api, у него тогда есть документация, и надо читать, и интегрировать, если это возможно.

Интеграция будет примерно одинаковой, на чём бы не писался веб интерфейс. А делать на django с нуля сложный сайт, будет конечно сложнее, чем на любом готовом движке.

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

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

Интеграция может быть очень разной, от общей базы, до шин и очередей сообщений.

Этот вопрос имеет отношение к настройке веб сервера, не drupal, если редирект делается средствами веб сервера, а не в drupal. А если в drupal, то загрузка конфигурации, конечно раньше маршрутизации, и нет ничего удивительного в таком поведении...

Какой у вас веб сервер, и какой конфиг? Где и как прописан редирект?
Вы случайно не с помощью встроенного php-cli веб сервера запускаете приложение?

Она совершенно не актуальная для 8/9. Всё коренным образом изменилось.

Думаю, вам никто вот так в общем виде, просто не сможет ответить на данный вопрос, да и смысла в нём довольно мало.

Если любопытно, то можно использовать xdebug, например, выполнить трассировку нужного вам запроса и посмотреть call stack в вашем конкретном случае, с вашим набором модулей и.т.п.

Но если у вас есть какая-то конкретная задача требующая ответа на такой вопрос, то лучше её и сформулировать в виде конкретного вопроса.

Добавлю, что все ваши файлы должны быть в пределах /hosts/iubp/. Возможно, где-то указан вместо относительного абсолютный путь.

Ага.

akhmetshin wrote: пиксель перфект верстку

Может, только требовать этого совсем не всегда разумно, точнее почти никогда. Как и полной идентичности отображения на разных устройствах, если оно не ломает смысл/картинку.
Абсолютное совершенство не достижимо, и пусть так и остаётся... Лучше вовремя остановиться, и выпустить нормальный продукт за разумные деньги, не потратив бесконечного времени.

Drupal довольно модульная штука, и его тема оформления, не отдельные html страницы с плейсхолдерами, а скорее набор иерархии шаблонов. Разделить вёрстку сделанную без понимания этого факта может быть весьма не тривиальной задачей, иногда требующей фактически переделать работу заново.
А если там присутствует ещё и JS, и его тоже писал кто-то без понимания, куда и как это будет интегрироваться, это может стать сущим адом.

Drush работающий с drupal 7 умеет работать с php 7.x, и кстати, наверняка есть не только php-cli 7.3, но и постарше под другим именем.

jura12 wrote: P.S. а вот сайты на удаленных хостингах на друпал 7 обновлять сложно. думаю сначала организовать автоматический инкрементальный бэкап.

Composer не требует какой-то централизованной установки и каких-то привилегий, так можно, но совершенно не обязательно.

По своей сути, это просто упакованная с помощью phar пачка скриптов на php.
На большинстве хостингов сейчас, он уже есть, а где нет, вся его установка, это просто закачка файла по тому же (s)ftp.
В большинстве случаев, доступы для входа по ssh на хостинг те же, что и первичный ftp аккаунт. Часто он просто единственный и есть, так что с клиента даже лишней информации не надо трясти.

При обработке одного запроса drupal будет использоваться фактически 1 ядро. Это будет фактически линейная цепочка вызовов php-mysql-php-mysql-php и.т.п. Каждый элемент которой, в каждый момент времени сможет занять только одно ядро. И на одном быстром ядре, запрос будет обрабатываться быстрее, чем на любом количестве медленных, просто потому, что остальные не смогут быть загружены в рамках одного запроса. То, что таблицы не блокируются, это плюс для соседних запросов, но не для этого же. У нас же тут не новомодно асинхронное всё.

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

Grenuy wrote: В рамках веб сервера apache nginx mysql умеет паралелить, а это 99% всего что нужно веб серверу.