Исправления и планы версии с mysql
17.09.2009Выложил обновление, с небольшими изменениями, в частности исправление обновления. С этой версии начал постепенный переход в названиях функций в нижнем регистре - только те, которые из одного слова. Раньше практически все методы были с больших букв, но мне реально лениво каждый раз нажимать шифт, и поэтому будет плавная миграция в сторону маленьких букв. Все по прежнему будет работать - и с большими и с маленькими буквами.
Однозначно будет версия с бд, поиски компактного врапера для бд я не нашел - все что смотрел мне не понравилось, так 9 из 10 функций я не буду никогда использовать, а зачем тогда тащить этот хлам? Сделаю я свой велосипед - потомок от стандартного класса mysqli, но не уверен пока в этом. Мне нужно едва ли 10 функций для доступа к бд, точнее это будут надстройки над всего одной - querry. Думалось мне, что было бы здорово иметь некий абстрактный класс, который бы обеспечивал доступ к разным базам: mysql, mssql, sqlite, firebird... Посмотрел я на такие фреймворки - монстры, сделаю я простую надстройку над mysql и не буду париться чужими классами.
Комментарии (47) на запись “Исправления и планы версии с mysql”
Оставить комментарий
Очень нужно!
Возможно ли в "Управление меню" также сотворить полное управление, как, например в темах и постах. Чтоб можно было задавать произвольный адрес. Это бы не только повысило гибкость Блоголета, и, в частности, позволило имитировать объемную структуру сайта, что полезно для PR.
http://zebroid.ru/ и поэтому загонять контент в вордпресс а потом импортировать его в Блоголёт не вариант и тогда теряется смысл простоты настройки Блоголёта.
Теперь надеюсь ясно почему я прошу импорт из xml файлов
Для меня (и многих других, думаю) самый главный плюс блоголета - это то, что он работает на файлах. Поэтому он идеально подходит для рабочих автонаполняемых сайтов. Если будет поддержка mysql, лично я не буду её использовать точно. Если мне понадобится сделать полностью белый блог, или блог, где мне будет страшно потерять какие-то посты - я, при всех плюсах блоголета, выберу вордпресс. Хотя бы из-за большого количества шаблонов и плагинов.
А есть у тебя сайт или страница английской версии блоголета "LightPublisher"? Не нашел ссылки на главной странице.
Есть, но правда не обновляется, сделал одну страницу, до остального руки не доходят:
http://litepublisher.com/
также закуппился целой пачкой доменов litepublisher.org litepublisher.net litepubl.com и в рушке тоже, неиспользуемые домены пока припарковал в гугле.
А почему такой интерес? В смысле что хочется?
http://litepublisher.googlecode.com/
http://kostya-kiev.livejournal.com/
А то шелл-доступ не у всех есть, а вручную потом для всех прописывать немного утомительно :)
tar.gz - про него то я совсем почему то и не подумал: проект делаю под виндой, где с правами нет ограничений, но за совет - спасибо, думаю смогу сделать. Сейчас дистрибутив собирается php скриптом в zip фай, и имеет соответствующие ограничения, в том числе на количество включаемых файлов (500 из за чего я недавно убрал из дистрбутива темы).л Идеальным решением было бы вообще сборка дистрибутива на стороне сервера из файлов репозитория и также закачки архива в download область гугля и у себя на сервере тоже. Хорошая идея - всму свое время.
P.S. в ближайшие пару дней ниаких изменений не будет, ибо сейчас уезжаю на свадьбу (не свою)
Разбивка страницы:
http://blogolet.ru/nebolshie-izmeneniya-i-installyator/#comment-1770
Во frogcms [madebyfrog.com] вывод даты сделан так:
public function date($format='%a, %e %b %Y', $which_one='created')
{
if ($which_one == 'update' || $which_one == 'updated')
return strftime($format, strtotime($this->updated_on));
else if ($which_one == 'publish' || $which_one == 'published')
return strftime($format, strtotime($this->published_on));
else
return strftime($format, strtotime($this->created_on));
}
Кстати там еще есть поддержка mysql, postgresql и sqlite, классы размером по 12 кб.
Папка keywords была одна, ее замена не помогла.
После нажатия кнопки сохранить, в редакторе ссылок, перекидыват на такую страницу:
/admin/plugins/keywords/?content=%3Cli%3E+%3Ca+href%3D%22http%3A%2F%2Fdomen.ru%2Ftag%2Fmytag%2F%22%3Elink_text%3C%2Fa%3E%3C%2Fli%3E%0D%0A%3Cli%3E+%3Ca+href%3D%22http%3A%2F%2Fdomen.ru%2F2009%2F09%2F%22%3Elink_text2%D0%BD%D0%BE%D0%B2%D0%B0%D1%8F%3C%2Fa%3E%3C%2Fli%3E%0D%0A%3Cli%3E+%3Ca+href%3D%22http%3A%2F%2Fdomen.ru%2Flink_text3%2F%22%3Elink_text4%D0%B4%D1%83%D1%8D%D0%BB%D1%8C+%D0%BF%D0%B8%D0%BB%D0%BE%D1%82%D0%BE%D0%B2%3C%2Fa%3E%3C%2Fli%3E&submit=%D0%A1%D0%BE%D1%85%D1%80%D0%B0%D0%BD%D0%B8%D1%82%D1%8C
на которой находится тоже, что и на /plugins/keywords/
Блоголётчик, уведомления об комментах хорошо приходят. у меня хмл-ки вида
<rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:wp="http://wordpress.org/export/1.0/">
<channel>
<item><title>TEST</title> <content:encoded>testpostname</content:encoded><wp:post_date>2009-04-7 12: 21: 51</wp:post_date><wp:status>publish</wp:status></item>
</channel>
</rss>
хорошо елись и 2.6, и 2.8. наверно если теги отличаются, лучше точить под 2.8
Я думаю делать плагином смысла нет, так как это едино разовое действие ну максимум 2-3 раза и "городить огород" тут не стоит.
Мне кажется будет удобней сделать так:
Закидываешь в папку движка папку допустим import
в ней лежат сами файлы отвечающие за импорт экспорт, и сам файл xml допустим с названием wp.xml в браузере запускается определенный фал url/import/import.php и скрипт видит xml файл и приступает к импорту контента.
Потом просто папку import с сервера удаляешь и всё.
Либо можно сделать немного по другому:
Сделать скрипт для импорта, а настройки для импортера по которым будет определятся структура файла с контентом вынести в отдельный файл конфига и там уже каждый сможет подправить под свои нужды.
Пример:
{TITLE} - Название статьи
{ALT_NAME} - Альт_нейм статьи
{KEYWORDS} - мета кейвордс
{DESCRIPTION} - мета дескрипшн
{TEXT} - текст статьи
{TAGS} - таги
{DATE} - дата
{URL} - путь к статье в формате /категори/статья.html
{URL-NOCAT} - путь к статье без категории
{URL-NOCAT-EXT} - путь к статье без категории и расширения файла
{URL-CAT} - путь без статьи (т.е. путь к кореню категории)
{CAT-NAME} - название категории в которой находится статья;
Это пример как можно делать экспорт из программы Зеброид, которой я и пользуюсь для подготовки контента.
Вот обсуждение по настраиваему экспорту:
http://zebroid.ru/forum/viewtopic.php?f=5&t=143&start=0
Возможно конечно не всех устроит такой вариант но как альтернативный мне кажется вполне хорош, так как не привязан именно к файлам которые генерит Wordpress.
Если у кого есть предложения высказывайте их.
Вначале я думал про простой скрипт импорта - наподобии импорта напрямую из базы wordpress, но потом подумал, что удобнее было бы загрузить xml файл через форму в админке. Для простых тегов достаточно таблицы совмещения названий тегов названию свойств поста, как пример
title = title
pubDate = pubdate
link = link
и так далее, но не все так просто, например комментарии являются вложенными тегами, ннекоторые значения находятся в атрибуте тега, поэтому универсальной таблицы сделать не удастья. Как один из вариантов я рассматривал в админке на странице импортеров инфа о существующих импортеров беретсятолько в виде имени файла импортера, без комментариев к нему. С другой стороны это тоже не вариант - все же нужен файл спутник например .ini где бы было описание, имя используемого класса - получается такой вариант плагина, но не в папке плагинов. Либо помещать импортер в папку плагинов, но для импортеров добавить в about.ini новое значение, например type = importer, чтобы в явном виде указать вид плагина и не показывать его в в общем списке файлов, а показывать только на странице импортеров. Либо делать страницу импорта на странице плагинов - хотя на мой взгляд логичнее место в обслуживании, чтобы не замусорять страницу плагинов.
Комментарии не всегда нужны! Вот допустим у меня во вновь созданном контенте их вообще нет и на некоторых рабочих сайтах которые я бы хотел перенести их тоже нет либо просто спам.
Вы сильно не заморачивайтесь чего и где и как размещать, выпустите для начала рабочий прототип, а дальше пользователи уже посоветуют как им удобней пользоваться импортом.
<!--nextpage-->