Тип сидит в role_id.
Но там в таблице пользователей чисто номер типа.
И надо глянуть, что там в модельке, отбирается ли это поле в result

Глянули? Отбирается?

Да. Смотрите в этом файле, где отбираются поля. И для образца как раз ищите fio.
Где fio, password, name, phone отбирается - это как раз из таблицы пользователей.
Если там нет role_id, то надо по образу соседних добавить.

Я ж говорил
Если вышла цифра - это id типа пользователя. 1 - админ, 2 - модератор, 3 - покупатель (или какие там номера, я не помню, мышку подведите в админке к каждому). Чтобы выходило имя типа доступа, надо его в таблице users_role выдергивать.
Например, так:

Блин, нет. В $result["role_id"] сидит цифра!
Уф. Вот как объяснить?
Этот код только название типа доступа запишет в переменную $name_role - я её так, для примера назвал.
Чтобы это применить в моделе и вьюхе, надо назвать переменную так же, как и другие переменные. Я не помню навскидку, но там как везде, массив $result[""], готовящийся к передаче во вьюху.
Сначала добавляете к полям role_id. Потом эту role_id используете в запросе за именем, в query_result.
А вместо переменной $name_role пишете $result["name_role"], чтобы во вьюхе эту $result["name_role"] и вывести.
Хотя смотря как там принимающий массив называется, может $rowt["name_role"] она будет. Я не помню!
Тут работы на минуту, а писать все эти объяснения дольше!

Да это проблема давнишняя, от цмс не особо зависит. Вон, полно обсуждений

Мы в пакете ничего особо такого не меняли. Обычные корректные заголовки, 200 ок, last modify и пр..

У себя посмотрел в вебмастере на сайтах, нет такой проблемы.
Может, в сочетании с хостингом что-то получается?

Давайте приводить сайты, урлы страниц с проблемой, и хостинги. Будем смотреть, сравнивать. Как-то локализуем, что именно яндексу не нравится.

Разбираемся

Мы проанализировали ситуацию и предполагаем, что это может быть из-за gzip-сжатия страниц. Но чтобы убедиться, нужно это сжатие отключить на каком-то проблемном сайте и затем дождаться переиндексации. Кто готов поэкспериментировать?

Хотя есть еще одна теория. Gzip вряд ли, ведь тогда весь сайт был бы проблемным, а так только некоторые страницы.
Кто может дать в службу поддержки свой сайт с фтп для анализа? Кто смелый?

Да не, экспериментов не будет. Только посмотреть, без воздействия.
Ведь только некоторые страницы с ошибкой.
А у нас точно нет каких-то особых заголовков для некоторых страниц. Может, сжатие некорректно работает из-за какого-то содержания страниц особого. Например, в карточке товара какой-нибудь особый баннер выводится, который некорректно сжимается. Или может BOM, который очень у многих фигурирует в шаблонах и вьюхах, мы уже рукой махнули каждый раз поправлять всех. Например, шаблон карточки товара отредактировали в обычном блокноте. В результате туда BOM записался. Скрипты не жалуются, так как BOM после заголовков выводится, а вот на content-lenght влияет. А при сжатии он учитывается/не учитывается. Или Яндекс его не видит/не считает за символ и по мнению яндекса там длина меньше. А сервер его видит и дает большую content-lenght. А может наоборот...
Прикол в том, что на всех сайтах, что делали мы, этих ошибок нет. А мы точно всё в UTFwithoutBOM пишем.
Так что надо смотреть.

Да не шумите уже, ситуация в первостепенном анализе и разборе. Примеров много дали в ТП, вместе с доступами, так что в ближайший день-два разберемся, решим и выложим.

Мы связались с Яндексом.
Они подтвердили, что косвенно ошибка с их стороны и они устранили этот недочет в алгоритме индексирования сайтов. На наш вопрос, нужно ли нам что-то менять в CMS и зависело ли что-либо от нас, ответ "нет".
В общем-то, выше в теме уже был ответ Яндекса с подобным смыслом.

Так что ждем

Так он правильный! Тут похоже дело не в том, что CMS неправильный заголовок отдает, а в том, что размер content-lenght ранее был другим, и при повторном обращении робота изменился!
Нам прислали в ТП с десяток сайтов с сотней примеров и страниц и мы все проанализировали. НЕТ разницы между исключенными страницами и неисключенными, НЕТ разницы между размером с сервера и размером отдаваемым заголовком! Всё идентично и корректно.
Исправлять-то нечего, нет локализованной проблемы. Мы не нашли ни одного сайта, где заголовок и реальный content-lenght с сервера отличался бы.
Проблема ведь в чем? В том, что "Яндекс выкинул некоторые страницы в панели вебмастера".Из-за чего? Из-за ошибки в алгоритме самого Яндекса, и Яндекс уже сказали, что они у себя эту ситуацию исправили. Мы на этот процесс никак не могли и не можем повлиять.

Ну начнем с того, что "проиндексировался" и "обращение робота" - это разные понятия. Робот может пару месяцев болтаться на сайте, несколько раз обращаясь к нему, прежде чем произойдет апдейт, обновится поисковый индекс и тем более панель вебмастера.
Во-вторых, мы лишь предполагаем о работе алгоритмов, а не знаем точные причины. В любом случае, мы специалистам компании Яндекс проблему описали, задали вопрос нужно ли нам что-то менять и получили ответ нет, менять ничего не стоит, ошибка на нашей стороне, всё исправлено, процесс начнется в течение двух недель.
Так что можете меня на слове не ловить, мне с Вами в дебаты вступать не с чем ,

