Если интересно, то после года работы с их API был написан небольшой фреймворк на Python для работы с их XML API с использованием pem файлов ключей. Так же есть PHP frontend написанный на Kohana для обработки полученных данных через Python фреймворк (инкассации, кол-во, даты, поиск потерянных инкассаций и т.д.), работало на сети Qiwi терминалов в размере 1000 штук.
Для поломки достаточно убрать шаблон для страницы сайта, стараюсь по возможности устранить все места, откуда можно сломать демо сайт:
Запрет на смену пароля
Запрет на выполнение PHP кода в частях страниц
Запрет на создание и редактирование шаблонов и сниппетов
Запрет на загрузку файлов через «Файловый менеджер»
В системе слишком большая свобода действий под администратором, но в тоже время и все функции как на ладони, для обычных пользователей можно ограничить набор функционала и таких проблем не будет.
UPD. Сайт починить легко, главное что бы сервер не подвел.
Почему нельзя вместо Meta::getInstance()->add(...) объявить метод add ститеческим и вызывать просто Meta::add(....) и так же Meta::init(), вместо Meta::getInstance()->init()? Зачем надо создавать объект класса, если то, что он делает не требует наличие этого объекта?
Еще раз повторюсь, срочно прочитай хотя бы книгу, которую я указал по ссылке, новичку в ООП она поможет открыть глаза на многие вещи. Ты забудешь про этот синглтон, ну или хотя бы поймешь в каком случае его необходимо использовать, ну и тоже самое с фабрикой, ты поймешь в чем их отличие. Прочитай что такое статический метод и статический параметр. Все это настолько просто для понимания, что через пару тройку месяцев при взгляде на свой старый код ты будешь смеяться, в прочем как и все над своим старым кодом.
Судя по твоему коду, ты понятия не имеешь, что бывают помимо getInstance, другие статические методы и боюсь как бы для тебя и сам Singleton не казался магией (т.к. он присутсвует в каждом классе), и у тебя в коде нет ни одного Абстрактного класса, от которых, как минимум, можно было бы наследовать все компоненты, хуки и что там еще есть в системе и который помог бы разработчику узнать об обязательных методах, которые должны реализовывать компоненты.
Бегло взглянув на код классов в папке engine, я ужаснулся тому, что все классы наследуют singleton (Хорошо еще сам класс не наследует), независимо от того нужен он там или нет. Поверю, что он нужен везде, если обоснуешь его необходимость хотя бы в этом классе и почему его методы просто ни сделать статическими, как и сам параметр $metadata.
Ну и вопрос на засыпку, как использовать один и тот же модуль несколько раз на странице с разными настройками (Например в одном блоке вывести 10 новостей, в другом 5)?
Очень рекомендую пройтись по каждой ссылке на этой странице: php.net/manual/ru/language.oop5.php и ты узнаешь для себя много нового, и предвещаю через некоторое время появление магических методов, например, замена методов init на __construct
Советую также изучить литературу по теме, например, книгу PHP. Объекты, шаблоны и методики программирования, в которой представлены разные паттерны, после которой предвещаю глубокий рефакторинг кода и выход версии 6.х.х и появление MVC или HMVC ну или того, что сейчас модно.
P.S. Понимание и использование различных паттернов это очень круто, именно это доставляет удовольствие от программирования. Удачи в разработке.
Неужели синглтон настолько важен для каждого класса, что чуть ли не все классы от него наследуются? Хотелось бы, что бы хоть разок и дргие паттерны звучали.
Во первых так исторически сложилось, ведь этот модуль делался по аналогии с FrogCMS и FlexoCMS, во вторых ветки в дереве страниц можно сворачивать (а в свернутом виде они не загружаются из бд), поэтому в любом случае для сортировки придется производить дополнительные манипуляции, ну и так меньше вероятности, что это не сделает кто-то случайно.
Этот же факт сильно останавливает от ее использования, ведь в какой-то момент у вас могут смениться приоритеты.
Есть несколько причин разработки CMS, одна из них это заработок денег, т.е. я выполняю заказы по разработке сайтом и для этого использую свою CMS и трачу на разработку одного сайта менее 3-х дней, вторая причина, мне нравится программировать.
Ну и надеюсь в будущем найдутся люди, которые присоединятся к разработке системы, что снизит вероятность того, что система будет заброшена.
В CMS — RedactorJS интегрирован в качестве плагина, также для системы был разработан плагин CKEditor, плюс системы в том, что редакторы не встроены в систему, за исключением редактора ACE.
unittest мерджится с dev веткой постоянно, хотя если есть предложения по организации работы с тестами, готов выслушать, для меня показалось логичным включить их в отделльную ветку и в ней проводить написание тестов и т.д.
Ну собственно в Kohana есть интерфейс Cache_Tagging и из коробки есть поддержка тегов — для MemcacheTag, sqlite, я добавил только поддержу тегов для File (хотя я думаю вообще исключить этот тип кеширования), для APC и MongoDB
Проблема в том, что в версии Kohana 3.3 появились зачатки PSR-0, а именно All class file names and directory names must match the case of the class as per PSR-0., а в связи с тем, что уже был пройден длинный путь разработки на более старых версиях (начальная версия была 3.1 насколько я помню), то привести все названия файлов и классов было уже трудоемкой задачей, которая требовала бы тестирования со стороны пользователей, но аудитория пока что очень маленькая и соответственно самому выловить все баги будет очень тяжело, хотя начало было положено github.com/butschster/kodicms/tree/PSR-0_support благодаря помощи канадского программиста.
В системе слишком большая свобода действий под администратором, но в тоже время и все функции как на ладони, для обычных пользователей можно ограничить набор функционала и таких проблем не будет.
UPD. Сайт починить легко, главное что бы сервер не подвел.
Раздел
Настройки раздела и набор полей
Виджет вывода списка документов раздела — аналог компонента news.list в битриксе
Виджет вывода документа раздела — аналог компонента news.detail в битриксе
Спасибо :)
Прошу www.kodicms.ru, есть демо сайт
Почему нельзя вместо Meta::getInstance()->add(...) объявить метод add ститеческим и вызывать просто Meta::add(....) и так же Meta::init(), вместо Meta::getInstance()->init()? Зачем надо создавать объект класса, если то, что он делает не требует наличие этого объекта?
Еще раз повторюсь, срочно прочитай хотя бы книгу, которую я указал по ссылке, новичку в ООП она поможет открыть глаза на многие вещи. Ты забудешь про этот синглтон, ну или хотя бы поймешь в каком случае его необходимо использовать, ну и тоже самое с фабрикой, ты поймешь в чем их отличие. Прочитай что такое статический метод и статический параметр. Все это настолько просто для понимания, что через пару тройку месяцев при взгляде на свой старый код ты будешь смеяться, в прочем как и все над своим старым кодом.
Судя по твоему коду, ты понятия не имеешь, что бывают помимо getInstance, другие статические методы и боюсь как бы для тебя и сам Singleton не казался магией (т.к. он присутсвует в каждом классе), и у тебя в коде нет ни одного Абстрактного класса, от которых, как минимум, можно было бы наследовать все компоненты, хуки и что там еще есть в системе и который помог бы разработчику узнать об обязательных методах, которые должны реализовывать компоненты.
Бегло взглянув на код классов в папке engine, я ужаснулся тому, что все классы наследуют singleton (Хорошо еще сам класс не наследует), независимо от того нужен он там или нет. Поверю, что он нужен везде, если обоснуешь его необходимость хотя бы в этом классе и почему его методы просто ни сделать статическими, как и сам параметр $metadata.
Ну и вопрос на засыпку, как использовать один и тот же модуль несколько раз на странице с разными настройками (Например в одном блоке вывести 10 новостей, в другом 5)?
Очень рекомендую пройтись по каждой ссылке на этой странице: php.net/manual/ru/language.oop5.php и ты узнаешь для себя много нового, и предвещаю через некоторое время появление магических методов, например, замена методов init на __construct
Советую также изучить литературу по теме, например, книгу PHP. Объекты, шаблоны и методики программирования, в которой представлены разные паттерны, после которой предвещаю глубокий рефакторинг кода и выход версии 6.х.х и появление MVC или HMVC ну или того, что сейчас модно.
P.S. Понимание и использование различных паттернов это очень круто, именно это доставляет удовольствие от программирования. Удачи в разработке.
Есть несколько причин разработки CMS, одна из них это заработок денег, т.е. я выполняю заказы по разработке сайтом и для этого использую свою CMS и трачу на разработку одного сайта менее 3-х дней, вторая причина, мне нравится программировать.
Ну и надеюсь в будущем найдутся люди, которые присоединятся к разработке системы, что снизит вероятность того, что система будет заброшена.
RedactorJS до определенного момента был бесплатным, и лицензирование началось с 9-й версии, если я не ошибаюсь.
https://github.com/html5cat/redactor-js вот, он конечно не такой крутой, как платные версии, мне пришлось его дорабатывать.
Они были убраны из ветки master и dev и оставлены в ветке unittest, которую я создал специально для тестов
All class file names and directory names must match the case of the class as per PSR-0., а в связи с тем, что уже был пройден длинный путь разработки на более старых версиях (начальная версия была 3.1 насколько я помню), то привести все названия файлов и классов было уже трудоемкой задачей, которая требовала бы тестирования со стороны пользователей, но аудитория пока что очень маленькая и соответственно самому выловить все баги будет очень тяжело, хотя начало было положено github.com/butschster/kodicms/tree/PSR-0_support благодаря помощи канадского программиста.