Шутить изволите, Маэстро?))Может быть, сделайте.
Я ни разу не делал сайты на ICMS1, да и на двойке рабочих сайтов пока нет.
Какой из меня аналитик этих двух CMS?
И, конечно же, я не Вам предлагал делать обзор.)) Извините, если так выглядело.
Asket
+85
Репутация
91
Рейтинг
Я ни разу не делал сайты на ICMS1, да и на двойке рабочих сайтов пока нет.
Какой из меня аналитик этих двух CMS?
И, конечно же, я не Вам предлагал делать обзор.)) Извините, если так выглядело.
Loadырь, спасибо за уточнение. То же самое имел в виду, но одно дело мои предположения, а другое — совет мастера.
Новый функционал, действительно, часто не нужен (и не только на визитках и лендингах), но важны обновления связанные с безопасностью. Если они устанавливаются без правок шаблона, то вариант «фиксированного» шаблона может быть удобен.
Новый функционал, действительно, часто не нужен (и не только на визитках и лендингах), но важны обновления связанные с безопасностью. Если они устанавливаются без правок шаблона, то вариант «фиксированного» шаблона может быть удобен.
Залетела шальная мысль. Как, наверное, удобно на первой ветке: один раз сделал, настроил сайт и работает без замечаний и без ограничения срока годности.
Для определённых целей, наверняка, первый движок был доведен близко к совершенству. Может быть, даже был бы полезен сравнительный обзор возможностей CMS двух веток (включая возможности использования популярных дополнений).
Для определённых целей, наверняка, первый движок был доведен близко к совершенству. Может быть, даже был бы полезен сравнительный обзор возможностей CMS двух веток (включая возможности использования популярных дополнений).
Loadырь, Rainbow, Андрей, спасибо за ответы! Буду пока осмысливать.))
Хочу разобраться, чтобы быть уверенным в правильности своих действий. Мечу в профессионалы.))
Вроде, бывают обновления в которых новый функционал не получится применить без внесения изменений в шаблон?
Хочу разобраться, чтобы быть уверенным в правильности своих действий. Мечу в профессионалы.))
Да, так и делал.В первом случае делаете полную копию дефолтного шаблона и в его файлах вносите правки.
В смысле, вообще никаких изменений, не только шаблона, но и функционала CMS?Если больше изменений не планируется, то про этот шаблон можно забыть и при обновлении не смерживать.
Вроде, бывают обновления в которых новый функционал не получится применить без внесения изменений в шаблон?
Приветствую сообщество!
Хочется досконально разобраться в процессе обновления сайтов на ICMS2. Поиском по форуму ответов на свои вопросы не нашел.
Думаю, данное обсуждение может быть полезно и другим пользователям. Поэтому, если у кого какие вопросы по теме обновлений, можете задавать здесь.
Чтобы сделать сайт на своём шаблоне, я добавляю второй дефолтный шаблон, переименовываю его и вношу в него свои правки. Получается, что обновляться можно на дефолтном шаблоне, а потом перейти на свой.
В статье говориться, что перед установкой обновлений надо сравнивать сначала файлы дефолтного шаблона, а затем своего. Процетирую:
ВОПРОСЫ
1. Из выше приведённой цитаты получается вывод, что перед обновлением надо всегда вносить правки вручную и в дефолтный шаблон, и в свой.
Непонятно зачем в дефолтный?
В пакете обновления есть новые файлы шаблона. При установке пакета обновления, файлы дефолтного шаблона обновляются (проверил), но не знаю насколько корректно. (Например, папки и файлы, которые в новой версии должны быть удалены — остаются.)
2. В статье рекомендуется сравнивать файлы шаблона из предыдущей версии с файлами шаблона из пакета обновления.
А, нельзя просто заменить папку default в старой версии на аналогичную из новой версии?
Например, default в 2.9.0 заменить на default из 2.10.0, без всяких сравнений?
После чего обновиться (на дефолте), а затем, мерживать только свой шаблон?
3. Если обновляться на несколько версий, то надо устанавливать пакеты обновлений поочерёдно, а сравнивать и править шаблоны столько же раз сколько обновлений? Перед каждым обновлением вносить правки в дефолтный шаблон? А потом в свой?
Может быть, можно заменить папку default из самой старой версии на такую же из самой свежей версии?
Потом устанавливать обновления (на дефолте) по очереди.
После чего, мерживать папку своего шаблона с папкой default самой новой версии, а не всех пакетов обновлений по очереди?
В общем, требуется полная ясность в отношении алгоритма действий при обновлении сайта на дефолтном шаблоне и на «своём».
Спасибо!
Хочется досконально разобраться в процессе обновления сайтов на ICMS2. Поиском по форуму ответов на свои вопросы не нашел.
Думаю, данное обсуждение может быть полезно и другим пользователям. Поэтому, если у кого какие вопросы по теме обновлений, можете задавать здесь.
Чтобы сделать сайт на своём шаблоне, я добавляю второй дефолтный шаблон, переименовываю его и вношу в него свои правки. Получается, что обновляться можно на дефолтном шаблоне, а потом перейти на свой.
В статье говориться, что перед установкой обновлений надо сравнивать сначала файлы дефолтного шаблона, а затем своего. Процетирую:
В тексте будет идти речь о шаблоне default, однако, если у вас свой шаблон, то описываемые здесь изменения вам необходимо помимо дефолтного внести и в аналогичные файлы своего шаблона.
ВОПРОСЫ
1. Из выше приведённой цитаты получается вывод, что перед обновлением надо всегда вносить правки вручную и в дефолтный шаблон, и в свой.
Непонятно зачем в дефолтный?
В пакете обновления есть новые файлы шаблона. При установке пакета обновления, файлы дефолтного шаблона обновляются (проверил), но не знаю насколько корректно. (Например, папки и файлы, которые в новой версии должны быть удалены — остаются.)
2. В статье рекомендуется сравнивать файлы шаблона из предыдущей версии с файлами шаблона из пакета обновления.
А, нельзя просто заменить папку default в старой версии на аналогичную из новой версии?
Например, default в 2.9.0 заменить на default из 2.10.0, без всяких сравнений?
После чего обновиться (на дефолте), а затем, мерживать только свой шаблон?
3. Если обновляться на несколько версий, то надо устанавливать пакеты обновлений поочерёдно, а сравнивать и править шаблоны столько же раз сколько обновлений? Перед каждым обновлением вносить правки в дефолтный шаблон? А потом в свой?
Может быть, можно заменить папку default из самой старой версии на такую же из самой свежей версии?
Потом устанавливать обновления (на дефолте) по очереди.
После чего, мерживать папку своего шаблона с папкой default самой новой версии, а не всех пакетов обновлений по очереди?
В общем, требуется полная ясность в отношении алгоритма действий при обновлении сайта на дефолтном шаблоне и на «своём».
Спасибо!
Так, это Fuze Вас метафорами нахлобучил?))) О квартирах, домах и водопроводах...)Конечно же я сначала переговорил с ним.
Тогда, конечно, заказываем двушку без отделки, комнаты смежные, но с водопроводом и канализацией, лоджий не надо — балкона достаточно! Теперь всё встало на свои места.))
По первой редакции Вашего ТЗ, где Вы сообщали, что Fuze ещё не знает, что выбран исполнителем, логично было предположить, что всё придумали именно Вы.
Поэтому, по моему скромному мнению, DzurDzuk и Vikont задают дельные наводящие и уточняющие вопросы.
А, вообще, перечитал Ваше ТЗ — мощно! Такую круть и в коробку — это же не ступенька, а прыжок вверх на новый уровень!
Только, мое мнение не имеет значения, а считает ли Fuze Ваш вариант единственно верным или хотя бы оптимальным, мы не знаем.
На мой взгляд, инструменты для профессионалов должны продаваться отдельно и обновляться платно, но не мне судить, как удобней реализовывать.
Ideasdigger, не, тут ТС — паровоз, пусть тащит, если хочет и может.)) Ему и ТЗ писать и разработчика выбирать и мозги ему парить. Зато и получать, что заказывал.
Если ТЗ выполняется, то не может быть никаких претензий к разработчику.
И никаких хотелок от участников складчины, отдельно высказываемых разработчику. Один заказчик, один исполнитель. Остальные участники общаются с заказчиком, а не с разработчиком.
В первом посте ТЗ примерно изложено, другие варианты от участников обсуждения — только мысли в слух.
Я готов поддержать любой вариант, в том числе и со сторонним разработчиком.
Мне пока не надо, поэтому своих требований нет. В перспективе, может быть, обращусь к Вам, Ideasdigger, если можно.
Если ТЗ выполняется, то не может быть никаких претензий к разработчику.
И никаких хотелок от участников складчины, отдельно высказываемых разработчику. Один заказчик, один исполнитель. Остальные участники общаются с заказчиком, а не с разработчиком.
В первом посте ТЗ примерно изложено, другие варианты от участников обсуждения — только мысли в слух.
Я готов поддержать любой вариант, в том числе и со сторонним разработчиком.
Мне пока не надо, поэтому своих требований нет. В перспективе, может быть, обращусь к Вам, Ideasdigger, если можно.
Теоретически всё круто. Начинайте работать, деньги будут.))Но в любом случае site.ru/spr/firma.html = firma.site.ru = firma.ru = ЗАПИСЬ в типе контента Компании.
Таким образом, на сайте firma.ru не будет в поиске никаких страниц кроме главной?Таким образом, если пользователь, авторизованный на сайте site.ru переходит на сайт firma.ru, то он может думать, что он перешел на другой сайт, но на самом деле он перешел на внутреннюю страницу сайта site.ru.
Может быть не гуд для продвижения...
Если включать, отключать и снова включать, то, наверное, нужен 302 редирект.)если мы решим отключить сеть
Если складчины не получится, всё-равно уточните цену вопроса у разработчика. Может быть, в узком кругу тогда скинемся и пусть будет отдельное платное дополнение (с инвестициями от разработчика). Поскольку нашлись даже те, кто против.Немного подождем еще, а потом закроем тему.
одна файловая система + одна база + разные урл для фирм
А я поддержу любые варианты, на усмотрение разработчика.Именно так. Другие варианты мне тоже не интересны.
для сайтов на отдельных доменах 2-го уровня
Не вполне.Это учтено в первом посте.
Пользователь по редиректу перенаправляется на другой сайт, хочет оставить там отзыв или только комментарий к контенту — ему надо заново авторизоваться. Допустим, под «привязать отдельный домен» Вы имели ввиду сквозную авторизацию в том числе.Добавить возможность вместо поддомена привязывать отдельный домен. И перенаправлять на него редиректом. Ссылки в списке записей не изменять. Т.е., в списке так и останется ссылка на firma.site.ru, но с помощью 301 редиректа произойдет переход на domain.ru.
Потом пользователь возвращается на предыдущий сайт и видит, что в его профиле добавление контента не отобразилось — ни отзывов, ни комментариев, вроде бы, не делал.
Та же задача с привязкой типов контента друг к другу на разных сайтах.
Ага, сотни миллионов в рекламу вложили и не парятся.При этом авито также успешно продаёт возможность создания своих магазинов на сайте и другие вещи. Но как то никто не парится насчёт урла.
В 2011 году число рекламных расходов Avito на ТВ, в прессе и на радио составило 243 млн руб, в 2012 году — 568 млн руб, следует из данных «TNS Россия».
SEO к успеху Авито почти не имеет отношения.
Вы ещё приведите в пример её быстродействие и скажите, что «правильный» сайт должен быть столь же медлительным.
Шэльдэ бердэ бельдэ, спасибо за глубоко продуманный 1-й пост и другие, а так же, за проявленную инициативу.
В отношении поддоменов, вроде бы, со всем согласен, только слишком сложное задание, имхо.
Хочу акцентировать внимание на возможностях для сайтов на отдельных доменах 2-го уровня. Автоподдомены, тоже неплохо, но для ограниченных целей. Если уж продвигать отдельные сайты (брать дополнительные трудности, как отмечал Letsgo), то хотелось бы, на отдельных доменах.
Под мультисайтовостью понимаю решение задачи связи сайтов на нескольких доменах второго уровня в один тематический портал, то есть несколько сайтов на разных доменах, на одной базе данных, но с разными настройками.
1. Для пользователей сайтов на разных доменах должна быть доступна сквозная авторизация (не только регистрация как сейчас).
2. Подобно общей таблицы БД пользователей, назначать типы контента, которые будут использовать общую таблицу базы данных. Дубли, естественно, закрывать от индексации.
Такое дублирование позволило бы включать имеющийся механизм связей типов контента на разных сайтах.
Например, чтобы в профиле пользователя добавленный им список контента (статьи, объявления и т.д.) был одинаковый на всех сайтах портала.
То же самое для компаний, чтобы товар, добавленный на одном сайте можно было привязать и на другом.
В отношении поддоменов, вроде бы, со всем согласен, только слишком сложное задание, имхо.
Хочу акцентировать внимание на возможностях для сайтов на отдельных доменах 2-го уровня. Автоподдомены, тоже неплохо, но для ограниченных целей. Если уж продвигать отдельные сайты (брать дополнительные трудности, как отмечал Letsgo), то хотелось бы, на отдельных доменах.
Под мультисайтовостью понимаю решение задачи связи сайтов на нескольких доменах второго уровня в один тематический портал, то есть несколько сайтов на разных доменах, на одной базе данных, но с разными настройками.
1. Для пользователей сайтов на разных доменах должна быть доступна сквозная авторизация (не только регистрация как сейчас).
2. Подобно общей таблицы БД пользователей, назначать типы контента, которые будут использовать общую таблицу базы данных. Дубли, естественно, закрывать от индексации.
Такое дублирование позволило бы включать имеющийся механизм связей типов контента на разных сайтах.
Например, чтобы в профиле пользователя добавленный им список контента (статьи, объявления и т.д.) был одинаковый на всех сайтах портала.
То же самое для компаний, чтобы товар, добавленный на одном сайте можно было привязать и на другом.
Вы делаете интернет-магазины без SEO!?С SEO делать мультимагазин?
Вау… что тут скажешь...)
И, что? А, я говорил про ниши коммерческих сайтов.Про ниши я говорю информационных сайтов.
Полностью согласен.Вот вы желающий, а не жаждущий. Если бы у вас была актуальная задача сделать мультимагазин, вы бы перерыли всё и уже бы сделали.
Я не жду, у меня другие проекты по плану, но в перспективе магазин намечен.Но вы ждёте мультимагазин, хотя еще нет даже магазина и пока нет сроков, чтобы он был. Значит вывод — не особо вам это и нужно.
Однозначно, так и планирую делать, только, вожусь не с магазином и отвлекаюсь на другие дела постоянно, ничего не успеваю. Удивляюсь, как офразработчики столько успевают делать.Сделали бы, реализовали, потом часть прибыли направили бы на развитие Инстанта. Всё просто же)
Ну, например, сказал Вам Fuze, что за «Совместные покупки» — 150 тыр, если не ошибаюсь. Где тут пропорция 1 к 20? Всё по честноку.Потому что за 1000 рублей сборов требовать и просить будут на 20 000.
Чем больше система расширяется — тем хуже рост и больше багов.
Разумеется, можно вообще сделать все виды сайтов в одном. Только кроме увеличения проблем это мало что даст.
Если бы была большая команда и все это было бы платным, можно было бы разделить движок и продавать сборками: вот молл, вот соцсеть, вот блог, вот лендинг, вот форум. Все занимались бы своей сборкой.
В целом, согласен, только все виды сайтов в одном — не надо и молл, разумеется, может быть платным компонентом.
Команда всего из двух человек, которые вынуждены работать над другими проектами (по сообщениям Владимира, над CMS — в свободное от основной работы время.)
Поэтому, дело, имхо, не в команде, а в отсутствии достаточного финансирования.
Была бы аудитория Инстант миллион ежедневных пользователей форума и ситуация с новыми дополнениями была бы другой.
Не возьмусь тут анализировать истории успеха популярных движков.Всё это есть во многих движках, что то нигде это особо не проявилось на успех.
Я сказал, только то, что мультисайтовость и многопользовательский магазин мне нужны (и готов за них заплатить) а Вы, вероятно, не понимаете зачем.
Мне нет дела до других движков, я переживаю за Инстант. Похоже, что голый энтузиазм офразработчиков поугас и требуется поддержка.
Да, пусть себе стараются, кто же против. Только, целевого трафика много не бывает (за редкими исключениями).Мультимагазин — его хотеть хорошо. Я делал несколько раз мультимагазины на заказ, что толку? Каждый продавец сейчас старается свой актив развить, то есть свой сайт.
На что продавцов-то ловили на рассылки, уговоры и рекламные слоганы? На перловку не пробовали?Побарахтались, а желающих размещать товары то и не особо.
Думаю, не мне Вам объяснять, что начинать надо с SEO и не делать универсальных магазинов подобных Алиэкспресс. Сами же про ниши всё время твердите. Если на магазин будет целевой трафик, то и желающие размещать свои товары найдутся.
И, что Вы хотите сказать в своём критиканстве, где предложения?
Что InstantCMS не нужен свой магазин? Пусть пользователи голосованием своими деньгами решают.
Может быть и не нужен, тогда желательно какой-то шлюз с профессиональными движками интернет-магазинов.
Хотя, многие задачи можно было бы комфортно решать на ICMS, с успехом достигая поставленных целей. Зависит от того, что за магазины.
Поэтому, я за профессиональный многопользовательский магазин на InstantCMS, желательно, от официальных разработчиков.
Да, слыхал.)) Я говорил именно про эти самые «офф внедрения» и ни о каких других. Последние две складчины инициировали авторитетные разработчики по согласованию с Fuze, насколько я понимаю.
Хоть об одной успешной складчине слышали? Исключая офф внедрения.
Аукцион для того, чтобы в первую очередь реализовывались самые востребованные дополнения или самые выгодные для офразработчиков.
Мало того, что элементарно не знаете правил лицензии, еще и предлагает анти маркетинг.
Похоже, что в Вашем представлении правила стандартной GNU GPL v2, v3 лицензии только Вы понимаете, судя по Вашим многочисленным спорам в том числе с R2 и Fuze. Не хочу тратить время на поиски ссылок тем более, что споить с Вами дело не благодарное.
Я не Вам предлагал, а высказал мысли. Может быть и нельзя делать платными обновления — не мне решать.
А знаете, что разработчик имеет право вообще изменить тип лицензии когда захочет?
Регулярные, желательно, ежемесячные складчины на мелкие доработки и хотелки.
Еще одна антирыночная утопическая идея.
Антирыночная-то почему?