Разное

Просмотрел несколько движков с целью выбора того, который будет использоваться в будущем как основной.

Движок DLE первоначально даже не привлек моего внимания, поскольку позиционируется как новостной. Но когда прочитал о его возможностях, то пришел в восторг! Какая же замечательная вещь! Для интернет-магазина не подходит, но для всего остального подойдет изумительно! Остается только удивляться тому, что на его фоне сохранили право на жизнь какие-то другие модификации.

Или я не прав? Может, у DLE есть какие-то проблемы?

(Про платность речи нет).

И какие же вы видите плюсы, отличающие DLE от остальных движков?
Конкретика рулит, воду и бессмысленные эмоции в топку.

Если взять DLE за 100%, то остальные будут ниже: danneo, textpattern, drupal, a-cms, amiro, umi-cms, webdirector...

В том смысле, что если поставить DLE, то не случится ситуации, когда потребуется что-то другое вследствии того, что DLE не справляется.

Разве не так?

Ничего не понял, совершенно.

Вы можете сделать так:
Плюсы ДЛЕ:
1. Скорость. Выражается в том, что...
2. Хорошая документация по API (ссылка на это апи)

и т.д.?

К столь серьезной аналитике я не готов. Да и задача у меня другая: узнать у гуру, обладающих личным опытом работы с DLE, те невидимые неопытному глазу дефекты, которые, может быть, есть у этой системы.

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

Вот этот термин "новостной движок" меня как-то тревожит. Что такого особенного есть в универсальной CMS, чего нет в новостной ДЛЕ?

Новости, насколько я понял, есть почти в любой CMS.

Лучшая поддержка модулей/плагинов мб?
Одно дело, когда новости - один из модулей, а другое дело, когда на нем все завязано.
Не могу сказать, стараюсь не работать с движками.

"Одно дело, когда новости - один из модулей, а другое дело, когда на нем все завязано."

И в чем разница?

В архитектуре, очевидно.
Если для вас "отдельный модуль" и "ядро, на котором все завязано" - одно и то же, то закончим на этом.

Я вообще-то искал гуру.

modx (evolution) смотрели?

Я про такую и не слышал... Надо посмотреть!

Про drupal то слышали? Седьмую версию хвалят.

Нет ничего лучше (и одновременно хуже, парадокс) самописа. Лучше - это потому, что можно любую функцию дописать, без копания в ядре. Хуже - потому, что практически каждую функцию нужно дописывать самому.

Да еще и дизайны прикручивать. Следовательно работа вебмастера (программиста) превращается в работу... программиста. Шутка.

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

Вообще-то, ДЛЕ удобный движок. Для конечного пользователя. Говорю это не потому, что сам его так люблю. Просто у моей знакомой есть сайт, сделанный как раз на ДЛЕ.

Если же Вам требуется идеальное удобство - пишите свой движок. Сделаете то, что Вам понравится.

Спасибо!

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

А самопис может быть очень удачным, но беда в том, что если увольняется автор, то надо сносить все под чистую и делать заново, ибо копаться в чужом никто не хочет. К тому же, у приемника повляется отмазка типа предшественник сделал плохо и как следует отладить этот код невозможно.

Для того, чтобы не случилось описанного, необходимо документировать код (или соответственно требовать этого от программиста). Т.е. не только оставлять комментарии, дескать "тута хуита, не трожьте, пока работает", а именно документировать.

Ну для пользовательского интерфейса возможно еще можно добиться документации, но для процесса разработки получить адекватную документацию вряд ли возможно. Это по сути книгу писать нужно. Это возможно, но дорого и не только в плане денег, но и времени.

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

Имелось ввиду первое, да.
Хотя бы описание работы функций/классов - уже неплохо, правда?
А остальное (т.е. как там внутри все работает) - можно понять (хотя, да, не всегда) из рабочих, готовых скриптов.

Я когда-то был инженером, работал на ВПК. Вот там была документация как надо: технические условия, технический паспорт, патентный формуляр, программа и методика испытаний...

Потом я от техники отошел, а когда через много лет вновь соприкоснулся на уровне программирования, то был просто в ужасе: термин "Интуитивно понятно" заменил абсолютно всё!

