Лучшая CMS

Сахар для сервис-локатора. Но да, синглтон конечно. В принципе единственный.

Не проще. Оно аналогично будет редактироваться из админки.

Здесь не понял. У меня тоже секции. С привязкой к конкретному объекту. Т.н. LangSpace. Только в собственном решении есть возможность сделать наследование секций. Например файлик словарика модуля статей/новостей выглядит так:

    'model/article' => {
        '#parent' =>'model/defaultPage',
    },
    'model/news' => {
        '#parent' =>'model/defaultPage',
    },
    'model/pageCategory' => {
        '#parent' =>'model/defaultPage',
    },
    'view/article/sidebar/list' => {
        'title'=>'Новости',
        'all'=>'Все новости >>>>',
    },

Лишняя зависимость от конфигурации сервера.

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

Да, будет. Примерно по таким соображениям.

Точнее я сейчас очень существенную часть логики вынес в конфигурационные массивы, недавно был большой блок по выкуриванию из них логики (в плане кода который не данные). Скоро буду переводить их на json. Но пока есть несколько "некрасивых" мест в синтаксисе этих конфигов. Но в целом для подавляющего большинства прикладных задач будет достаточно только конфигов и шаблонов. Так что тут явно напрашивается избавление от пхп в прикладном слое. Шаблоны редактируем в ACE editor, под конфиги красивую админку можно забабахать... На прошлой итерации этого бесконечного цикла, я остановился на том, что шаблонизатор таки нужен, чтобы не было всяких XSS и прочих неожиданностей. Да и все мы знаем что больше половины сайтов на ВП имеют бекдоры именно потому что гуляет куча тем с закладками, и мало кто чистит код, удаляет ненужные темы и т.п. Не нужно давать пользователю возможность отстрелить себе ногу.

Но когда я начал писать этот движок, то у меня было четкое понимание, что ActiveForm и прочих виджетов можно утонуть под горой кода вьювов, и оно того не стоит.

Плюс проект начинался с принципов "ни одной строчки старого кода, как чужого так и своего".

Необходимость шаблонизатора усугубляется еще и тем, что у меня понятия вьюва и шаблона разделены. Есть стандартный класс вьюва, есть возможность для разных вьювов указать свой специфический. Т.е. специфичный код ДОЛЖЕН жить отдельно, во вьюве, а в шаблоне относительно небольшой набор возможных операций. Но доберусь я до этого не скоро. Готовые шаблонизаторы немного тяжеловаты, а свой - долго. Может форкнуть твиг, и выкинуть лишнее?) В общем это в долгом ящике.

Ну да, со стандартами каша. Каюсь :)

Оно начиналось на половину в шутку. Тестовое задание на собес, примеры для обсуждений/обучения юниоров. Потом вдруг понял, что в этой шутке слишком много правды. У меня даже неймспейсов нет, композера нет, пхпдоксы почти не заполнены, тестами даже не пахнет.

---------- Добавлено 30.11.2016 в 00:08 ----------

Речь вообще не про изучение.

Если я правильно понимаю, то список составлялся через get_defined_functions?)

Разжую. Не просто функций. А функций уже загруженных. В ПХП нет автоподгрузки функций, как для классов. Вы можете никогда не использовать 1500 из этих 1900. И ваши плагины, и темы могут их всех никогда не использовать. Но при КАЖДОЙ странице этот код будет выполнен.

Да какие уж тут напряги :) просто хотел поделится своими наблюдениями. Речь не о наборе функций и не о функционале в целом, а о том, что непонятно зачем подгружается такие объемы кода для отображения всего навсего одной рубрики и одной статьи.

---------- Добавлено 30.11.2016 в 01:18 ----------

Да, именно get_defined_functions. Я понимаю что большая часть может не использоваться, но они загружены и у каждой функции не по 2 строки кода, а это лишняя нагрузка на интерпретатор.

А началось все с темы лучший цмс. холивар удался 🤪

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

