Недавно столкнулся с подобной проблемой. Проект «переехал» с другой CMS.
Поэтому запросы в БД Пересчет количества в топиках
UPDATE `PREFIX_topic` t
SET t.topic_count_comment = (
SELECT count(c.comment_id) FROM `PREFIX_comment` c
WHERE c.target_id = t.topic_id AND c.comment_publish = 1
AND c.target_type = 'topic')
Пересчет количества в topic_read
UPDATE `PREFIX_topic_read` t
SET t.comment_count_last = (
SELECT count(c.comment_id) FROM `PREFIX_comment` c
WHERE c.target_id = t.topic_id')
Некоторые экшены проксируют вызовы несуществущих методов в вызовы модулей.
Это не совсем очевидно и не масштабируемо, но так сложилось исторически. Я рекомендую всегда использовать полный синтаксис Engine::GetInstance()->Module_Method() или сокращенный алиас LS::Module_Method() (для версий PHP 5.3+, или LS::E()->Module_Method() — для ранних версий PHP)
$oTalk = $this->Talk_SendTalk(
$yourMessageTitle,
$yourMessageText,
1, /* admin user ID */
array($oUser),
false, /* no notify */
false /* no blacklist */
);
$this->Talk_DeleteTalkUserByArray($oTalk->getId(), 1 /* admin user ID */);
В этом случае все будет работать как и при предложении дружбы. Т.е. в почтовом ящике пишет от кого письмо, но ответить нельзя. Да и код выглядит приятнее.
Просто многие следуют принципу «что слышу, то пою», а те кто им изначально это напел наверное погоняли какой-нить стандартный ORM Framework против «пустных» запросов и решили «что они все такие». Я сам когда-то сравнивал Doctrine и AdoDB — и да, doctrine в 30 раз медленее AdoDB, но всё равно в пределах тысячных секунды. Это всё статичный оверхед, и с ним можно спокойно жить :)
taSize: function(obj) {
obj=$(obj);
var tareasize = obj.getSize();
if (tareasize.y > 599) {tareasize.y = 0}
obj.style.height=tareasize.y+200+'px';
},
теперь по нажатию на кнопку поле для текста увеличивается каждый раз на 200 пикселей в высоту, а при достижении 1000 пикселей уменьшается до первоначального
…
{/if}
Поэтому запросы в БД
Пересчет количества в топиках
Пересчет количества в topic_read
LS::CurUsr() => Engine::GetInstance()->User_GetUserCurrent()
LS::Adm() => Engine::GetInstance()->User_GetUserCurrent()->isAdministrator()
Это не совсем очевидно и не масштабируемо, но так сложилось исторически. Я рекомендую всегда использовать полный синтаксис Engine::GetInstance()->Module_Method() или сокращенный алиас LS::Module_Method() (для версий PHP 5.3+, или LS::E()->Module_Method() — для ранних версий PHP)
Кстати, вот другие алиасы:
LS::Ent($sName, $aData) => Engine::GetEntity()
LS::Mpr($sClassName, $sName, $oConnect) => Engine::GetMapper()
LS::CurUsr() => Engine::GetEntity()->User_GetUserCurrent()
LS::Adm() => Engine::GetEntity()->User_GetUserCurrent()->isAdministrator()
В шаблонах аналогичным образом можно использовать инстанцию $LS: {$LS->CurUsr()->getName()}
В этом случае все будет работать как и при предложении дружбы. Т.е. в почтовом ящике пишет от кого письмо, но ответить нельзя. Да и код выглядит приятнее.
Надеюсь будет полезно кому-то.
а в panel.js
дописал
теперь по нажатию на кнопку поле для текста увеличивается каждый раз на 200 пикселей в высоту, а при достижении 1000 пикселей уменьшается до первоначального
Находим
И после него вставляем
В идеале конечно лучше проверять включена ли активация по почте и после её проведения отправлять письмо, это же так, чисто пример реализации
в SimilarTopics.class.php
в Sphinx.class.php
Слегка поясню что же я сделал:
1) Ищется теперь только в опубликованных
2) Усложнён запрос, теперь он формулируется так:
Теперь теги ищются среди тегов, а заголовок в заголовках и текстах, причём совпадения в тегах по двум словам, а в заголовке должны совпасть 60% слов.
P.S. Конечно в конфигурациях сфинкса (там где вы писали запросы к БД) нужно в запрос к топикам добавить поле topic_tags
Написал просто ппц как, но мне простительно, см. время коммента. Надеюсь кто нить разберётся в этом ночном бреде