Joomla, большая таблица jos_bannertrack и неверная кодировка на сайте

Недавно переместил свои сайты на более качественный хостинг (можете почитать статью по каким критериям я выбираю хостинг: "как выбрать хостинг" ). И вот один из сайтов на Joomla почему-то переместился так. что все русские символы отображались знаками вопроса. Естественно первое что я подумал: где-то включена неверная кодировка. После некоторой возни решил выяснить на каком именно этапе возникают знаки вопроса: посмотрел через PhpMyAdmin в базу данных на новом хостинге - в таблице jos_content есть знаки вопроса. Посмотрел на старом - в той же таблице нет знаков вопроса. Решил экспортировать базу со старого хостинга на локальный диск и посмотреть есть ли в экспортируемой базе данных знаки вопроса.

И тут я вспомнил что эту базу не с первого раза у меня получилось экспортировать. В ней таблица jos_bannertrack настолько большая, что старый хостинг не хотел отдавать сжатую базу данных, я скачивал ее без сжатия. Возникли подозрения что база данных не вся скачивается, хотя не понятно как тогда вообще сайт на новом хостинге работает.

Таблица  jos_bannertrack учитывает показ банеров и клики по ним. Имея несколько банеров и более-менее посещаемый сайт, таблица   jos_bannertrack будет достаточно быстро расти, а значит и размер самой базы. Эту таблицу можно смело очистить (не удалить, а очистить), что я сразу и сделал:

Joomla - bannertrack

В столбце "строки" в этой таблице у меня было очень большое значение. После очистки экспортируемая база данных уменьшилась в 10 раз: с 60 Мегабайт до 6. Эту, уже небольшую, базу данных я снова импортировал на новый хостинг и... Сайт на новом хостинге стал отображать свое содержимое без знаков вопроса.

Как же отключить это отслеживание банеров? Следующий скриншот вам это подскажет:

Joomla - банеры 0

Joomla - банеры

Понравилось? =) Поделись с друзьями:

Обсуждение записи “Joomla, большая таблица jos_bannertrack и неверная кодировка на сайте”

  1. Виктория (trafficlightstudio.com.ua) says:

    Спасибо, ваша статья очень помогла. Та же проблема была обнаружена в процессе очередного экспорта базы данных для резервной копии. В связи с тем что таблица jos_bannertrack содержала очень большое количество значений, а именно 1 167 983, в связи с этим время генерации dump-a превышало 60 сек, поэтому экспорт не выполнялся.

  2. Владимир Демянович (elims.org.ua) says:

    Пожалуйста =) Рад что кому-то пригодилось) А каких мне это стоило умственных мучений, что бы догадаться о истинной причине неверной кодировки) Помню тогда повозился с кодировками, и так и сяк заливал базу пока не понял что причина в другом =)

  3. Маргарита (a-expert.kiev.ua) says:

    В моем случае таблицы экпортировались пустыми. Не знаю что и делать. Может подскажите как это исправить плиз!

  4. Владимир Демянович (elims.org.ua) says:

    Если у вас также включен bannertrack, то сделайте то, что описано в статье. Если же причина другая — к сожалению вряд ли подскажу что делать. Можете посмотреть в phpMyAdmin которая из таблиц подозрительно большая и выяснить за что она отвечает и кто виноват.

  5. Маргарита (a-expert.kiev.ua) says:

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

  6. Валентин (valentin.abc-4.com) says:

    Подскажите как почистить базу в ЦМС Думла на сайте.

Обсудить