LTS вроде поддерживает php7, но там маловато контрибных модулей.

У меня когда-то работал без патчей. PHP по-моему, был 5.2

Orion76 wrote:

Вот только drupal.org это англоязычный ресурс, т.е. если не бОльшая, то большАя часть единомышленников сразу отсеется.

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

Всё уже давно написано до нас.

itcrowd72 wrote:

Обновление с Д6 на Д7 в принципе беспроблемное.

Да как два байта обоссать. ...ули там делать.

Orion76 wrote:

А смысл? Если он не расчитан в сыром виде для использования на ЛЮБОМ сайте?

Тогда - в песочницу.

Orion76 wrote:

В каталог модулей drupal.org "принимаются" только готовые решения (модули) c достаточной поддержкой.

Да ничего подобного. Можно спокойно заливать свои модули на d.org в статусе Full project.
Будет висеть плашка This project is not covered by Drupal’s security advisory policy.
Если помогут пройти security check - уберется.

Странно.
hook_entity_presave и hook_entity_load обычно решают 99% потребностей.
И hook_entity_property_info_alter - остальной 1%.

Экспромт wrote:

Почитала, настроила.

Экспромт wrote:

Error connecting to the database: SQLSTATE[HY000] [1045] Access denied for user 'admin'@'localhost'

Нет, не настроили.

Алексей Пушкарев wrote:

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

Уверен, что если бы взялись за детальную проработку ТЗ на Битриксе, то выяснилось бы, что всё это реализованное и протестированное, решало бы задачу клиента на те же самые 80%.
А оставшиеся 20% точно как же стоили бы 80% разработки, если не хуже.

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

Ну, я даже не знаю...

alexo wrote:

Но нода публикуется везде.

А смотрите под админом с id=1 ? Ему можно всё, никакие ограничения не действуют.

512M - это ж вообще на всю виртуалку. Может, свопится, когда память заканчивается.

юзер - тот, под кем вы заходите по ssh (тоже не 100% верно, но на 99% это так)
Если ваш вебсервер запускает php от имени login1 или входит в группу login1 - то можно делать 440, иначе - 444

ftp-аккаунты и учетка друпала тут роли не играет.

alexo wrote:

А почему не 440

Допустим, у вас на сервере пользователь, под которым вы заливали файлы - user123
тогда у файлов и папок друпала владельцем будет user123 и группа - user123 (если на сервере не делались специфичные настройки)
права 440 означают, что пользователь user123 и пользователи, входящие в группу user123 могут читать файл, а все остальные - нет.

Ни о чем не говорит.
Сам вебсервер может быть запущен от www-data (а может - и от nobody), но если там апач и mpm-itk - то php будет исполняться от вашего пользователя.
В первом случае, надо дать права на чтение для остальных пользователей, т.е. 0хх5 на папки и 0хх4 на файлы.
Во втором - можно закрыть доступ для остальных, т.е. 0хх0 на файлы и папки.

В общем, если не владеете ситуацией, то лучше доверьтесь техподдержке.
Выставьте вручную 0444 на settings.php и 0555 на sites/default

Зависит, от какого пользователя/группы у вас работает вебсервер.

Попробуйте https://www.drupal.org/project/feeds_tamper_taxonomy_hierarchy/git-instr...

Согласен.

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

Во-первых, тут нетривиальный случай - использование собственных запросов в обход рекомендованной практики использования api.
Попробуйте так в проприетарном софте поступить - и гарантии лишитесь, и иск ещё впаяют за реверс-инжиниринг.
И требовать от разработчиков поддерживать все недокументированные случаи использования кода - это как-то наивно.

Во-вторых, восьмерка - это энтерпрайз.
Всё, баста карапузики. Никаких drush up на проде.
Дев-тест-стейдж-прод, система контроля версий, мердж реквесты, код ревью, система деплоя, и никак иначе.

OldWarrior wrote:

Задачи были нетривиальные и довольно сложные

Даже не пытался критиковать это решение. Действительно, бывают случаи, когда средств api недостаточно.
Речь о том, что такие сложные решения требуют особого внимания.

Разрабам 100500 раз твердили: юзайте api, не надо лазить в базу напрямую. А раз уж полезли - будьте готовы к тому, что что-то может пойти не так.
Обновление не критическое, нет никакой нужды накатывать его в срочном порядке сразу на прод. Сначала вдумчиво курим diff, затем усиленно тестим то, что изменилось, и уже затем выкатываем это в прод.