Pull to refresh

Comments 73

Новый движок это конечно хорошо и похвально, но вынесли бы вы хтмл код из пхп, и внесли бы хоть немного другу организацию кода — а то по сути весь ваш двитжок это большое количество функций. Сам не люблю употреблять слово ооп, но тут оно пригодилось бы., особенно при взгляде на бесконечное число употребления global.
Да, я знаю, глобальный рефакторинг будет совсем не лишним при дальнейшей активной разработке. Просто сейчас непонятно, будет ли эта самая активная разработка.
Ну вы же понимаете, что буквально через пару месяцев активно разработки, вы точно уткнетесь в проблему поддержки существующего кода и растущего количества дублированого кода. Поэтому просто начните сразу писать правильно. Рефакторинг будет всегда, но в данном случае лучше хоть начать сравнительно правильно.
Прекрасно понимаю. Но если движок окажется никому не нужным, то глупо будет тратить на это ресурсы.
Да, но я веду к тому, что бы начинать изначально писать правильно. А не — сначала абы как, а потом если пойдет, то перепишу с нуля. Не перепишете. Никогда :)
Вы правы. С другой стороны, сейчас писать с нуля свой движок я бы вообще не стал :)
Слушайте, ну кто из php-программистов не писал свой php-движок? И зачастую бывает гораздо хуже
UFO just landed and posted this here
Ну, сравнили. Тру php-программисты начинают с делфи. :) Шучу. Хотя в моем случае это правда.
Ладно, но то, что большинство программистов имеют где-то в глубине иерархии директорий свой когда-то написанный движок, вы не спорите? :)
Перед входом в админку добавьте в userstyles:
* {background-color: #fff !important}
Зачем? В настройке админки можно менять цвет фона. Кто-то поставил ядовито-зеленый.
Это было адресовано всем хабраюзерам, т.к. можно менять цвет фона админки, и кто-то поставил ядовито-зеленый :)
Ладно цвет, кто-то вообще пароль от админки сменил.
Демо-сайт сбрасывается к первоначальному состоянию каждый час. Но сейчас, пока хабраэффект, я буду делать это чаще.
Надо бы сделать запрет на смену пароля для админа в демо-сайте. Представьте сколько сейчас людей ломятся в админку и сколько из них туда не попадут, если поменять пароль. Вы просто физически не сможете его сбрасывать так часто, чтобы хотя бы половина пришедших хабраюзеров увидела админку.
Более того, сейчас имеется возможность обрывать другие сессии этой учетной записи. Поэтому мне минут 10 понадобилось, чтобы увидеть как выглядит панель установки расширений. Постоянно кто-то сбрасывал сессию. Шутники блин.
Это называется хабраэффект.
Дело не в Опере. Просто много желающих попробовать разные функции под одним аккаунтом, в том числе и запретить ему доступ.
Там его вообще можно удалить, предварительно создав юзера с необходимыми правами. Это баг или фича? :)
Админы равноправны и могут удалить друг друга. Так что фича :)
Если честно я не понял за что минусуют.
Оставлять для тестового аккаунта возможность смены пароля — очень «здравая» идея.
Как оказалось, во время хабраэффекта действительно неудачно получается.
Но обычно всё нормально, достаточно того, что демо-сайт сбрасывается к начальному состоянию каждый час.
Ну приятно, даже зная, что в мире уже миллионы различных цмс, автор все таки написал свою, хорошее развитие для мозга, а квантование магнита, это как раз то, ради чего стоит жить.
ЧПУ — это, блин, станок с Чило Програмным Управлением, а то, про что Вы говорите, называется Frienly URL
Не надо плеваться, это устойчивая аббревиатура, и в данном случае она обозначает именно «человекопонятный урл».
Да заведите себе пользователя вместо admin. Никто не будет ни выбрасывать, и пароль менять. :)
И в течении часа можно спокойно смотреть сайт.
И снова: =)
list($usec, $sec) = explode(' ', microtime());
$s2_start = ((float)$usec + (float)$sec);

