Первый взгляд на Pagekit CMS — чистый, расширяемый, быстрый, но …

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

Красивые URL

По умолчанию для URL-адресов Pagekit будут использоваться безобразные URL-адреса с index.php Чтобы получить красивые URL на Apache, модуль должен быть включен — обратитесь к документации по настройке вашего сервера для этого. В Nginx настройка по умолчанию из Homestead Improved будет поддерживать красивые URL-адреса (то есть они будут работать ), но Pagekit не будет включать их по умолчанию, поскольку не может определить, включены ли они. Чтобы обмануть это, мы можем добавить пользовательское значение в конфигурацию сервера:

 fastcgi_param HTTP_MOD_REWRITE On;

Как только мы перезапустим сервер с помощью sudo service nginx restart Пример полной конфигурации сервера приведен ниже:

 server {
    listen 80;
    listen 443 ssl;
    server_name pagekit.app;
    root "/home/vagrant/Code/pagekit";

    index index.html index.htm index.php;

    charset utf-8;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location = /favicon.ico { access_log off; log_not_found off; }
    location = /robots.txt  { access_log off; log_not_found off; }

    access_log off;
    error_log  /var/log/nginx/pagekit.app-error.log error;

    sendfile off;

    client_max_body_size 100m;

    location ~ \.php$ {
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass unix:/var/run/php/php7.0-fpm.sock;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param HTTP_MOD_REWRITE On;
        fastcgi_intercept_errors off;
        fastcgi_buffer_size 16k;
        fastcgi_buffers 4 16k;
        fastcgi_connect_timeout 300;
        fastcgi_send_timeout 300;
        fastcgi_read_timeout 300;
    }

    location ~ /\.ht {
        deny all;
    }
}

Безопасность

Любопытно, что Pagekit идет вразрез с лучшими практиками и помещает точку входа в приложение ( index.phppublic В Nginx (и в Apache, который не читает локальные файлы .htaccesspagekit.dbmypagekit.com/pagekit.db

Чтобы обойти это, нам нужно еще больше изменить скрипт сервера с помощью довольно примитивной строки кода, взятой почти дословно из их файла .htaccess Добавьте следующее чуть выше location ~ \.php$ {

 location ~ /(composer.lock|pagekit.db|installed.json|composer.json|package.json|bower.json|CHANGELOG.md|README.md|gulpfile.js|webpack.config.js|pagekit) 
{ 
        deny all; 
}

Это чрезвычайно примитивное и устаревшее решение, но оно работает. Можно только надеяться, что команда Pagekit вскоре отойдет от этой структуры папок.

Развертывание сайта Pagekit

Развертывание сайта Pagekit так же просто, как загрузка статического сайта, если для базы данных по умолчанию используется SQLite, а файл базы данных сохранен в той же папке. Полное руководство по этому вопросу можно найти здесь , используя как Laravel Forge, так и сырой подход DigitalOcean + Github, так что выбирайте!

Вывод

На первый взгляд, Pagekit кажется хорошей альтернативой другим CMS. Пользовательский интерфейс замечательный, их экосистема для разработчиков невероятно дружелюбная, а их система плагинов хорошо сконструирована и рассчитана на длительный срок. Он поставляется с некоторыми изящными стандартными функциями, такими как постдублирование, Markdown, VueJS в пользовательском интерфейсе, достаточные настройки по умолчанию как для сайта, так и для блога / комментариев, и все, чего не хватает в текущих настройках, можно легко добавить с помощью расширения.

Это не без его недостатков, все же.

Во-первых, тот факт, что его безопасность зависит от того, насколько хорошо кто-то настраивает сервер, означает, что он не такой кроссплатформенный, как должен быть без серьезных модификаций — и мы все знаем, что файлы конфигурации Nginx и Apache не являются наиболее интуитивно понятными для редактирования файлами. Кроме того, встроенный PHP-сервер не может использоваться для его правильного тестирования, что ограничивает фактор «игры» на определенных машинах и определенно наносит вред приложению с точки зрения готовности к производственному нативному PHP-серверу, должен ли он когда-либо развиваться. Команда Pagekit должна обязательно выполнить некоторые проверки безопасности на стороне PHP и отказаться от попыток даже использовать файлы .htaccess

Во-вторых, на данный момент нет возможности экспортировать данные из базы данных. Это делает нецелесообразным переносить приложение на MySQL после того, как пользователь сыт по горло SQLite, и ограничивает переносимость контента — представьте себе, что все настраивается и локально пишите сообщения в SQLite, а затем просто загружаете данные в живое приложение, использующее MySQL. вместо.

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

Рынок все еще довольно пуст, но я не сомневаюсь, что он быстро заполнится, как только шарик начнет катиться — и наши будущие уроки обязательно помогут с этим — но действительно ли это «убийца WordPress»? Не только пока. У него, безусловно, больше возможностей, чем у таких претендентов, как Ghost, но ему нужно работать над совершенствованием MVP, а не удалять M из MVP, чтобы угодить толпе. Нам нужна CMS с меньшим количеством функций, которые мы можем легко расширить, но которая прекрасно работает в своем состоянии по умолчанию.

Вы пробовали Pagekit? Как вы к этому относитесь? Дайте нам знать об этом в комментариях!