1. Главная
  2. vlucas

vlucas: Комментарии

Главные вкладки

2 июня 2017 в 16:02

Для меня сейчас непонятен момент с пользователями.
Я не очень силен в linux...
Если вынести папки ядра из директории пользователей, необходимо будет завести пользователя под эти нужды, не от root же обновлять потом? И не будет ли проблем с доступом к ним?

2 июня 2017 в 14:55

Может не по теме, но очень близко:

Имею:
VPS сервер на котором есть 2 (и более) пользователей, у каждого, стандартно, своя директория веб-сервера, папка www, где лежат папки сайтов.

Сайты у обоих пользователей на drupal 7. Git репозитории хранятся на уровень выше сайтов, т.е. директория сайта www/site.ru, директория git репозитория для него www/git/site.ru.

В репозитории весь проект, вместе с ядром..., contrib модулями..., кроме sites/*/files, sites/*/private.

8 декабря 2016 в 15:44

«Если включено кеширование всей страницы, то это бесполезная задача, а вообще вам сюда видимо »
Т.е. необходимо очищать кеш страницы на которой помещен блок?

12 июля 2016 в 21:34

1. заведите git репозиторий проекта на удаленной машине (его можно вынести из рабочего каталога)
2. git clone
3. далее вносите изменения, тестируете на локали и пушите на продакшн, если, конечно, один работаете

11 июля 2016 в 23:43

@Orion76 об этом и не просят, за совет спасибо.

@Andruxa
«Это решение было продиктовано тем, что на разных доменах - разные структуры-иерархии разделов каталога, и сами разделы разные»
У меня все одинаковое, товаров всего 1000, без атрибутов, просто не хочется громоздить всего, ведь проблема, на первый взгляд, довольно простая...

11 июля 2016 в 23:01

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

11 июля 2016 в 22:42

В данном конкретной случае, думаю, не проще, тем более не вижу смысла плодить базы, если требуется всего-то только менять цены, которые "на лету" и так можно сменить. Да ресурсы на те же базы? Администрировать все сайты? Или писать экспорт изменений во все остальные базы при добавлении продукта? Это решение напомнить CTR-C CTR-V

11 июля 2016 в 22:00

Спасибо за обзор.
Цены буду рассчитывать исходя из наценки для конкретного домена рулесами. Здесь, я думаю, проблем не возникнет.

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

16 февраля 2016 в 14:38

Скажите в связи с этим: http://xandeadx.ru/blog/drupal/751, ничего ли не изменилось за последнее время с этой ошибкой views?
К сожалению с использованием данного модуля тоже возникает эта ошибка, а с решением без него работает нормально