Если делать правильно, то останется главное - контент.

А "переделывать" к ВП относится ровно также как и др движку. Может даже в меньшей мере.

Но другой вопрос, что эксперименты с темами и плагами оставляют в базе следы.. Не всегда не заметные.

Загляни в адмику ВП и обрати внимание на правый сайдбар на подобной странице ;).

Ну кому-то "естественно" с помоек питаться. А потом рассказывать что выпускают отравленную колбасу.

Бесплатно чистое для ВП - только в репо. И не старое.

Кто может написать и/или реализовать ТЗ др. способами - может не платить.

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

Это плохо?

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

Ну как по мне наиболее конструктивный топик из подобных. Без перекидок гуаном (ттт)

Жаль только, что большинство вопросов о ВП, а о других движках не особо.

Жаль только, что большинство вопросов о ВП, а о других движках не особо.

Я бы даже сказал, что это ода ВП, прям даже всерьёз стал подумывать о переезде со своей любимой жу. А мне в ней комфортно. Я не программер, но ради экономиии своей фирме приходится многое делать по движку и функционалу. Обходимся бех техподдержки.

Не помню что там, но если намек на сходство, то я стараюсь сделать высокофункциональную вещь с таким же удобством "для мужиков" как у ВП, так что сходство предсказуемо :)

Нагрузка на диск, компиляция в опкод, место в ОЗУ. Это не так много, но больше чем с автозагрузкой классов. Да и изначально то это был ответ на "гулпые ООП-программисты делают кучу классов с кучей наследования".

Сейчас глянул у себя:

160 классов встроенных в пхп, 80 классов моих. Странно что так много.

У меня 137 классов в этом проекте. И 80 из них подгружается? Капец)

Почему выполнен-то? Они регистрируются на этапе Syntax Analysis, но не выполняются. Да, появляются зарегистрированные функции, но процессорного времени они не жрут особо. Да, мертвый код плохо, но мы говорим о CMS, а это всегда какое-то универсальное решение, а значит и функционал будет размазанный (кто-то будет все функции использовать, а кто-то 20% от всего списка). Именно поэтому крупные сайты пишут под себя с нуля или на микрофреймворках, чтобы не платить денежку за ресурсы, которые при Highload обходятся дорого.

Да, подключение класса обычно происходит autoload'ером, а значит то, что не используется, подключено не будет. В добавок ко всему, глобальное состояние - плохо, ну к примеру, если мы сделаем в нашем bootstrap файле что-то вроде

$app = new App();
$app->run();

То переменная $app попадает в global state. В случае, если кто-то во вьюхе (которое без template engine) напишет $app = "something"; то получится непредсказуемое поведение, и хоть function overloading в PHP запрещено (это я о глобальных функциях WP), то получаем нестабильное поведение. Любой может изменить глобальную переменную, от которой зависит работа вашего приложения.

Я сейчас пишу один проект на Go, так вот, там сам проект не компилируется при наличии функций или даже переменных, которые не используются, т.е. по факту dead code и unreachable code там не прокатят. А, к слову, PHP проекты просто усыпаны таким кодом. Там ещё куча фишек есть, как и минусов, которые мне, как программисту на PHP, не удобны, но я начинаю понимать, почему они так сделали.

Например, там нету Exception, зато есть multiple return (и кортежи), таким образом можно:

менять переменные местами

var a int = 1
var b int = 2

a, b = b, a

и разработчика, можно сказать, заставляют проверять все на ошибки, например

file, err := os.Open("file.go") // функция os.Open вернет два значения, "файл" и ошибку, если она есть, или nil, если её нет, т.е. по факту мы не можем просто взять, и не принять err (на самом деле можем, но только умышленно через переменную _, вот так file, _ := os.Open("file.go")
if err != nil {
	log.Fatal(err) // тут мы пишем в лог и завершаем выполнение программы, если критически важный для нас файл не открылся по какой либо из причин (err содержит причину). 
}

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

