arigoda

да нет, в этом конкретном случае имена до 16 символов не должны резаться, как и раньше. да и потом - я просто хотел таким спобосом уточнить причину, а не предложить решение.

вопросы SEO обсуждались здесь неоднократно. ищите.

расстояние там напрямую зависит от линейных размеров смайлов, если не ошибаюсь. спрячьте все огромные - и должно быть нормально.

ааа... ясно. а что если создать BB-коды - [prefix]гр. пользователя[/prefix] ну и такой же - суффикс? ну а далее вопрос сводится к грамотному созданию BB-кода, который будет залинкован на соответствующий кеш группы. только при публикации поста - не преобразоваывать код в HTML-теги, а хранить как есть, чтоб при выводе темы теги обрабатывались по адекватному кешу группы.

Не знаю как у других, но мой интерпретатор русского языка задымился. В первую очередь от конструкций наподобие: И куски кода, пожалуйста, берите в тег CODE - нагляднее.--- По сути. Вы приводите кусок стандартной обработки информации о пользователе. Конкретно указанный код обрамляет имя пользователя в префиксы и суффиксы, указанные в настройках группы, к которой пользователь принадлежит - [приставка перед именем пользователя] и [суффикс после имени пользователя] соотвественно. А что значит "фиксирован на конкретной группе"? Вы хотите определить какие-то еще группы, кроме стандартной группы пользователя? Уточните, по каким условиям вы хотите дописывать префиксы и суффиксы к своему "тексту"?

мы сейчас, конечно, уйдем в оффтоп, но на самом деле это совершенно нормальная жизненная ситуация. смотрите сами: у вас что-то не работает, вы просите совета. с себя ответственность вы сразу снимаете - мол, ставил чистый дистрибутив (хотя совершенно непонятно, что за дистрибутив у вас такой). представитель разработчика софта прекрасно знает, что в описанных условиях его софт обязан работать и это многократно проверено. какой он делает вывод? причина в настройке базового софта на сервере. совершенно логично. вы форвардите реплику разработчика софта хостеру, но хостер-то тоже прекрасно знает, что у него десятки ресурсов работают на такой связке. и делает закономерный вывод - это софт кривой. таким образом вы попадаете в порочный круг, из которого вырваться можно только одним способом - предоставить, наконец, более подробную информацию. вот я и предлагаю вам один из вариантов - обратитесь напрямую в суппорт, в clientarea. специалисты убедятся, что у вас совершенно станартный дистрибутив, уточнят в чем именно была причина и уже техническим языком опишут проблему хостеру (или извинятся и скажут - да, вы нашли у нас ошибку, вот мы ее исправили, спасибо за сотрудничество!) есть и другой путь, прямо противоположный - обратитесь со слезливым письмом хостеру, пусть они выделят специалиста, который тоже техническим языком скажет вам - что именно не так в софте (или извинится и скажет - да, благодаря вашей наблюдательности мы смогли оптимизировать наши настройки, спасибо вам огромное!)

здесь был намек на решение: Trash Can + Undelete (or restore) posts and topics in 2.1.x.

вы бы хостеру еще матом написали ;-) кому ж понравится такое обращение - "эй вы там, шо за хрень вы понастроили?" думаю, правильнее всего вам обратиться в команду поддержки IBResource, чтобы специалист подключился к вашему хосту и посмотрел что не так в настройках.

кодировка базы - UTF? --- попробуйте - в sources/action_public/profile.php найдите строчку: $member['members_display_name_short'] = $this->ipsclass->txt_truncate( $member['members_display_name'], 16 ); замените в ней 16 на 32, вот так: $member['members_display_name_short'] = $this->ipsclass->txt_truncate( $member['members_display_name'], 32 ); это решает проблему с именами длиной до 16 символов?

запросто ;-) Нумер раз: $this->ipsclass->DB->build_query( array( 'select' => 'p.post_date, p.author_id, p.author_name, p.pid', 'from' => array( 'posts' => 'p' ), 'where' => "p.topic_id=$tid", 'order' => "p.{$this->ipsclass->vars['post_order_column']} DESC", 'limit' => array(0,1), 'add_join' => array( 0 => array( 'select' => 'm.id, m.members_display_name', 'from' => array( 'members' => 'm' ), 'where' => "p.author_id=m.id", 'type' => 'left' ) ) ) ); Нумер два: $this->ipsclass->DB->build_query( array( 'select' => 'p.post_date, p.author_id, p.author_name, p.pid', 'from' => array( 'posts' => 'p' ), 'where' => "p.topic_id=$tid", 'order' => "p.{$this->ipsclass->vars['post_order_column']} ASC", 'limit' => array(0,1), 'add_join' => array( 0 => array( 'select' => 'm.id, m.members_display_name', 'from' => array( 'members' => 'm' ), 'where' => "p.author_id=m.id", 'type' => 'left' ) ) ) );