Скачаешь из сети или купишь где-то самописную программку, а там если и есть описание, но зачастую сводится к перечислению изменений: когда и в каком году одну закорючку заменили на другую. И больше ничего! Иной раз просто закричать хочется: твоя программа что делает? Она вообще для чего предназначена, блин!? А как ее установить-то? Нет ответа… И почта автора молчит. Либо ответ типа «Учи матчасть».

Или описание, составленное из балабольства про пиво и девочек, где как бы вскользь что-то говорят и о программе. Все заканчивается фразой «И будет тебе счастье», после прочтения которой все это творчество летит в корзину.

Так что заставить серийных программистов-самоучек делать нормальное описание практически невозможно. Большинство из них сделать это просто физически не могут. Да что там, описание, там ТЗ бывает такое, что в обморок упасть можно…

Не все, конечно. Но на фрилансе так.

Деньги не те... создание документации для ракеты сразу в бюджет заложено, штат под это выделен, человеко-часы. А для программ, особенно созданных на коленке - это непозволительная роскошь, так как создание документации обходится чуть ли не дороже самой программы. Автору это не нужно, особенно если программа бесплатная. Пользователи - не организованы (адекватная документация для PHP и MySQL появилась очень поздно). Еще один немаловажный аспект - срок жизни программ много меньше, чем изделия - документация устаревает очень и очень быстро (т.е. на её сопровождение уходит больше времени и денег). Вы абсолютно правы, создание документации - это отдельная работа, для которой нужен технический писатель, а то и команда таковых - для фриланса или небольшой утилиты - это непозволительная роскошь.

PS Мы пару раз создавали документацию для разработчиков (правда у нас опыт написания книг есть), но удовольствие слабое, так как кому попало это не доверишь и приходилось писать лично мне (а мне и без этого есть что писать :). В общем когда имеется возможность сами стараемся избегать создания персональной документации для разработчиков (лучше снабдить клиента нашими книгами, где процесс разработки достаточно подробно описан).

>Я хочу выбрать движок и сделать его основным в своей фирме.
Не очень удачный выбор. Мне приходилось иметь дело с этим движком, поэтому Ваших восторгов я совершенно не разделяю. Весь код там переплетен как макароны - внося правку в одну часть, нет никакой уверенности что что-то не отвалится в другой. Код действительно простой, но на этом его достоинства и заканчиваются - там жуткая каша из php, html и JS. API для создания подключаемых модулей, как таковой, появился только в последней версии. Причем, появился в совершенно зачаточном состоянии - только для галочки, проблем он никаких не решает.
Отдаю должное ее разработчикам - они создали систему, которая симпатично выглядит и обладает солидным набором функций "из коробки". Но этим набором функций все и заканчивается - как основа для собственной разработки она никуда не годится.

Спасибо за Ваше мнение!

Тут был упомянут modx. На первый взгляд, весьма достойная вещь. Вам не доводилось с ним иметь дело?

upd. для проектов крупных, где нужны авторизация. личный кабинет больше подходит новая modx revolution

Вы имеете в виду релиз MODx Revolution 2.0.0 RC-2 http://modx.ru/blog/modx-revolution-rc2 ?
Мне показалось, что русскоязычная документация там не очень подробна. Кроме шаблона, по которому есть исчерпывающая информация.

и по Evolution не подробная. API описано не полностью. можно с Evolution разобраться за 2недели и с этими знаниями начинать работать с Revolution

У меня такого, как у вас восторга нет :)
Я начала работать с этим движком, после остановилась,потому как непонятно было, буду я делать проект или нет. Поэтому в основном смотрела ради интереса. Попробовала натянуть свой дизайн - особых трудностей не возникло, перепробовала все пользовательское, после полезла в код. Давайте сначала про плюсы, после - минусы.
Плюсы.
Для разработчика движок прост в освоении. Модули поключать легко, там идет что-то типа:
switch(гет-параметр, передающий текущий модуль)
case "register" :
include register.php';
break;
Добавляете новую строку case для модуля - и готово. Шаблон уже подключается внутри файла модуля. Там нет таких наворотов, как, например, в Битриксе или Друпале, что модуль - это что-то глобальное типа целой папки файлов, где в одной папке и css, и шаблоны, и обработчики и много чего еще нужного... Здесь все просто - 1 файл== 1 модуль + шаблон насколько я помню, кладется в папку темы, туда же вроде как и стили, и js - все в куче, и все, ваши проблемы на этом закончились.
Документации для разработчиков нет. Да там в принципе она и не нужна, движок маленький, структура сразу видна.