Когда я только учился только писать на PHP, я часто писал mysql_connect($args... Args); и продолжал работать, даже не проверив что там вернулось, и тогда я ещё задумывался, был бы какой-то механизм, который заставлял бы меня все проверять, чтобы я не забывал и код стабильно работал. Потом я начал писать or die("Cannot connect to database");. Дело было давно, сейчас в PHP 7.1 нужно только один блок Catch на то, чтобы выловить все Exceptions.

Который раз убеждаюсь, что строгость = благо (не всегда сейчас и сразу, но всегда в будущем, в перспективе).

Wordpress, кстати, полностью нарушает SOLID, конечно, благодаря этому он такой гибкий, и такой... шаткий, уязвимый.

Синглтон, не?

глобальные переменные зло.

Для сахара, чтобы короче было, обычно делают или статикой типа Yii::$app->имяСервиса, или как я - в функцию оборачивают т.е. s()->имяСервиса

Еще адресное пространство засерают, функциям в ВП никто неймспейсов не дает.

Но то такое. На самом деле это было возражение на слова "куча связанных классов". На что ответили мол "вы на свои функции смотрели? А они то загружены всегда, а не автозагрузчиком". Так то я удивился что у меня 80 классов грузится, даже список из любопытства глянул, ну и забыл. Глупости это. Даже без кеширования глупости. А с кешированием автозагрузчик еще меньше грузанет. Но я бы изначально такой аргумент не стал бы приводить потому-что ерунда. Имеет смысл только в ключе "на себя посмотрите".

Покрытие тестами решает. У меня оно правда ноль :)

А так то я не понимаю как можно найти мертвый код у интерпретатора с автоподгрузкой и т.п. Построитель запросов для древней СУБД это мертвый код?

И чем он с точки зрения кода будет отличаться от такого же, но под sqlite?

Просто проект маленький.

Возьмем к примеру проект с использованием Doctrine: 2 Base класса на таблицу + 1 Base/Generated класс на модель таблицы. Далее +2 класса на методы работы с таблицей как с моделью, а потом еще +1 класс снова на описание типа модели как объекта.

И это все не руками делается, это все Doctrine генерирует из schema.yml файла, в котором описана таблица.

И вот ты такой грузишь проект в IDE, открываешь нужную функцию, а там:

    public static function getTntByBarcode($barcode) {
        try {
            $package = Doctrine::getTable('Logistics_Models_Barcode')->getPackageBarcodeByIdentifier($barcode);
            return self::getTrackingByPackageId($package->package_id);
        } catch (Exception $e) {
            throw new Exception("Barcode {$barcode} not found");
        }

    }

Теперь вопрос, где искать метод getPackageBarcodeByIdentifier ? Из за не явного вызова модели, IDE просто не может найти где в ней этот метод. Т.е. вручную конечно, открыл файлы и нашел. Но когда ты находишься на стадии знакомства с проектом - время на такой дебаг уходит куча.

Это проблема IDE (или Doctrine) но никак не ООП и абстракций.. нужно использовать type hinting PHPDoc для того, чтобы IDE подхватывал... более того, проблема есть даже если

<?php



class waRedisCacheAdapter extends waCacheAdapter

{

    /**

     * @var Redis

     */

    protected static $redis;



    protected function init()

    {

        if (!self::$redis) {

            self::$redis = new Redis;

            self::$redis->pconnect('127.0.0.1', 6379);

        }

    }



    /* ... Methods ... */



    public function delete($key)

    {

        return self::$redis->delete($key); // тут IDE без декларации PHPDoc в начале класса запутается, т.к. она не знает что лежит в self::$redis

    }

}

Фиксится таким образом для методов возвращающих экземпляры классов

/**

@return YourClassName

*/

Или в начале класса

/**

* Users collection

* @var \Doctrine\ORM\ArrayCollection

*/

protected $users;

или вариант для PHP7+

public function getSomeClass(string $table) : TableModel 

{

// ...

}