А по коду вообще, советую автору почитать, например: Мэтта Зандстра: PHP Объекты, шаблоны и методики программирования.
Да, движок работает на PHP 4.3.

Вы не поверите :)
Именно эту книгу я сейчас читаю.
Т.е. вы создали движок, который работает на сверх-устаревшей версии php и с ужасно хромой архитектурой? Простите, но вы опоздали на 10 лет. Тогда у вас мог быть бы шанс.
Создал-то я его не сегодня и не вчера.

Движок может работать на сверхустаревшей версии PHP. Но с тем же успехом работает и на современных версиях.
Т.е. вы предлагаете пользоваться заведомо устаревшим продуктом? Извините, но поддержка ПО 10-тилетней давности, когда запросто можно разрабатывать на самом современном ПО — это сложности в поддержке, сопровождении и т.д.
Вообще-то я нигде не предлагаю пользоваться устаревшим продуктом.

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

Я хочу, чтобы потенциальные пользователи и разработчики сами решили, будет ли у движка будущее.
давно как бы уже есть для microtime() параметр get_as_float (If used and set to TRUE, microtime() will return a float instead of a string...)
Давно — это начиная с PHP 5. Движок же поддерживает PHP 4.3 (поддержка 4.3 была с самого начала, и пока я не делал чего-либо, ради чего от нее нужно было бы отказаться).
это шутка ?, php5 вышел 2004 года, это уже почти 8 лет назад, Вы действительно верите в то что нужно поддерживать версию 4.3?
Сейчас, очевидно, нет. Но в 2007 году, когда я начал разрабатывать движок, PHP 4.3 еще был актуален. Например, на моем хостинге был установлен именно он.

С тех пор я не делал такого рефакторинга, который бы потребовал отказаться от поддержки PHP 4.3. Поэтому не было причин выкинуть строчку «list($usec, $sec) = explode(' ', microtime());».
Сразу признаюсь: мы тоже работаем над системой управления контентом. Хочется обменяться опытом, задать пока несколько вопросов.

Как у вас обстоят дела с простотой написания расширений для вашей системы?

Используете ли вы внутри фреймверк?

Какая система (-ы) были взяты за основу?

На какие сайты ориентирован движок?
Разработка расширений описана в документации. Чтобы разрабатывать расширения, нужно иметь общее представление об устройстве движка и заглядывать в его код.

Как такового фреймворка нет. Есть некоторый служебный код вроде упоминавшейся БД-абстракции, который может использоваться и в расширениях.

Про основу я написал. Сначала я писал движок с нуля, потом взял из форумного движка PunBB систему расширений и некоторые другие вещи.

В моем представлении движок ориентирован на небольшие и средние контент-сайты. Можете посмотреть примеры готовых сайтов.
Отвечу как автор своей собственной системы (к сабжу никакого отношения нет, просто надеюсь ответ будет интересен).
1. Как у вас обстоят дела с простотой написания расширений для вашей системы?
Переопределить можно всё. Всё модули, даже сама админка, даже класс ActiveRecord (ORM), даже модуль новостей, текстовых страниц и так далее. Всё на функциях/методах классов, запускаемх через прослойку, поэтому всё переопредеяется. Т.е. Новость — модель, вид, контроллер — это модуль. И так со всем, абсолютно. Так что хочешь-не хочешь, всё на модулях автоматически. Только в отличие от всяких джумл, модули гораздо проще в реализации, где то рядом с Ruby on Rails. К тому же есть скаффолдинг — открыл, написал news — создано всё, таблица, роутинг, шаблон, контроллер.
2. Свой. Сама система и есть фреймфорк, нечто среднее между рельсами и кодеигнитером. Код одного контроллера короче, чем в Yii, CakePHP, Codeigniter, но вот рельсовое
def index
   User.all
end

