просто, как будто, напрашивается вариант типа
$config['module']['uploader']['images']['custom-topic-type'] или как то так…
по поводу quality — в функции StoreImage при вызове Save не передается дополнительный параметр конфига, а мог бы — в теле StoreImage есть $aConfig в котором «локальный» quality… а раз оно не передается, то Save использует «глобальные» значения…
например, через $config['module']['uploader']['images']['topic-multi-image-uploader'] не получилось — хоть в корне, хоть в 'transform.@mime...'. При том что transform.max_width, например, отрабатывает норм.
мне бы идеально задать quality и transform для одного пользовательского типа контента(топика) — это возможно?
еще, у меня не заработало quality. реально изменить качество сжатия я смог только через:
$config['module']['uploader']['images']['default']['quality'] = 44;
А как будет выглядеть конфиг(ключ) для пользовательского типа контента?
Расскажите в этом конексте еще про TargetType вообще и topic-multi-image-uploader в частности. Ну и вообще про программное использование новых фишек. Например, программное добавление топика с картинками, правильная привязка, удаление и тд.
Проверять на дубли через ...topic_extra LIKE '%http://altocms.com/218.html%'… не подходит?
Работать будет. Но, подозреваю что по по скорости это не ахти. В случае отдельного поля, там честный деревянный индекс, что даст максимальную производительность. Хотя я могу чего то не знать про LIKE.
Ну и вообще, на будущее хочется знать какие варианты(я так понял тут их >1) расширения функционала есть. Скорее всего в БД отдельная таки таблица будет. А вот как в коде все прописать правильно? Модель топика ли расширять обучая ее оперировать с новой таблицей, или создавать отдельную модель. Как отдельную модель подружить с моделью топика… и тд и тп. Потихоньку в общем сам разберусь но, если распишите(можно отдельно даже) — буду признателен(думаю, не только я).
В основном, разобрался, спасибо. Однако, пока не очень понятен смысл некоторых вещей… Так и не нашел, где и как при обычном сабмите заполняются textshort и text, там вроде только textsource… а если я не задаю явно textshort & text, то у меня в таблицу topc_content ничего не добавляется, со всеми вытекающими… E::Topic_AddTopic($oTopic) при этом возвращает true
Еще посоветуйте плз. Я вот топики импортирую и как то хочется отделить их от всех остальных, но пока еще не понял как лучше. Пока только в отдельном блоге они. Там промелькал тип контента, но я не понял пока где и с чем его едят. Кроме того, нада бы доп.поля.
Например, для урла оригинала, и в отдельной таблице ибо extra не подходит за отсутсвием индекса, а нужно проверять при импорте на дубли, как раз по урлам оригиналов… можно по хэшам смотреть конечно, но не совсем верно. Мме и таблицы url->topcId уже для проверки хватит, но интересно как это по уму «впаять» в движок?
поставил плагин, перезапустил phpstorm — нифига не подсказывает :(
еще интересно, как IDE будет реагировать на вещи типа:
E::Module('User')->…
или
E::Module('PluginMine\Stat')->…
Только я не очень понял как в IDE это заводится? Никакога плагина для phpstorm не нада? Он(phpstorm) из диры с плагином альты все что нада для автодополнения узнает?
ЗЫ. Требую продолжения банкета! :) То есть побольше инфы для разработчиков. Может какой нить cookbook? Например, для меня такой(необчный) подход наследования довольно непривычен, а если были бы примеры раскрывающие всю его красоту(при создании плагинов/модулей), было б здорово. Еще раз спасибо!
Здесь(на демо) этого как раз нет :o Но, в остальном, подтверждаю: взял только что последнюю версию с гитхаба(ветка ver1.1) — глюк есть. У меня он проявляется только при наведении мыши на текущий(который загружен) элемент меню… на других все ок.
// Пробовал в Firefox 35.0.1 и Chromium 39.0.2171.65 Ubuntu 14.04 (64-bit)
в общем то, склоняюсь больше к следованию все таки новому, вместо совместимости… использую 1.1 ветку.
но вот понимания отличий от ЛС нет… я и ЛС то не знаю еще, и в этом смысле было бы здорово чтобы у альты была самостоятельная документация, с развернутыми (даже) идеологическими выкладками… а так, разбираясь, так или иначе натыкаешься на ЛС — забыть бы про него уже тогда :)
А вот еще бы небольшой FAQ на предмет изменений по отношению к LS. Меня интересуют именно API сторона — разбираюсь как плагины писать. И все время разрываюсь — или под LS читать доки, или с Alto разбираться изначально. Вот и хотелось бы знать, какие ничтяки есть в альто и когда имеет смысл их использовать, а когда можно «сохранить совместимость с LS»… Под LS же модуля совместимости с плагинами от альты еще не изобрели? :)
еще вот обнаружил: не могу залить аватарку :(
в консоли видим:
SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data
ататат
кстати, куда лучше подобные вещи писать? сюда или на гитхаб?
А потом, видимо, рег. данные уже в базу вносят, и бот авторизуется и постит топики.
это да — это будет всегда :( разве что :) модуль статсов, предложенный как часть разделеня в ветке про рейтинги, тут вполне бы пригодился — можно уже с таймаутами как то играться и пресекать подозрительную активность даже зарегатых.
а можно подробнее? что за атаки, на чем основаны(почему именно LS/Alto?).
с друпалом недавно намучался с этими уязвимостями :( чего про LS/Alto в этом смысле мне следует знать? :)
Вообще, можно саму задачу логически разделить на две основных — сбор статсов и их обработка, анализ, расчет конечных параметров. Ну и треться задача — вывод этого всего(виджеты, сниппеты и тд).
Так вот, развивая мысль inliquid про различные показатели, в модуль статсов(он как раз может быть inbox) по сути должен быть хуком(хуками) на все возможные действия в системе — не только очевидные лайки и тд. Пишется все что можно. Такое, кстати, могет пригодиться не только для рейтингов.
Ну а дальше эти статсы можно использовать в отдельном модуле рейтингов или чего угодно. Например, можно делать какие то выводы о пользователе или его постах, даже из паузы между ними…
На мой взгляд, только так можно что-то навычислять, не принуждая юзера к какой то отдельной активности на эту тему. С одной стороны, статсы собираются для юзера полностью прозрачно. Но с другой — уже какие то данные модно наковырять, для анализа и росчетов каких то показателей.
Понятно что писать все в бд — затратно. Но это можно заоптимизировать(писать в времянку, а в бд скидывать периодически). Ну и все это настраивается и если не нада, то ради производительности отключается полностью или частично.
Про мотивацию полностью поддерживаю. В этом смысле дополнительной мотивацией для кого то может стать просто расширение системы рейтингов, то есть кроме силы еще что-то, как в играх RPG. Сама туса может быть как игра RPG в том смысле, что участники обладают несколькими параметрами, и как то «прокачиваются» :) где то может какие то параметры даже монетизироваться могут…
У меня в фантазиях основное — система, чтоли, авторитета… не просто сила, которую можно потратить, а циферка, которая описывает значимость, важность, авторитетность этого юзера в системе(группе). Типа даже изначально отталкиваться что есть юзеры-боты или спамеры. Для таких тоже предусмотреть какую то позицию в системе. Ну и дальше какой то механизм «очеловечивания» — автоматика основанная на дейстивях пользователя и и действиях других связанных с этим пользователем… о как :) Если это не утопия, то в итоге можно такой параметр много где применять… вплоть до выборов президента :)
$config['module']['uploader']['images']['custom-topic-type'] или как то так…
по поводу quality — в функции StoreImage при вызове Save не передается дополнительный параметр конфига, а мог бы — в теле StoreImage есть $aConfig в котором «локальный» quality… а раз оно не передается, то Save использует «глобальные» значения…
мне бы идеально задать quality и transform для одного пользовательского типа контента(топика) — это возможно?
$config['module']['uploader']['images']['default']['quality'] = 44;
то есть это какбы глобально получается уже…
А как будет выглядеть конфиг(ключ) для пользовательского типа контента?
Расскажите в этом конексте еще про TargetType вообще и topic-multi-image-uploader в частности. Ну и вообще про программное использование новых фишек. Например, программное добавление топика с картинками, правильная привязка, удаление и тд.
а подскажите еще как по уму вывести cover, а то из коробки(1.1) он нигде не выводится :(
Ну и вообще, на будущее хочется знать какие варианты(я так понял тут их >1) расширения функционала есть. Скорее всего в БД отдельная таки таблица будет. А вот как в коде все прописать правильно? Модель топика ли расширять обучая ее оперировать с новой таблицей, или создавать отдельную модель. Как отдельную модель подружить с моделью топика… и тд и тп. Потихоньку в общем сам разберусь но, если распишите(можно отдельно даже) — буду признателен(думаю, не только я).
Спасибо!
Еще посоветуйте плз. Я вот топики импортирую и как то хочется отделить их от всех остальных, но пока еще не понял как лучше. Пока только в отдельном блоге они. Там промелькал тип контента, но я не понял пока где и с чем его едят. Кроме того, нада бы доп.поля.
Например, для урла оригинала, и в отдельной таблице ибо extra не подходит за отсутсвием индекса, а нужно проверять при импорте на дубли, как раз по урлам оригиналов… можно по хэшам смотреть конечно, но не совсем верно. Мме и таблицы url->topcId уже для проверки хватит, но интересно как это по уму «впаять» в движок?
Спасибо!
еще интересно, как IDE будет реагировать на вещи типа:
E::Module('User')->…
или
E::Module('PluginMine\Stat')->…
Только я не очень понял как в IDE это заводится? Никакога плагина для phpstorm не нада? Он(phpstorm) из диры с плагином альты все что нада для автодополнения узнает?
ЗЫ. Требую продолжения банкета! :) То есть побольше инфы для разработчиков. Может какой нить cookbook? Например, для меня такой(необчный) подход наследования довольно непривычен, а если были бы примеры раскрывающие всю его красоту(при создании плагинов/модулей), было б здорово. Еще раз спасибо!
// Пробовал в Firefox 35.0.1 и Chromium 39.0.2171.65 Ubuntu 14.04 (64-bit)
в общем то, склоняюсь больше к следованию все таки новому, вместо совместимости… использую 1.1 ветку.
но вот понимания отличий от ЛС нет… я и ЛС то не знаю еще, и в этом смысле было бы здорово чтобы у альты была самостоятельная документация, с развернутыми (даже) идеологическими выкладками… а так, разбираясь, так или иначе натыкаешься на ЛС — забыть бы про него уже тогда :)
А вот еще бы небольшой FAQ на предмет изменений по отношению к LS. Меня интересуют именно API сторона — разбираюсь как плагины писать. И все время разрываюсь — или под LS читать доки, или с Alto разбираться изначально. Вот и хотелось бы знать, какие ничтяки есть в альто и когда имеет смысл их использовать, а когда можно «сохранить совместимость с LS»… Под LS же модуля совместимости с плагинами от альты еще не изобрели? :)
в консоли видим:
SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data
ататат
кстати, куда лучше подобные вещи писать? сюда или на гитхаб?
это да — это будет всегда :( разве что :) модуль статсов, предложенный как часть разделеня в ветке про рейтинги, тут вполне бы пригодился — можно уже с таймаутами как то играться и пресекать подозрительную активность даже зарегатых.
с друпалом недавно намучался с этими уязвимостями :( чего про LS/Alto в этом смысле мне следует знать? :)
спасибо!
Вообще, можно саму задачу логически разделить на две основных — сбор статсов и их обработка, анализ, расчет конечных параметров. Ну и треться задача — вывод этого всего(виджеты, сниппеты и тд).
Так вот, развивая мысль inliquid про различные показатели, в модуль статсов(он как раз может быть inbox) по сути должен быть хуком(хуками) на все возможные действия в системе — не только очевидные лайки и тд. Пишется все что можно. Такое, кстати, могет пригодиться не только для рейтингов.
Ну а дальше эти статсы можно использовать в отдельном модуле рейтингов или чего угодно. Например, можно делать какие то выводы о пользователе или его постах, даже из паузы между ними…
На мой взгляд, только так можно что-то навычислять, не принуждая юзера к какой то отдельной активности на эту тему. С одной стороны, статсы собираются для юзера полностью прозрачно. Но с другой — уже какие то данные модно наковырять, для анализа и росчетов каких то показателей.
Понятно что писать все в бд — затратно. Но это можно заоптимизировать(писать в времянку, а в бд скидывать периодически). Ну и все это настраивается и если не нада, то ради производительности отключается полностью или частично.
теперь я знаю как это называется :) спс :)
У меня в фантазиях основное — система, чтоли, авторитета… не просто сила, которую можно потратить, а циферка, которая описывает значимость, важность, авторитетность этого юзера в системе(группе). Типа даже изначально отталкиваться что есть юзеры-боты или спамеры. Для таких тоже предусмотреть какую то позицию в системе. Ну и дальше какой то механизм «очеловечивания» — автоматика основанная на дейстивях пользователя и и действиях других связанных с этим пользователем… о как :) Если это не утопия, то в итоге можно такой параметр много где применять… вплоть до выборов президента :)
SQL Error: Table 'alto.a_blog_type_content' doesn't exist