avatar
+0.15
0.410
просто, как будто, напрашивается вариант типа
$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 в частности. Ну и вообще про программное использование новых фишек. Например, программное добавление топика с картинками, правильная привязка, удаление и тд.
спасибо!
а подскажите еще как по уму вывести cover, а то из коробки(1.1) он нигде не выводится :(
Проверять на дубли через ...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 в том смысле, что участники обладают несколькими параметрами, и как то «прокачиваются» :) где то может какие то параметры даже монетизироваться могут…

У меня в фантазиях основное — система, чтоли, авторитета… не просто сила, которую можно потратить, а циферка, которая описывает значимость, важность, авторитетность этого юзера в системе(группе). Типа даже изначально отталкиваться что есть юзеры-боты или спамеры. Для таких тоже предусмотреть какую то позицию в системе. Ну и дальше какой то механизм «очеловечивания» — автоматика основанная на дейстивях пользователя и и действиях других связанных с этим пользователем… о как :) Если это не утопия, то в итоге можно такой параметр много где применять… вплоть до выборов президента :)
это теперь ок, спс
по обновлению — попытался еще раз, та же фигня:
SQL Error: Table 'alto.a_blog_type_content' doesn't exist