Экспорт последних тем с форума если вопросы остаются - лучше задавать там же. ключевые слова для поиска - экспорт и export

ой-ой-ой, sM1Le, Song, позвольте вмешаться, ИМХО вы в другую степь ушли. Song, ты наверное имеешь в виду проверку последнего поста форума - за это отвечает кусок кода дальше в этом скрипте, он дает отдельный запрос, уже ориентируясь на результаты работы обсуждаемого куска кода. sM1Le, собственно этот скрипт вообще забивает на поля last_poster, starter - он их, собственно, и обновляет, что хорошо, потому что ресинхронизация после фикса этого бага убрала все созданные ранее ошибки. просто сколько я ни смотрел - ну так и не понял, что же на самом деле за ситуация, когда запрос из posts окажется пустым. наверное это возможно только если база была наглым образом покорежена [кривыми ] руками и мы имеем совершенно пустую запись о теме вообще без постов. но тогда упоминавшееся выше присвоение данных первого поста последнему все равно не имеет никакого смысла - первый-то запрос тоже будет пустым ;-))) чем, собственно, отличается оригинальный запрос последнего поста? он похоже предназначен для обновления последнего поста форума, а не темы, ибо выдергивает еще и сведения, к какому форуму относится пост, что, согласитесь, мало интересно нам при поиске последнего сообщения в теме ;-) с другой стороны, он ничего не спрашивает из таблицы members и, как следствие, теоретически должен неправильно работать с отображаемыми именами, если они менялись.

sources/ipsclass.php function txt_truncate($text, $limit=30) вот так оно и обрезается.

там же. видим: //----------------------------------------- // Get last post info //----------------------------------------- $this->ipsclass->DB->cache_add_query( 'mod_func_get_last_post', array( 'tid' => $tid, 'orderby' => $this->ipsclass->vars['post_order_column'] ) ); $this->ipsclass->DB->cache_exec_query(); $last_post = $this->ipsclass->DB->fetch_row(); $last_poster_name = $last_post['members_display_name'] ? $last_post['members_display_name'] : $last_post['author_name']; нетрудно убедиться, что никакого поля members_display_name запрос mod_func_get_last_post никогда не возвратит - он обращается за инфой к таблице posts (ну и заодно - topics), так что даже захоти он вытащить отображаемое имя - не выйдет, нету там такого поля. есть в posts только author_name. вопрос знатокам: какого лешего понадобилась проверка в последней строке? кстати говоря, из такой проверочки следует еще один неутешительный вывод. если человек сменит свое отображаемое имя, то после ресинхронизации тем имя последнего автора опубликуется старым. все потому, что author_name в posts - не меняется при смене имени и это, как уже было сказано выше, обычно ни на что не влияет - не используется это поле при выводе сообщений не-гостей. а вот при ресинхронизации скрипт заботливо это старое имя вытащит и опубликует ;-) --- кстати, чуть ниже идет Get first post info - и там все уже делается правильно. --UPD-- ааа, ясно ;-) там тоже хотели использовать другой запрос, который запрашивает и members тоже, а потом забыли видать ;-) --------------------------------- UPD --------------- в общем, на скорую руку предлагаю пофиксить так. sources/lib/func_mod.php, функция rebuild_topic находим: $this->ipsclass->DB->cache_add_query( 'mod_func_get_last_post', array( 'tid' => $tid, 'orderby' => $this->ipsclass->vars['post_order_column'] ) ); меняем на: $this->ipsclass->DB->build_query( array( 'select' => 'p.post_date, p.author_id, p.author_name, p.pid', 'from' => array( 'posts' => 'p' ), 'where' => "p.topic_id=$tid", 'order' => "p.{$this->ipsclass->vars['post_order_column']} DESC", 'limit' => array(0,1), 'add_join' => array( 0 => array( 'select' => 'm.id, m.members_display_name', 'from' => array( 'members' => 'm' ), 'where' => "p.author_id=m.id", 'type' => 'left' ) ) ) ); ниже в той же функции находим: 'last_poster_id' => $last_post['author_id'] ? $last_post['author_id'] : $first_post['author_id'], меняем на 'last_poster_id' => ($last_post['author_id'] || $last_post['author_id']==0) ? $last_post['author_id'] : $first_post['author_id'], по идее в функции два совершенно одинаковых запроса с джойнами, каждый из которых выбирает всего одну строчку. наверное можно все это как-то сделать одним запросом? тут я, к сожалению, не силен...