Что мне не понравилось.
Вроде как все валится в кучу в папку темы, если на сайте много модулей - в теме будет большой беспорядок.
Пробовала сделать сайт на utf. По умолчанию здесь - cp1251, через админку переключиться не получилось - что бы ни делала, пишет cp1251, чтобы переключить на utf, пришлось залазить... в файл, где хранятся языковые константы и руками исправлять кодировку. И зачем они сделали языковую константу, обозначающую кодировку, для меня вообще непонятно. Да хоть на немецком, хоть на турецком utf так и будет utf.
Поставила базу на utf - некоторые модули перестали отображать контент., т.е. он отображается, только в виде кракозябров. Проверила все, что только можно(и кодировку базы, и соединения, и т.д.) - все равно криво. Переконвертировала все файлы движка в utf(у меня тут тема где-то такая была), контент модулей появился как надо, перестала работать регистрация. Я в ней тогда не стала копаться, придется сейчас разбираться.
Т.е. мой вывод - под utf движок приспособлен слабо, если приходится все делать руками.
Я уже после нового года возобновлю работу, планирую подключить phpbb,после допишу, если будет что нового из негатива. Я обычно про движки когда читаю, опираюсь в основном на негативный опыт и проверяю его сама. Позитива всегда много и позитив чаще всего дают в целях рекламы.

"По умолчанию здесь - cp1251"

А как она с Аяксом работает на 1251?

а разве аякс работает только с utf? 8-[

В Internet Explorer 6 могут быть проблемы.

Даже если сервер отвечает с заголовком, например, header("Content-type: text/xml; charset=windows-1251") ?

Я сейчас не уверен (давно не проверял), но помоему нет...

хм...но мне кажется ie6 уже совсем не актуально

Для разработчика движок прост в освоении. Модули поключать легко, там идет что-то типа:  switch(гет-параметр, передающий текущий модуль) case "register" : include register.php'; break;

Сначала также у себя делал. Потом мозгом подумал и переделал:

<?php // $GET[0] - модуль; с индексом >= 1 - параметры для конкретного модуля // route - это продукт работы mod_rewrite $GET = isset($_GET['route']) ? explode('/', $_GET['route']) : array('main'); $isset_modules = array (                 // Главная страница                 'main',                                  // Поиск                 'search'); // Благодаря массиву доступных модулей, всякие бяки исключены if (in_array($GET[0], $isset_modules))     include ma($GET[0]); else     include ma('pages');

Соответственно все, что не подходит под алиасы модулей рассматривается как алиас страницы.

По поводу phpbb - вы уже думали, каким образом будете подключать, или это просто как факт надо, но не углублялись?

Так, конечно, лучше, в $_GET даже если попадет что-то левое, вреда от него не будет.
В сторону phpbb еще пока не думала, требуется сделать общую авторизацию для сайта и форума, пока что скачала сам форум, но в нем еще не копалась.

Занимался его подключением.
Но т.к. форум планировался с самого начала, то я решил не плодить записей в бд и база пользователей у меня на форуме, а сайт (самопис) уже на это наращивался.
Если будет интересно - могу кое-что скинуть. Там и авторизация чтобы работала на сайте и т.д. Но это самопис, т.е. интегрировать по сути ничего не надо было. Так что для вас будет лишь полезным узнать какие файлы участвуют в регистрации/авторизации, сессиях.

>Если будет интересно - могу кое-что скинуть.

Ок, не откажусь :) на тот же e-mail. Посмотрю, как вы связывали.

Я по форуму немного покопалась, файлы нужные вроде как нашла.
Пока что идея такая. Опираться буду на форум, потому как у меня форум тоже на сайте основной. Т.е. пользователи будут писаться в базу форума.
В регистрации на сайте я просто сделала редирект на соответствующую страницу форума.
В форме авторизации на сайте имена полей теперь == имена полей авторизации на форуме.
В action формы поставила phpBB3/ucp.php?mode=login. После авторизации там идет редирект, так вот после редиректа сессия теряется.
Я так поняла, в phpBB id пользователя в сессию не пишется? Как тогда там проверяется, авторизован пользователь или нет?

Отправил.

Еще добавлю - возможно, придется покапаться в настройках форума, особенно домен кукисов и т.д.
Если будет несколько доменов - убирайте сразу конкретный, потому что мне потом пришлось костыли лепить, чтобы исправить кукисы.