Никому побить не удастся =)
Благодаря единому стилю наименования таблиц, удалось практически автоматизированно вешать всё на админку. Т.е. админка продумана ещё при проектировании архитектуры.
3.Какая система (-ы) были взяты за основу?
Рельсы как идея DRY и чистоты. Своя предыдущая админка и опыт сотен сайтов на ней — как работа над ошибками и понимание, как программисту меньше париться.
4. На какие сайты ориентирован движок?
Первое — это визитки с каталогами, новостями и любыми списками, галереями и так далее. Такое строгается вообще без программирования.
Второе — сайты с формами — список пользователей, зарегистрировался, создал что то просмотрел. В народе часто называются RESFful приложениями. Т.е. есть механизм просто валидации форм, а также манипулирования данными. Т.е. соц сеть создавать будет неудобно, т.к. придётся писать всякие форумы, стены и т.д. Но вот блог создаётся за 30 минут без подготовки, сайт вроде хабры за пару дней (включая вообще всё).

Если интересно, можете прям тут задать вопрос (например, как запилить новости, как запилить каталог, галерею, форму обратной связи, регистрацию, список докладчиков) — с удовольствием сделаю скринкаст на 5-10 минут. Если, конечно, интересно.
Конечно выкладывайте скриншоты. Всегда интересно взглянуть на «чужой» опыт!
А вот скриншоты тут не помогут — мало что скажут. Особенно учитывая то, что админка — это тоже модуль и внешний вид легко меняется. Если честно, не понимаю, например, как будут выглядеть скриншоты Ruby on Rails.
А скринкаст может показать остальное — как модули создаются, на какие сайты ориентрирован.
У таблицы допустим news три поля, кроме id — title, text, image. Задаётся поле для редактирования каждого из полей — обычное текстовое поле, большой textarea и загрузчик картинок. Программист легко может добавлять свои экзотические типы полей (ввод даты, и так далее).
Ну и это всё, дальше можно делать обычные модель вид контроллер, причём модель можно не объявлять явно, и использовать данные из базы данных в два шага — контроллер обрабатывает POST и GET запросы, получает данные из модели (база данных), формирует переменные и массивы с данными, запускает другие контроллеры, запускает шаблон.
Итого в админке нет модуля новостей как такового, и таблицы news тоже. Есть только модуль текстовых страниц, и то как пример в дефолтовой сборке. То есть модуля новостей нет, и его каждый раз приходится писать заново. И так с каждым. Сейчас всё-таки покажу.
Вот, сегодня накидал
vimeo.com/33580244

Тут создание модуля новостей с нуля, в ключая создание таблицы, списка всех новстей, вывода трёх последних на главной, полынй краткий текст новости, автообрезаемые первью картинок для каждой новости, и возможность редактирования всего этого через админку.
Длина 10 минут.
Вам не приходила ещё мысль выложить код на GitHub вместо собственного репозитория Subversion?
Я пока не знаю, какие значительные преимущества может дать такой переезд.
багтрекер и сборщик идей в первую очередь.
форк-в-один-клик во вторую
Ещё гитхаб интегрирован во многие IDE (Phpstorm например)
Вон там мою реплику с ответом на этот вопрос прочтите. Специально даю гиперссылку, чтобы контекст явствовал.
Без фреймворка? Очень и очень зря. Развития не будет — никто кроме вас не будет писать код под новую систему.
Когда я начинал разработку, фреймворки не были так популярны, и я ни об одном не знал.
в коде каша, в вперемешку html + js + php, буферизация вывода, глобальные переменные, eval-ы, или делайте полный рефакторинг, или Ваш труд заглохнет
А что плохого в буферизации?
Ну, хватило смелости выложить — уже хорошо! :)
Код для 2011-го года ужасный, конечно. Желаю развиваться быстрее, выше, сильнее :)
Догадался что CMS на базе PHP только по комментариям…
Забавно, я ща работаю в компании, одним из брендов которой является S3, и под нужды этого направления делаю как раз движок с простой для конечного пользователя админкой. Правда использую для этого CodeIgniter последней версии.
Как будет релизная версия, буду очень сильно толкать идею в компании сделать исходники опенсорсными, а продвать на ней сайты под ключ + поддержку.
UFO just landed and posted this here
Я думаю, что человек не хочет, чтобы его труд зря пропадал, поэтому решил поделиться с сообществом.
нет-нет так
$replace[''] = isset($page['comments']) ? $page['comments'] : '';
дело не пойдёт.
$replace['<!-- s2_comments -->'] = isset($page['comments']) ? $page['comments'] : '';


