- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
NetBeans + Прямые руки.
но ведь это не cms. разговор о системах управления, а не средах разработки.
в ответ могу сказать, что Symfony + прямые руки и тоже буду прав
Как раз словечко от редактора, т.е. контент-менеджера вашими словами.
Нахожу админку очень даже удобной, а размещение материалов с JCE вообще комфортным. Правда, это когда понял всю логику взаимодействий, меню-разделы-категории-модули-компоненты и т.д., на что мне, неопытному в сих вещах, понадобилось месяца с два. Сейчас без проблем правлю даже css... не зная языков.
Ладно вам спорить... В зависимости от ТЗ мы выбираем cms, ессно блог на Джумле не буду делать, а возьму ВП. А Джумла удовлетворяет все мои запросы по сайтам, поэтому и сижу на ней. Если нужно было например сделать сложный сайт вакансий и т.п., то взял бы Друпал, но такие сложные сайты я не делаю.
P.S. Выбор инструментов для создания сайта зависит от потребностей заказчика или вас. Не все йогурты одинаково полезны.. Кто-то на ДЛЕ делает, кто-то на других cms. Главное что-бы сайт был полезным, а не очередным ГС, коих в сети 100500...
? include в статью php любой скрипт = любой тип :)
Зачем такие извращения? Зачем тогда вообще джумла нужна? Почему бы не делать на файлах и инклудах?
Невозможность создания своих наборов категорий, тегов.
? непонятно
В версии 1.5 можно было сделать только так: выпадающий список с категориями, справа выпадающий список с подкатегориями. Все.
Невозможно сделать несколько категорий у которых будет свои выпадающие списки подкатегорий.
Насчет тегов точно не помню, то уверен что сделать несколько наборов (категорий) тегов нельзя (например теги про погоду, теги про город и т.д.).
Много необходимых плагинов/модулей и т.д. в платном виде.
Все платные давно в паблике
Со встроенными шелами?
Нет единого центра переводов, невозможность установить за 10 сек доступные переводы для ядра и доп. плагинов.
Есть, в lang сразу кидаете руский перевод и всё.
Дайте ссылку на единый центр переводов на все доступные языки ядра и все доп. модулей.
"свои типы материалов" - изврат друпала, это мое мнение.
Материал должен оставаться материалом, т.е. иметь текстовое содержимое. Нужен каталог - используем компонент каталога (свои таблицы в БД, свои индексы), нет нужного функционала - модифицируем, в конце концов пишем (заказываем) свой. И так далее. Валить все в одну таблицу БД не лучшее решение.
Ограничения на типы материалов это хорошо? Типы материалов давно вышли из такого понятие как только "текстовое содержание". Проблемы начинаются на этапе модификации, зачастую чтобы сделать какое-нибудь простенькое изменение, что придется многое переписывать. В друпале ничего не свалено в одну таблицу, наоборот все разделено.
Если нужно в материале выполнять скрипты, получать др. данные, и т.п. - есть все необходимое - это плагины, и этого абсолютно достаточно. С помощью плагина можно получить ЛЮБЫЕ данные с любого компонента, или таблицы БД. Написать необходимый плагин, при отсутствии нужного, не такая большая проблема.
3-уровневая система компонент-модуль-плагин решает ВСЕ возможные задачи.
Под каждую проблему по выводу информации писать доп. плагин? Откройте для себя Views.
кстати, от друпала отказались, т.к.
- сложен в изучении
- высокая нагрузка на БД
- безграмотная структура
- отсутствие ООП
- невменяемый кэш
- несовместимость модулей
- трудоёмкая кастомизация
Перешел на друпал по следующим причинам (не все):
Для не специалиста, коим являюсь я, Joomla вполне себе вариант. Дополнительных тяжёлых расширений не ставил, почти всё из стандартной сборки. Оптимизировал (из-за незнания) довольно долго, но теперь всё работает быстро и без отказов. К управлению уже привык и проблем не вижу.
В поддержку Drupal скажу следующее: Я только осваиваюсь в нём, и как раз логичность вызывает восторг. Т.е. с эстетическо-технарского взгляда, с этой CMF просто приятно работать. Причём, логику можно повернуть по-своему, в понятное тебе русло. Особенно мне нравится эта штука:
Зачем такие извращения? Зачем тогда вообще джумла нужна?
В версии 1.5 можно было сделать только так: ....
Под каждую проблему по выводу информации писать доп. плагин?
Вы дергаете цитаты как вам удобнее...
последняя версия 1.7 версия 1.5 в апреле перестанет поддерживаться.
И что сложного в написании плагина? при знании api 10 мин и 20 строчек кода? И в админку это выносить совсем лишнее, пользователю системы это не нужно.
Я не сторонник джумлы как универсальной системы, но мне нравится как и куда идет разработка. друпаловцы по религиозным причинам не поймут (Когда я слышу слово Joomla, я хватаюсь за пистолет), как впрочем и большинство джумловцев, в виду крайне низкой квалификации.
nikhotin добавил 25.11.2011 в 00:16
Под каждую проблему по выводу информации писать доп. плагин? Откройте для себя Views.
уже закрыл, плагином быстрее. Не нужно это в админке, только если сайт делается для себя, и вы его администрируете. а так только пользователя пугать...
Вы дергаете цитаты как вам удобнее...
последняя версия 1.7 версия 1.5 в апреле перестанет поддерживаться.
И что сложного в написании плагина? при знании api 10 мин и 20 строчек кода? И в админку это выносить совсем лишнее, пользователю системы это не нужно.
В плагине нет нечего сложного, но к сажелению для решения большинства интересных и сложных задач требуется писать компонент.
уже закрыл, плагином быстрее. Не нужно это в админке, только если сайт делается для себя, и вы его администрируете. а так только пользователя пугать...
У друпала нет админки в том понимании ка это принято в джумле
В версии 1.5 можно было сделать только так: выпадающий список с категориями, справа выпадающий список с подкатегориями. Все.
Невозможно сделать несколько категорий у которых будет свои выпадающие списки подкатегорий.
Насчет тегов точно не помню, то уверен что сделать несколько наборов (категорий) тегов нельзя (например теги про погоду, теги про город и т.д.).
Вообще-то компонент мультикатегорий есть. И это получше, чем теги. С неограниченным количеством категорий и подкатегорий, с возможностью отнесения материала к разным категориям. Материал при этом не дублируется, в смысле на один материал только одна ссылка.
У Joomla масса возможностей...
У друпала нет админки в том понимании ка это принято в джумле
Полностью согласен.
В друпале тема админки может быть любой, хоть специальной (аля админка джумлы), хоть прямо тема сайта будет выступать в качестве темы админки.