Визитки с формой и отправкой заявки на мыло - да, думаю именно так. Попробовать определённо стоит. --- Добавлено --- Запилил нормальное описание http://pinpie.ru/ru/manual О PinPIE это лёгкий движок маленьких сайтов. Все страницы и обработчики url'ов хранятся в php-файлах. Так же есть возможность кэширования. Механизм кэширования прозрачный и предсказуемый. Просто подключите свои любимые классы, функции, ORM, и можно начинать писать код. # Плюшки Лёгкий Быстрый Легко понять Теги: чанки, сниппеты, константы и для статик файлов Всё хранится в файлах, из чего следует: Редактируйте весь контент в своей любимой IDE или текстовом редакторе, со всеми плюшками: подсветкой, автоформатированием, автосохранением, автозагрузкой и привычными хоткеями Полная поддержка дебага включая конкретные номера строк и контроль выполнения скрипта из IDE Поддержка акселераторов даёт сверхнизкое время отклика Дружит с системами контроля версий — все версии вашего контента защищены от потери при редактировании или как-то иначе Удобно деплоить Удобно бэкапить Прозрачный роутинг урлов Конфиг выбирается в зависимосте от имени сервера — удобно разрабатывать с локальным конфигом, деплоить с другим, всё это живёт в проекте и в системе версий Кеширование сниппетов прозрачно контролируется: не кэшировать (дефолтно), кешировать на точное время в секундах и кешировать навсегда Кэшированные сниппеты обновляют своё содержимое автоматически если их файл или файл их детей любого уровня поменялся Управляемые правила кэширования, основанные на HTTP-коде ответа и GET-параметрах чтобы раздельно контролировать кэширование для 200, 404 и других ситуаций Поддержка темплейтов или вывод текста как есть Возможна интеграция с темплейт-движками типа Twig, Smarty, Mustache и др. Поддержка cookie-free серверного шардинга для параллельной загрузки статик контента Автоматическая преминификация для статик файлов (картинки, css, js, и др.) Автоматическая прекомпрессия (gz) для статик файлов (картинки, css, js, и др.) Требует минимального знакомства с PHP и HTML # Краткий обзор PinPIE спроектирован так чтобы выдавать 100-150 страниц в секунду даже на дешёвом VPS/VDS хостинге. Но его можно использовать и на шаред хостинге. PinPIE хранит весь контент в файлах "*.php", которые кэшируются опкод-кэшером, что позволяет инклудить страницы, сниппеты и чанки просто молниеносно. В PinPIE используются теги. Теги можно кэшировать. Кэширование легко включается и выключается отдельно для каждого тега. Управление кэшированием тегов очень понятное и простое. При обновлении файлов PinPIE автоматически перекэширует то, что изменилось. Ниже можно чуть подробнее прочесть об этом всём. # Как начать использовать PinPIE Чтобы начать использовать PinPIE достаточно просто закинуть файлы и папки из архива в корень сайта, заинклудить /pinpie/pinpie.php, и создать страницу /pages/index.php, которая по‑дефолту использует/templates/default.php, который тоже нужно создать с содержимым [[*content]], но работать будет и без него. И всё! Должно работать! Более подробные инструкции по настройке и запуску PinPIE читайте тут. # Контент хранится в файлах Весь контент хранится в файлах. Страницы живут в папке /pages, сниппеты кода в /snippets, чанки в /chunks, темплейты соотв. в /templates. Можно создавать папки в папках. # Теги PinPIE Парсер PinPIE работает с тегами. Синтакс тегов вдохновлён системой тегов CMS ModX. Она мне очень нравится. Основные типы тегов: Чанки — кусочки простого текста Сниппеты — кусочки php-кода, который надо выполнять Более подробно можно прочесть в доке по тегам. # Кэширование PinPIE позволяет контролировать автоматическое кэширование сниппетов. Из коробки поддерживается кэширование в: Memcache — привычный способ APC — самый быстрый файлики — работает везде, и при небольшом размере сидит в кэше ОС и порой выходит быстрее Мемкеша можно вообще отключить Более подробно можно прочесть в доке по кэшу. # Файловая структура PinPIE Текущая структура всех файлов и папок: Код (Text): / ├── chunks/ папка для чанков ├── config/ папка для конфигов ├── filecache/ используется только если выбрано кэширование в файлах ├── pages/ обработчики урлов, т.е. страницы ├── pinpie/ собственные файлы PinPIE живут именно в этой папке │ ├── classes/ основные файлы PinPIE │ │ ├── cachers/ несколько файлов классов кэшеров │ │ │ один из которых согласно конфигу │ │ │ подключается на старте │ │ ├── cache.php класс, контролирующий операции кэширования │ │ ├── cacher.php интерфейс кэшера │ │ ├── cfg.php загрузчик конфига, дефолтные значения живут тут │ │ ├── pinpie.php основной код PinPIE │ │ └── staticon.php методы работы со статик файлами │ ├── pinpie.php точка входа PinPIE │ └── throw.php несколько функций, используемых в коде PinPIE ├── snippets/ папка для хранения сниппетов - кусочков исполняемого кода └── templates/ папка темплейтов. Не забудьте создать default.php Во всех пустых папках есть файлик 'dummy' который нужен, чтобы папка точно создалась при заливке. Источник: http://pinpie.ru/ru/manual --- Добавлено --- Перевёл краткое описание примеров http://pinpie.ru/ru/examples Вот тут http://pinpie.ru/ru/examples/important важное замечание о том, что надо в примеры закинуть файлы пинпая в папку с примером. Простейший сайт с двумя страничками http://pinpie.ru/ru/examples/simplest Простой пример с основными тегами http://pinpie.ru/ru/examples/basic Пока больше нету. Но будут. --- Добавлено --- Если никто ничего не напишет - я убью котёнка и сделаю из него пирог!
Игорь, на днях буду делать сайт-визитку музыкального исполнителя. В общем, свой сайт Когда-то начинал писать с нуля, сейчас на пинпае начну. Отпишусь)
Круто! Надеюсь, понравится! =) --- Добавлено --- Всегда, когда знакомишься с новым инструментом, сначала очень радуешься, потом, когда нащупываешь его границы - немного печалишься. Но именно когда знаешь точно границы применимости инструмента, именно тогда он становится удобным.
Ну по описанию как раз нужен именно для моих целей) Видал когда-то и другие движки маленькие, но тут я хоть в случае чего могу спросить у автора напрямую какие-то вещи
отсюда http://pinpie.ru/ru/manual/cache Чтобы закешировать сниппет, нужно выставить в теге желаемое время в секундах: [[тут$snippet]]. На текущий момент есть три варианта: [[$some_snippet]] — кеширование отключено, сниппет будет выполняться каждый раз [[3600$some_snippet]] — сниппет закеширован на один час [[!$some_snippet]] — закэширован навечно. Если файл сниппета или файлы входящих в него тегов поменяются - всё перекешируется само. Это очень удобно. --- Добавлено --- Соответственно, это позволяет кешировать допустим комментарии на минуту или хоть на секунду. Если нужно. Т.е. даже если кешировать на секунду, то это даёт то, что запросов к бд не будет чаще чем раз в секунду. А ещё сниппет перекешируется если его гет-параметры поменяются. Это такие параметры, которые можно передавать в сниппет вот так: [[$snippet?foo=bar]] и в сниппете будет переменная $foo которая равна "bar". Так вот, если сниппет закешируется [[3600$snippet?foo=bar]] допустим на час, а мы поменяем то, что передаём - то он перекешируется. Можно например, ну я просто пример привожу с потолка, например если есть форум, а в форуме есть топик, и есть сниппет, который рисует топик [[$topic?id=845]] то мы можем его закешировать хоть навсегда [[!$topic?id=845]] Но как быть, если оставят новый камент в топике, его же нужно перерисовать? Можно сделать так. Передавать в сниппет параметр скажем айдишник последнего сообщения или время редактирования последнего сообщения, оно же время создания последнего сообщения. Эта денормализация удобна, поэтому пусть в этом примере она будет. Т.е. когда кто-то отписался в топике или подправил, то мы это поле обновляем. Так вот, мы можем сделать так: PHP: <?php echo '[[!$topic?id=' . (int)$topic['id'] . '&edit=' . (int)$topic['edited'] . ']]'; где $topic['id'] - айдишник топика, а $topic['edited'] - юникс время редактирования в секундах Получается, что хоть ни $edit, ни $topic['edited'] не используются в сниппете (или используются - не важно), каждый раз когда это время меняется - сниппет перерисуется. А всё остальное время будет сидеть в кеше. Даже можно номер страницы сюда добавить. Получается, что запрос к бд по топику мы делаем всегда, а все остальные запросы уже не делаем почти никогда. Вот так. Пример утрированный, но понятный. Всем хорошего вечера! --- Добавлено --- Я надеюсь, кто-то прочтёт это внимательно.
В общем начал разбираться. И сразу не могу понять: не хочет работать роутинг. Главную страницу открывает, а about выдаёт 404 (это в примере basic, но такая же история с simpletest). В конфиге ничего не прописывал, сделал всё с нуля --- Добавлено --- отмена тревоги, перечитал доку, нужно все запросы отправить на индексный файл
Это видел. Но, почему-то мне кажется, при её использовании только всё запутается --- Добавлено --- Теперь ещё один момент не могу поймать: в шаблоне есть [[*title]] и использован он 2 раза. Но в h1 он выводится, а в <title> нет --- Добавлено --- А нет, он вообще не выводился. Всё норм, его для начала создать надобно.
при включённом дебаге плейсхолдеры видны, т.е. остаются, поэтому не пужайся. Я делаю финт ушами, что в конфиге проверяю айпишник, и если это мой, то включаю дебаг. --- Добавлено --- Если что - я тут. Знайте это. Я всегда тут. И давно. --- Добавлено --- Ищу героя, который решится запилить на этом деле сайт, позволит так сказать обкатать в бою. Кстати на форуме кроме меня есть ещё один человек, который с этим двиглом знаком.
попробовал вынести файлы за публичную папку (ну ту, к которой переходит при обращении /), т.е. выше неё, а в public_html засунул index.php в котором подключается '../index.php' так начало сыпать ошибки, типа не можем найти конфиг в public_html/config так что-то, что-то у тебя не продумано.. еще хотел спросить, если какой-нибудь неудачник, например такой как я захочет свои какие то классы, хелперы например, куда их засовывать и как их подцеплять?
=) @VLK Спасибо, что уделил время. Я буду рад тебе помочь с любыми вопросами. ну в принципе я держу такую структуру, при которой статика и php-файлы живут отдельно, и у меня не возникает проблем. Может быть тебе просто стоит танцевать от обратного - утащить статику в другую папку, и всё? Т.е. прописать путь к статик фолдеру, это есть в доке по конфигу. Вообще я держу пхп-скрипты в одной папке; статик файлы, которые уходят клиенту, типа скриптов js и картинок - в другой, храню пользовательское барахло в третьей. Эти папки могут жить в разных местах, конечно же. И они в конфиге прописаны так, чтобы не пересекаться, так что это однозначно можно сделать как-то. И на пхп и статику я ставлю только чтение права. А писать можно только в пользовательский сторадж. В пинпай есть проверка реального пути, чтобы нельзя было заинклудить или подцепить статикой файл, который находится за пределами своей родной папки. Так что в приципе это дело предусмотрено. Может я просто слишком костноязычен, но изначально я закладвал возможность секурной конфигурации. ну как минимум ты подключаешь пинпай, а не пинпай подключает тебя, так что конечно можно что-то делать в index.php, как обычно. С другой стороны, в пинпай есть preinclude, которые я по тупости забыл описать в доке. Они подключаются до инклуда страницы и могут задаваться в конфиге. Я опишу это обязательно в ближайшее время, спасибо, что помог найти это упущение. По дефолту это файл preinclude.php который лежит рядом с индексом, после страницы подключается postinclude.php
я просто исходил из того, что если тебе надо секурно, то ты сам правишь конфиги своего веб-сервера. А если надо просто - то всё валишь в кучу в одну папку и точно работает. вот тут есть примерные конфиги. Оба они простые. Но во втором, который с шардингом, можно задать разные пути к папкам. Я же использую конфиг такого типа: Код (Text): server { server_name www.site.com; return 301 http://site.com$request_uri; } server { server_name site.com; ###################################################################### #site listen 80; root /var/www/site.com; gzip on; ###################################################################### #connection keepalive_timeout 5; client_max_body_size 10G; client_body_buffer_size 128k; ###################################################################### #logs access_log /var/www/site.com/log/access.log; error_log /var/www/site.com/log/error.log error; #access_log off; #error_log off; ###################################################################### #locations location / { fastcgi_pass unix:/var/run/php-fpm.site.com.sock; fastcgi_param SCRIPT_FILENAME /app/backend/index.php; include /etc/nginx/fastcgi_params; } } server { gzip_static on; gzip on; gzip_min_length 1100; gzip_buffers 64 8k; gzip_comp_level 5; gzip_http_version 1.1; gzip_proxied any; gzip_types text/plain application/xml application/x-javascript text/css; server_name s0.site.com s1.site.com s2.site.com s3.site.com s4.site.com s5.site.com s6.site.com s7.site.com s8.site.com s9.site.com; listen 80; root /var/www/site.com/app/static; ###################################################################### #protective locations location /nbproject {deny all;} location /.idea {deny all;} location /.svn {deny all;} ###################################################################### #static location location / { access_log off; log_not_found off; expires max; add_header "Access-Control-Allow-Origin" "$http_origin"; } }
тут ещё можно увидеть gzip_static - это модуль который ищет рядом со статик файлом его .gz вариант, чтобы не пережимать каждый раз. Пинпай умеет автоматически пережимать статики и класть рядом.
ну а разве эти CMS написаны таким профессионалом как @igordata, да и разве там есть что-то сложное? просто правильно определить папку с файлами. но там только Nginx, а если какой-нибудь нуб захочет воспользоваться твой CMS, который немного шарит в PHP, а .htaccess для него просто какой то файл, да и использовать он будет CMS на простом хостинге, где оно работать не будет. хороший продукт это хорошо, но это полдела, вторая часть дела это хороший маркетинг, по этому надо все дописывать. ты же не хочешь что бы потом, этот чувак с глупыми вопросами, который уже давно не появлялся, которого кажется Евгений зовут, ну или подобный ему, воспользовавшись твоей CMS везде писал что она не работает, а у того кто её сделал кривые руки.
Для нубов must have дружелюбная интуитивно-понятная админка, иначе они теряются и паникуют, ящитаю --- Добавлено --- Но PinPIE типа как не для нубов. Админка это тот самый маркетинг, которого так не хватает! --- Добавлено --- Написать, что ль
Но PinPIE типа как не для нубов. это не очевидно ))) вот в чем проблема. Работает он как надо, или нет)