А что здесь не так?
ИМХО всё круто. Только можно было бы проигнорить лишние проверки и сразу пускать. Нативный код (php-функции) написаны на Си, и конечные автомат сами разберутся, что на что менять довольно шустро.
Видимо, чтобы PHP4 не выдавал варнингов по поводу отсутсвия ключа.
В любом PHP будет notice, если элемент массива $page['comments'] не определен.
Про дефолтовый PHP4 не скажу, PHP5 дефолтовые обычно настроены чтобы варнинги, нотисы, депрекатеды не выводить. Хотя нотис будет в любом случае, это да.
Я бы на Вашем месте переписал фрагмент так:
$tpl = preg_replace('/<\!--\ss2_([a-Z0-9_]+)\s-->/', '<?php  if(isset($page['$1'])) { print $page[$1]} ?>',$tpl);

Если конечно шаблонизатор компилирующий и $page глобальная. Это может помочь при кешировании результатов работы шаблонизатора. В противном случае это бесполезно и решение, судя по всему, в данной ситуации лучше некуда (если только в начале файла инициировать все ключи массива пустыми строками для скорости).
Эх, надеялся увидеть красивый код, продуманный дизайн… В увидел спагетти код, который обнять и плакать…
Кто захочет влиться в проект под капотом у которого технологии 2004 года?

По сути что у вас есть:
— обкатанная схема БД, общая архитектура
— более или менее нормальный клиент-сайд админки (js, html)
— все это склеено морально-устаревшим php4

В такой проект никто не пойдет волонтером — кому нужно решение на php4? В последних релизах php уж больно много вкусного. Так что если не хочется забрасывать проект, то я бы отрефакторил систему с использованием плюшек php5 (там где это нужно конечно).

Серьезно бы задумался об использовании какого-нибудь фреймворка типа yii. Помимо традиционных плюсов от использования фреймворков есть и не очень очевидный, но столь важный для вас бонус — например, на том же yii нет cms доступных в паблике, люди пока не выкладывают свои проекты в опенсурс, ограничиваются отдельными компонентами. Есть пара проектов, но они совсем в зачаточном состоянии, ваша система даже в текущем виде делает их как лежачих. Так вот, вы можете получить поддержку целого сообщества и волонтеров в проект. Если начнете рефакторить под yii и будете это делать публично — такие волонтеры обязательно появятся, у вас просто не будет достойных конкурентов. В конце концов может получится полноценный опенсурс проект со своим сообществом.
Без ООП тяжело вести разработку большого проекта, особенно в команде!
К особенностям движка относится система расширений, позволяющая добавлять или изменять функциональность.
Мне кажется, или это не является такой уж и сильной особенностью?

Кстати, являюсь сам разработчиком на PHP и присоединяюсь к тому, кто предложил вынести HTML из PHP.
И ещё хочется отметить, что быстроты абсолютно никакой не обнаружил. В топике точно тот демонстрационный сайт?
Может и не такая сильная особенность, но это нужно было как-то упомянуть.

HTML-код публичных страниц сайта практически вынесен из PHP. У тех небольших фрагментов, которые генерит движок, логичная разметка, указаны классы, так что через их можно спокойно оформлять через CSS. HTML-код админки действительно содержится в PHP. Его нужно выносить в рамках рефакторинга админки.

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

Рефакторинг? Хм, я бы не стал писать о проекте на хабре, если он не допилен до вменяемого вида чуть менее, чем полностью.

Упомянуть стоило, но это в наше-то время совсем не особенность.
На такое допиливание нужно много времени, поэтому я решил остановиться чуть раньше. Выше в комментариях я упоминал о том, что цель топика — найти потенциальных пользователей и разработчиков. Если таковых не окажется, я буду тратить на движок существенно меньше свободного времени.
Sign up to leave a comment.

Articles