Здесь вы присваиваете алиас команде /opt/php8.2/bin/php -d memory_limit=500M ~/composer.phar. Если она у вас в таком виде нормально работает, и с алиасом должно быть всё ок.
Крайне не рекомендую слепо следовать этим рекомендациям не понимая, что меняется и зачем.
Это совсем не кнопка "сделай хорошо". А как и различные pagespeed, и подобные инструменты, это набор общих рекомендаций, исполнение которых, в определённых условиях, может помогать, может не помочь вообще в конкретной ситуации, а может сделать даже хуже в определённых ситуациях.
Например, такой здоровый innodb_log_file_size не часто нужен в принципе. innodb_buffer_pool_size делать такого объёма, возможно, тоже не нужно в вашем случае, даже если базы суммарно в вас и больше и.т.п.
Так это не техническая проблема - если клиент не хочет оплачивать реботу, вероятно её не стоит вообще делать.
Обновление с 7 до следующих версий это фактически создание нового сайта и миграция данных... Это не какая-то дешёвая рутинная операция. Если клиент этого не понимает, ну увы. Может и не надо с ним работать?
Ну во-первых, надо наверное почитать документацию о логе медленных запросов, установить нужный лимит на длительность запроса и.т.п.
Также в realtime можно посмотреть что происходит в mysql/mariadb с помощью утилиты mytop.
При этом, надо смотреть ещё потребление ресурсов. Там куда интереснее будет картина - потребление памяти в случае apache должно быть заметно больше, и больше зависеть от количества подключений. А именно в скорости разница не велика, собственно всё время почти в php-fpm, который тут одинаков.
Ну и сравнивать имеет смысл c apache + mod php. Apache + php-fpm в принципе довольно странная связка.
Вопрос масштабов и стоимости поддержки.
Но в целом да, свои мелкие почтовики имеют не много смысла. Всё равно надо их обслуживать, проверять на попадание в те же блеклисты, что не всегда хорошо автоматизируется. Да и вообще, почта, даже только исходящая, это всегда лишние проблемы и потраченное время.
Я, вот, всё это неплохо умею, но почта моих доменов обслуживается одним из хостеров за мелкую копеечку, а не на одном из моих серверов.
Вообще-то не совсем всё так плохо. Часть адресов действительно находится в блек листах, если на них были кривые почтовики, или ими пользовались спамеры, но это решаемая проблема.
SPF это просто TXT запись, и она должна быть просто правильно указана. Т.е. указано откуда можно принимать вашу почту.
А вот с DKIM, всё куда сложнее. Это криптографическая подпись письма на стороне отправителя. Оно не только в DNS, оно и на сервере, собственно, подписывать должен какой-то софт, который надо настроить, сгенерировать пару ключей, и публичный ключ поместить в ту самую DNS запись.
Если не используется внешний почтовый сервер, конечно нужно - чем-то посылать-то всё равно нужно.
Всё что ставится на стороне Drupal, требует чего-то внешнего:
это может быть и внешний сервис
почтовый сервер на стороне той же виртуалки
почтовый сервер на стороне хостера
Модули просто дают разные дополнительные возможности, например, делать атачи, использовать не только php mail(), использовать какие-то не smtp сервисы для отправки и.т.п. Т.е. расширяют возможности взаимодействия с почтой, но не доставляют её клиентам непосредственно.
Так она чаше всего и будет в спаме - этого мало.
Как минимум, надо настроить SFP запись, DKIM, например с помощью opendkim, и PTR соответствующий имени хоста почтовика.
Sendmail такое себе решение, сложное и устаревшее.
Лучше и проще настроить postfix или exim.
Чтобы настроить почтовик надо немало знать, на самом деле о том, как это всё работает, чтобы настроить его для своей задачи. Брать какой-то пошаговый howto довольно бесполезно в любых ситуациях, а в этой и подавно... Даже если будет работать, доставляемость чаще всего будет никакая. Без этих знаний куда разумнее будет использовать готовый внешний сервис.
Аpache + mod_php быстрее чем apache + php-fpm, на самом деле. Apache не ставят не из-за скорости обработки отдельных запросов, а из-за ресурсоёмкости излишней на каждый запрос, даже к статике.
Надо было запускать друш с нужной версией php просто.
Как-то так: /path/to/fresh/php-cli /path/to/drush
Пути конечно могут быть разными, но скорее всего для php что-нибудь вроде /usr/bin/php8.1
Какая-то каша. /vendor/bin/drush это абсолютный путь, он может быть только один и явно странный.
Под каким пользователем ведётся разработка?
Чтобы было удобнее, можно делать отдельных пользователей для отдельных сайтов, например.
Лучше делать как предлагает @yaro, но если хочется через $database->query(), то надо не пытаться запихнуть аргументы прямо в текст запроса, а использовать плейсхолдеры для аргументов, а их передавать в массиве вторым аргументом qurey():
VasyOK wrote: Или мне .bashrc для каждого сайта создавать?
Для каждого пользователя, скорее...
На самом деле, просто не под рутом это надо сделать, а под пользователем, который работает с сайтом, и соответственно не в /root/.bashrc, а в таком же файле в домашней папке этого пользователя.
Боюсь, что для drush arb не добавили нужного аргумента.
Можно не пользоваться drush для архивирования, вообще говоря. Или только дамп им снимать, чтобы не задумываться о пароле к базе, а файлы нужные паковать tar, например.
А что именно делать в вашей конкретной ситуации, зависит от задачи. Например, для резервного копирования, обычно достаточно снять дамп и сохранить /sites/, или даже sites/*/files, если используется система контроля версий для кода, и это лучше делать специализированными инструментами автоматически и регулярно.
Вопрос по composer
Здесь вы присваиваете алиас команде
/opt/php8.2/bin/php -d memory_limit=500M ~/composer.phar
. Если она у вас в таком виде нормально работает, и с алиасом должно быть всё ок.Ускорить views
Очень зависит от запроса. До этого могут происходить разные join и сортировки, которые и составят основную нагрузку которую создаёт запрос...
Советую познакомиться поближе с отладкой sql запросов, начиная с EXPLIAN.
Ускорить views
дубль
Ускорить views
Крайне не рекомендую слепо следовать этим рекомендациям не понимая, что меняется и зачем.
Это совсем не кнопка "сделай хорошо". А как и различные pagespeed, и подобные инструменты, это набор общих рекомендаций, исполнение которых, в определённых условиях, может помогать, может не помочь вообще в конкретной ситуации, а может сделать даже хуже в определённых ситуациях.
Например, такой здоровый innodb_log_file_size не часто нужен в принципе. innodb_buffer_pool_size делать такого объёма, возможно, тоже не нужно в вашем случае, даже если базы суммарно в вас и больше и.т.п.
Д7 перенос на Д10. Миграции не переносят тему оформления. Так? Что же делать?
Автоматизацию работающую не на паре тройке простых случаев будет _очень_ сложно написать...
Д7 перенос на Д10. Миграции не переносят тему оформления. Так? Что же делать?
Так это не техническая проблема - если клиент не хочет оплачивать реботу, вероятно её не стоит вообще делать.
Обновление с 7 до следующих версий это фактически создание нового сайта и миграция данных... Это не какая-то дешёвая рутинная операция. Если клиент этого не понимает, ну увы. Может и не надо с ним работать?
Идет большая нагрузка ядер процессора у mariadb
Ну во-первых, надо наверное почитать документацию о логе медленных запросов, установить нужный лимит на длительность запроса и.т.п.
Также в realtime можно посмотреть что происходит в mysql/mariadb с помощью утилиты mytop.
Сравнение производительности apache-fpm и nginx-fpm в ddev с помощью siege
При этом, надо смотреть ещё потребление ресурсов. Там куда интереснее будет картина - потребление памяти в случае apache должно быть заметно больше, и больше зависеть от количества подключений. А именно в скорости разница не велика, собственно всё время почти в php-fpm, который тут одинаков.
Ну и сравнивать имеет смысл c apache + mod php. Apache + php-fpm в принципе довольно странная связка.
На сайте не отправляется почта. На сервер надо что-то ставить?
Вопрос масштабов и стоимости поддержки.
Но в целом да, свои мелкие почтовики имеют не много смысла. Всё равно надо их обслуживать, проверять на попадание в те же блеклисты, что не всегда хорошо автоматизируется. Да и вообще, почта, даже только исходящая, это всегда лишние проблемы и потраченное время.
Я, вот, всё это неплохо умею, но почта моих доменов обслуживается одним из хостеров за мелкую копеечку, а не на одном из моих серверов.
На сайте не отправляется почта. На сервер надо что-то ставить?
Вообще-то не совсем всё так плохо. Часть адресов действительно находится в блек листах, если на них были кривые почтовики, или ими пользовались спамеры, но это решаемая проблема.
На сайте не отправляется почта. На сервер надо что-то ставить?
SPF это просто TXT запись, и она должна быть просто правильно указана. Т.е. указано откуда можно принимать вашу почту.
А вот с DKIM, всё куда сложнее. Это криптографическая подпись письма на стороне отправителя. Оно не только в DNS, оно и на сервере, собственно, подписывать должен какой-то софт, который надо настроить, сгенерировать пару ключей, и публичный ключ поместить в ту самую DNS запись.
На сайте не отправляется почта. На сервер надо что-то ставить?
То нужно что-то что позволит с ним работать, по нужному протоколу. Например, если это smtp, то это может быть и https://www.drupal.org/project/smtp, и https://www.drupal.org/project/symfony_mailer с smtp транспортом и наверняка ещё есть что-то.
На сайте не отправляется почта. На сервер надо что-то ставить?
Если не используется внешний почтовый сервер, конечно нужно - чем-то посылать-то всё равно нужно.
Всё что ставится на стороне Drupal, требует чего-то внешнего:
Модули просто дают разные дополнительные возможности, например, делать атачи, использовать не только php mail(), использовать какие-то не smtp сервисы для отправки и.т.п. Т.е. расширяют возможности взаимодействия с почтой, но не доставляют её клиентам непосредственно.
На сайте не отправляется почта. На сервер надо что-то ставить?
Так она чаше всего и будет в спаме - этого мало.
Как минимум, надо настроить SFP запись, DKIM, например с помощью opendkim, и PTR соответствующий имени хоста почтовика.
На сайте не отправляется почта. На сервер надо что-то ставить?
С минимальными знаниями внешний сервис. Их много.
Чтобы доставлялось как-то со своего сервера, минимально надо проверить и настроить SPF, DKIM, PTR. А также пробить ip виртуалки по спам листам.
На сайте не отправляется почта. На сервер надо что-то ставить?
Sendmail такое себе решение, сложное и устаревшее.
Лучше и проще настроить postfix или exim.
Чтобы настроить почтовик надо немало знать, на самом деле о том, как это всё работает, чтобы настроить его для своей задачи. Брать какой-то пошаговый howto довольно бесполезно в любых ситуациях, а в этой и подавно... Даже если будет работать, доставляемость чаще всего будет никакая. Без этих знаний куда разумнее будет использовать готовый внешний сервис.
Взял сервер. Сайта выдает: 403 Forbidden nginx/1.18.0 (Ubuntu).
Аpache + mod_php быстрее чем apache + php-fpm, на самом деле. Apache не ставят не из-за скорости обработки отдельных запросов, а из-за ресурсоёмкости излишней на каждый запрос, даже к статике.
Взял сервер. Сайта выдает: 403 Forbidden nginx/1.18.0 (Ubuntu).
Конечно нет, надо создать новый конфиг из этого шаблона, заменив там часть данных, например домен и путь до webroot.
Доступ к сайту Д8
Надо было запускать друш с нужной версией php просто.
Как-то так:
/path/to/fresh/php-cli /path/to/drush
Пути конечно могут быть разными, но скорее всего для php что-нибудь вроде /usr/bin/php8.1
Доступ к сайту Д8
drush uli если есть доступ из консоли.
Алис для vendor/drush/drush/drush. Как создать?
Будет работать только из корня проекта.
Алис для vendor/drush/drush/drush. Как создать?
Какая-то каша. /vendor/bin/drush это абсолютный путь, он может быть только один и явно странный.
Под каким пользователем ведётся разработка?
Чтобы было удобнее, можно делать отдельных пользователей для отдельных сайтов, например.
Точка с запятой MYSQl-запросе
Лучше делать как предлагает @yaro, но если хочется через $database->query(), то надо не пытаться запихнуть аргументы прямо в текст запроса, а использовать плейсхолдеры для аргументов, а их передавать в массиве вторым аргументом qurey():
Алис для vendor/drush/drush/drush. Как создать?
Для каждого пользователя, скорее...
На самом деле, просто не под рутом это надо сделать, а под пользователем, который работает с сайтом, и соответственно не в /root/.bashrc, а в таком же файле в домашней папке этого пользователя.
Что значит: mysqldump: Error: 'Access denied; you need (at least one of) the PROCESS privilege(s) for this operation'
Боюсь, что для drush arb не добавили нужного аргумента.
Можно не пользоваться drush для архивирования, вообще говоря. Или только дамп им снимать, чтобы не задумываться о пароле к базе, а файлы нужные паковать tar, например.
А что именно делать в вашей конкретной ситуации, зависит от задачи. Например, для резервного копирования, обычно достаточно снять дамп и сохранить /sites/, или даже sites/*/files, если используется система контроля версий для кода, и это лучше делать специализированными инструментами автоматически и регулярно.