- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Как удалить плохие SEO-ссылки и очистить ссылочную массу сайта
Применяем отклонение ссылок
Сервис Rookee
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Есть простая самописная онлайн crm(+еще много всего к ней), сама суть скрипта не важна. Эту систему мы используем внутри компании, сейчас у каждого отдела установлена своя копия. При выходе новой версии обновляем каждую, и вот почему - каждый отдел просил и просит дополнительных фич, которые другим отделам не нужны и выводить их не нужно, т.е. индивидуальные штуки для конкретного отдела. Иногда эти изменения/дополнения касаются модулей, иногда ядра, иногда шаблона. Сейчас это просто инклюды файлов в разных местах скрипта. Соответственно при обновлении каждого версии начинается ад с перенесением нестандартного функционала в новую версию.
Как повернуть реку, чтоб версия срм была одна для всех отделов, а дополнительный функционал подгружался, допустим, в зависимости от настройки в профиле юзера? Чтоб добавление следующих дополнений было без шаманства, т.к. сейчас все только начинается, а дальше дополнений будет больше и вести отдельную ветку разработки под каждый отдел не хочется.
Боюсь, что поздно решать проблемы архитектуры. Изначально надо было нормально проектировать.
Боюсь, что поздно решать проблемы архитектуры. Изначально надо было нормально проектировать.
Сейчас еще возможно все написать с нуля, вопрос в том - как? Проект, вернее его часть, которая срм, небольшая.
Не вижу особых проблем.
Подгружать в виде модулей, как-то разделять конфиг файлы.
Или 1 единый и дальше чтобы он как-то обозначался (разные группы настроек), в зависимости от отдела.
Модульность + ACL, например, решит ваши проблемы.
Модульность + ACL, например,
+ конфиги в зависимости от
сейчас у каждого отдела установлена своя копия.
* по сути всё просто
- держать все файлы в одном экземпляре
- различать конфиги, например, по имени домена ($_SERVER['HTTP_HOST'])
- использовать БД, модули и прочие различающиеся части в зависимости от конфига.
По возможности всё общее выносить в общую часть.
p.s.
Есть простая самописная онлайн crm
При выходе новой версии обновляем каждую
У вас своя(?) CRM с регулярными новыми версиями и нет понимания, как лучше её допиливать? Быть может поинтересоваться у разработчиков CRM?
Сейчас еще возможно все написать с нуля, вопрос в том - как? Проект, вернее его часть, которая срм, небольшая.
Я бы посоветовал делать на друпале, вопрос в другом - готовы ли вы к тому что функционал, а точнее то что было в CRM надо будет писать возможно с нуля, возможно модулями под друпал, или вы ищите конкретный двиг CRM но чтоб можно было отдельные части движка разграничивать для разных отделов?
+ конфиги в зависимости от
В зависимости от роли(при использовании ACL или RBAC), наиболее логично, имхо.
PS В целом странно организовано, разные копии, разные шаблоны, ядра:) Поддержка этого дела - ад адский.
---------- Добавлено 04.08.2013 в 18:55 ----------
Я бы посоветовал делать на друпале, вопрос в другом - готовы ли вы к тому что функционал, а точнее то что было в CRM надо будет писать возможно с нуля, возможно модулями под друпал, или вы ищите конкретный двиг CRM но чтоб можно было отдельные части движка разграничивать для разных отделов?
Не, лучше вордпресс, для crm то..
Не, лучше вордпресс, для crm то..
Если вы пытаетесь хамить то изучите для начала возможности друпала, или вы реально полагаете что вордпресс подойдет?
Если вы пытаетесь хамить то изучите для начала возможности друпала, или вы реально полагаете что вордпресс подойдет?
С друпалом уже утомлять начинают тут.
Скоро сервис сбора позиций будут советовать на друпале делать...