edison

Где посмотреть демо?? Для какой версии IPB скрипт?? Нужен для версии 3.4.5.

Fatal error: Call to undefined method IPSLib::makenameformatted() in /home/forum/admin/applications/forums/modules_public/forums/boards.php on line 375 Возникает только при заходе на форум. При заходе в блоги календарь и прочее нет такой ошибки все заходит, в тот же момент когда не могу зайти на форум

Что делать с постами которые не поддались обработке??? Respected А новичков с неудобными вопросами награждают баллами предупреждения потому что ответить не могут??

Точняк!!! Линух и без морды.

Даа надо подумать!! только куда там со своей ibm server 336 идти то!!! и к PROXMOXу привык и памяти дают сколь хочешь бесплатно и процессоров аж 4 ) И места полтора тера дають биплатно даж не знаю найду ли дешевле

Ага чтоб получить интернал сервер эррор!!! Он на 50ти уже вываливался!! поставил 5 за проход не вываливается!

Вторые сутки маслает перестроение сообщений, и даже до половины не дошло ( Надеюсь не придется пользоваться бэкапом Ато ждать 4-5 дней и все восстанавливать (( 200 тысяч постов у меня на форуме

Чет ума не приложу как поменять то запросом в базе или в дампе!!! А именно: data-cid="213239" data-time="1417263052 это откуда брать ??? Если в старом: div class='quotetop'>Цитата(Алёна @ May 10 2006, 11:34 AM) Самому придумывать data-time и data-cid

После обновления форма 2.3.6 посты с цитатами не правильно отображаются! В мискуле найдены такие различия: Старый вариант поста с цитатой <!--QuoteBegin-Алёна+May 10 2006, 11:34 AM--><div class='quotetop'>Цитата(Алёна &#064; May 10 2006, 11:34 AM)</div><div class='quotemain'><!--QuoteEBegin-->Бла бла бла пост <{POST_SNAPBACK}></a></div><!--QuoteEnd--></div><!--QuoteEEnd--> Новый вариант поста с цитатой <blockquote class="ipsBlockquote" data-author="edison" data-cid="213239" data-time="1417263052"><p> Бла бла бла пост </p></blockquote> Вопрос простой!! Как сделать так чтоб в постах не торчало - <{POST_SNAPBACK}> и выделялись слова процитированные от вновь сказанных???

$INFO['sql_charset'] = 'utf8'; Все так просто оказалось!!! Всего лишь надо было это добавить в старый конфиг!!!

Еще бы он ла локалхосте авторизовывался когда заходишь www.xxx.ru/forum/admin/upgrade/ Не принимает правильный пароль.

[Tue Dec 02 14:58:02 2014] [notice] mod_fcgid: process /home/svadebnoe/public_html/forum2/admin/upgrade/index.php(26982) exit(shutting down), te$ [Tue Dec 02 14:58:03 2014] [notice] suEXEC mechanism enabled (wrapper: /usr/lib/apache2/suexec) [Tue Dec 02 14:58:03 2014] [notice] Digest: generating secret for digest authentication ... [Tue Dec 02 14:58:03 2014] [notice] Digest: done [Tue Dec 02 14:58:03 2014] [notice] Apache/2.2.9 (Debian) DAV/2 SVN/1.5.1 PHP/5.2.6-1+lenny16 with Suhosin-Patch mod_ruby/1.2.6 Ruby/1.8.7(2008-$ [Tue Dec 02 14:58:11 2014] [notice] mod_fcgid: call /home/svadebnoe/public_html/forum2/admin/upgrade/index.php with wrapper /home/svadebnoe/fcgi$ [Tue Dec 02 14:58:40 2014] [notice] mod_fcgid: call /home/svadebnoe/public_html/forum/index.php with wrapper /home/svadebnoe/fcgi-bin/php5.fcgi [Tue Dec 02 14:58:46 2014] [notice] mod_fcgid: process 27532 going graceful shutdown, sending SIGTERM $n error), terminated by calling exit(), return code: 0 И это еще

Может тогда подскажете как это решить??? Ато это байда замучала уже на всех дистрибутивах испробовал на одном и том же месте одно и то же!! PHP Warning: Module 'mcrypt' already loaded in Unknown on line 0 [Tue Dec 02 11:10:32 2014] [notice] mod_fcgid: process 13547 going graceful shutdown, sending SIGTERM [Tue Dec 02 11:10:38 2014] [notice] mod_fcgid: process /home/svadebnoe/public_html/forum2/admin/upgrade/index.php(13547) exit(communication error), terminat$ Это в логах апача. А в браузере Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, [no address given] and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log. Всегда на этом месте: Invision Power Board 3.2 Добавление приложения: Система.... Добавление приложения: Форумы.... Добавление приложения: Пользователи.... Добавление приложения: Calendar.... Продолжение обновления

Рассказываю всем!!!! Мучался три дня!!! Копал весь интернет, пробовал разные способы! Вот что надо для обновления динозавра: 1. переделать базу в utf8 таким образом Первое, что нам следует сделать, это дамп базы. Снимать дамп будем не целиком TableDefinitions (TDs)+data, а раздельно. Т.е. в один файл структуру, в другой данные. Это нужно для того, чтобы не позаменять в данных проекта чего лишнего. Если, например, какой-то пользователь писал что-то про cp1251, а может быть еще и TDs-ы цитировал, мы не должны их испортить. Обратите внимание, что снимать TDs-ы надо с ключем --routines, чтобы не забыть хранимки и --triggers, чтобы триггеры оказались вместе со структурой. А вот дамп данных в свою очередь с ключем --skip-triggers, иначе получите CREATE-ы триггеров в дампе с данными. Впринципе, ничего страшного в нахождении триггеров в дампе с данными нет, но я предпочитаю отделять мух от котлет. Кроме того, если вы работаете с InnoDB таблицами, вам понадобится добавить ключ --single-transaction при снятии дампа с данными. mysqldump -uroot -p --routines --triggers --no-data yourdb > db.tds.sql mysqldump -uroot -p --skip-triggers -n -t --default-character-set=utf8 yourdb > db.data.sql Итак, у нас 2 дампа, один с TDs-ами, другой с данными. Берем любимый редактор с возможностью bulk-замены (sed, хотя, можете бить камнями, mcedit) и правим TDs-ы. Коллэйшены либо просто убить, либо заменить на utf-ные, затем все cp1251 меняем в utf8. В простейшем случае вот список замен (именно в этом порядке) для db.tds.sql: 'collate cp1251_bulgarian_ci' => '' 'COLLATE=cp1251_bulgarian_ci' => '' 'cp1251' => 'utf8' Дальше стоит обратить внимание на тип данных TEXT. Дело в том, что при конвертации из однобайтовой в мультибайтовую кодировку данные у нас распухнут и могут перестать умещаться в старых типах. Самый простой путь решения этой проблемы - заменить в TDs-ах тип данных TEXT на MEDIUMTEXT. Если же у вас исходные данные в MEDIUMTEXT, проверьте, ну нужно ли увеличить его до LONGTEXT, но это вряд ли. В деле трансляции данных из одного чарсета в другой распространен метод использования iconv-a и трансляции дампа им. Этот метод подходит, если у нас достаточно небольшой дамп (iconv использует оперативку) и если у нас идеальные данные. В реальном проекте не без помощи спамеров в базу попадает зачастую такой набор байтов, который MySQL не берется разобрать и сохраняет как получится. iconv на этом месте скажет, что с такими данными он работать не будет и ключ //TRANSLIT вам не поможет. Поэтому мы сразу при снятии дампа попросили MySQL по возможности транслировать наш дамп в utf8. Можно было оставить трансляцию на момент импорта дампа обратно, т.е. мы импортировали бы cp1251 дамп в utf базу и MySQL по уже описанному мной алгоритму сохранил бы все в utf-е. Ну а дальше самый отчаянный момент: mysql> DROP DATABASE yourdb; mysql> CREATE DATABASE yourdb DEFAULT CHARSET utf8; mysql -uroot -p yourdb < db.tds.sql mysql -uroot -p yourdb < db.data.sql Ну вот и все. Теперь у нас честная UTF-8 база. ...или почти все, если вы использовали в своих таблицах MD5 от данных. После конвертирования в UTF ваши хэши больше не совпадают со строками, из которых были получены, если в этих строках содержались символы, выходящие за рамки ASCII. Так что внимательно проверяйте таблицы и генерите MD5 заново. Но моя ошибка стоявшая двух дней заключалась в том что я заменял только cp1251, а надо было еще не забыть про latin1 которые так же были в базе у некоторых таблиц!!!! 2. Скачать какуюнибудь 3.0..... версию и обновиться до нее, а потом на более свежую )