Да ладно, сопли вытирать, а то у Яндекса проблем никогда не было? Я вот сам сколько сайтов продвигал за 9 лет, так то морда выпадет на месяц, то 50% страниц выпадет из индекса. Пишешь Платону, а он "Ой, ну сломалось, извините, скоро всё вернется", и сидишь ждешь. А так, чтобы морда выпала у продвигаемого сайта по высокочастотнику и клиент несколько недель рвал и метал, теряя траф, так это нередко.
А Яндексу нынче вообще тяжело, его Гугл ест

Я процитировал выше. Или Вы хотите нотариально заверенный скриншот?

Если что-то уже произошло, у каждого всегда есть выбор: переживать или не переживать. Причем сами переживания, очевидно, никак на проблему не влияют, не помогают в её решении. Тогда почему многие выбирают путь бессмысленного самоистязания? Наверное, потому что нравится

Страницы обычные?
Я на одном сайте нашел с такой ошибкой только урлы типа ******.mp3

Впрочем, сейчас мы у Яндекса спросим, чтобы не гадать. Я отпишусь сразу.

Yandex.Search support

Проблема с форматом, увы, полностью связана с проблемами с нашей стороны. В настоящий момент они уже были устранены, страницы сайта в скором времени должны начать посещаться роботом и смогут появиться в выдаче с последующими обновлениями поисковых баз. Некоторые из страниц смогут появиться уже после следующих 1-2 обновлений. Обычно обновления поисковой базы происходят с частотой один-два раза в неделю. Вы можете настроить получение уведомлений об этих обновлениях на электронную почту на странице http://webmaster.yandex.ru/settings/messages/types.xml .

Приносим свои извинения за доставленные неудобства.

--

С уважением, Платон Щукин
Служба поддержки Яндекса
http://help.yandex.ru/

Гляньте в вебмастере, если есть сайты не на нашей CMS, есть такая ошибка?

Кстати, Яндекс утверждает, что это невзаимосвязанные проблемы.

Вы уверены, что страницы "переместились" те же самые, и это не другие страницы?

Что-то каша какая-то...
Модуль - это несколько файлов. Про какой именно файл Вы говорите?
Что значит "в другом месте"? Это в каком?
Это переменная, обычная строковая ячейка массива result. И поскольку она сидит в <a href="'.$result['userpage'].'"> - очевидно, что в ней содержится просто адрес на страницу пользователя, формируемый в модели.
userpage.php тут причем вообще?
Ну? Это контроллер, вызывающий show() в модельке.

Можно завести переменную, передаваемую в строке адреса, типа site.ru/userpage/?page=orders
И затем в модельке смотреть

Что ж вас всех в обход самых простых решений-то несёт?
Почему нельзя в режиме редактирования прямо на сайте карандашик поднести к нужному заголовку и поправить?

Да, форма не для авторизованного - это форс-мажор
Ну через языки тогда.

И тут самое главное, чтобы во вьюхе эти тексты были как

а не

Принцип прост, MVC. В админке чуть проще, т.к. там всё по одному принципу, поэтому там быстро у Вас получилось. А в публичной части надо побольше поколдовать, т.к. там воротить можно что угодно в свободном режиме.
Собираете простейший контроллер, в модельке запросы к БД и формирование result. И во view вывод.
Возьмите какой-нибудь простой модуль, типа news, и разберите его публичную часть. Даже склонируйте для образца. А далее метод "тыка", так быстрее запоминается

Функции называть можете как угодно, конечно. Главное, по именам их вызывать.
По Вашей function list_() можете не заморачиваться для начала с кешированием, пагинатором, а начинать с простых функций, типа .

Бред. Постят они по адресу корзины, как любые комменты, форумы и пр. Т.е. на сайт браузером бот не заходит, в прямом понимании слова, поэтому метрика не отмечает визит.

Я бы для начала поставил в корзине проверочку, перед оформлением заказа, пустой ли referer и равен ли он нашему сайту. Если там нашего сайта нет - значит это бот, т.к. нельзя оформить заказ не походив по каталогу, очевидно.

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

Такие вещи обычно решаются в частных порядках.
Капча и прочие ограничения не вариант. Тут надо творчество.
Например, на каждого пользака, в его сессию завести переменную, которая по умолчанию 0. Посмотрел человек две-три страницы минимум - переменная=1. Провел на сайте более 1 минуты - переменная=2. И самое главное, на странице корзины, время захода в корзину и время POST в аякс, сабмит формы. Человек же не может заполнить форму заказа быстрее чем за... ну 20 секунд? Не может. Если более 20 секунд и переменная=2, то тогда заказ оформляется в базу. А если нет, т.е. в сессии нет предыдущих страниц (т.е. бот зашел сразу в корзину) и на сайте менее минуты (какой же покупатель забежит, тыкнет купить и сразу оформит заказ?) и форма заказа заполняется мгновенно - это бот, можно ему сообщение "Ваш заказ принят" выводить, но сам заказ в БД не постить.