Если эта кука должна сохраняться в поле ref в таблице user то вот эту строку
mysql_query("INSERT INTO `user` (`login`, `password`, `email`, `name`, `parent`, `class`, `level`, `exp`, `hp`) VALUES ('{$_POST['m_login']}', '".md5($_POST['m_password'])."', '{$_POST['m_email']}', '{$_POST['m_name']}', '{$_POST['parent']}', 'a', 0, 0, 99)");
замените на
mysql_query("INSERT INTO `user` (`login`, `password`, `email`, `name`, `parent`, `class`, `level`, `exp`, `hp`,`ref`) VALUES ('{$_POST['m_login']}', '".md5($_POST['m_password'])."', '{$_POST['m_email']}', '{$_POST['m_name']}', '{$_POST['parent']}', 'a', 0, 0, 99,'$_COOKIE[ref]')");
LEOnidUKG прав. SQL - это отдельный язык, отдельная архитектура, или даже, если хотите, философия. С ним не начинают работать так "с наскока". Если вы с ним не знакомы, найдите хорошую, основательную книжку (а лучше несколько), где не только описываются команды и их синтаксис, а преподаётся теория, начиная с азов реляционных баз данных. Стоит выделить на его изучение значительное время. Потом это окупится.
Ваша правда, ошибся.
При продолжительном листании, несколько секунд на страницу могут так проесть печёнку...
Это не шутка, это из личного опыта. Я делал сайты без неоптимизированных картинок, и когда задумывался, не сделать ли сайт в UTF-8, то я взвешивал плюсы и минусы. Плюс: если на сайте будет текст на каком-то другом языке... Но его там не будет! Минус: в два раза больше объём данных, и для передачи (трафика) и для хранения в базе данных. А больший объём в базе данных - это и чуть менее быстрая её работа.
Это зависит от специфики сайта. Вот этот форум, к примеру, не содержит очень много картинок, и специфика его работы такова, что огромное количество его страниц с одними и теми же картинками просматривает ограниченная постоянная аудитория. В результате, после первого посещения, все картинки кешируются в наших браузерах. А потом, на протяжении лет, и миллионов просмотров страниц, мы качаем сугубо текстовый трафик. Но сейчас, когда у нас много-мегабайтовые безлимитные каналы, нам на это плевать. А в эпоху модемов 14400кб и платы по счётчику - это имело значение.
А у китайцев не буквы :p
Кроме того, ASCII с американцами имеют мало отношения к заданному вопросу. UTF-8 была разработана в 1992 году. Почему же до сих пор огромное количество интернет-сайтов работает на национальных кодировках, учитывая, что подавляющее большинство из них были построены или кардинально перестроены когда UTF-8 уже надёжно поддерживалась браузерами? О чём могли думать эти миллионы вебмастеров, если не о скорости загрузки их страниц?
Придумали! Она называется: UTF-8. Предвижу следующий вопрос: зачем придумали все остальные кодировки? :-) Дело в том, что раньше (в прошлом веке) компьютеры были слабенькие, каналы связи - тоненькие, ну в общем, всё было плохо, и приходилось экономить. Для того, чтобы можно было показать в одной кодировке все возможные буквы всех земных алфавитов, требуется по 2 байта места на каждую букву. А если задаваться целью показать только два алфавита (русский и английский, например), то достаточно одного байта на букву. Вот и представьте, если когда-то в прошлом веке страница, размером в 1 килобайт грузилась в браузер минуту, а страница в два килобайта - две минуты. Захотели бы вы заставлять пользователя ждать загрузки вашей страницы лишнюю минуту ради того, чтобы у вас была возможность, если когда-нибудь понадобиться, написать словечко по японски?
С кодировками в MySQL важно понимать следующее: кодировка, она же charset, она же (почти) Collation - задаётся на уровне полей. Кодировка таблицы - это кодировка "по умолчанию", которая будет использована при добавлении в таблицу нового поля, если не будет указана его кодировка в явном виде. Так же, кодировка базы данных - это кодировка по умолчанию, которая будет использована в качестве кодировки таблицы, при создании таблицы, если при этом не указывается другая кодировка. Поэтому удобно и правильно - задать нужную кодировку сразу после создания базы данных (пока она пустая). Тогда дальше (при добавлении таблиц) можно будет о ней не задумываться.
Важно чтобы кодировка полей базы данных соответсвтвовала кодировке ваших интернет-страниц. То есть, к примеру, если вы создали базу данных в UTF-8, то следите за тем, чтобы во-первых, ваш текстовый редактор, которым вы редактируете PHP-скрипты, сохранял файлы в этой же кодировке, и во-вторых, чтобы в разметке этих страниц указывалось: <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> или <meta charset="utf-8" /> для HTML5.
Ещё есть кодировка сервера, и кодировка соединения. В обычном случае, когда речь идёт об использовании шаредного хостинга, у вас нету возможности установить эти величины по умолчанию. И если они на сервере не установлены в UTF-8, то вам нужно добавить одну строчку кода в то место, где у вас устанавливается соединение с базой данных, то есть примерно после строки, содержащей "mysql_connect", нужно добавить строчку:
mysql_query('SET NAMES utf8');
То есть, не перед каждым запросом, а один раз после установки соединения с базой данных.
Уверяю вас, при современных вычислительных мощностях - это ерундовая нагрузка. Если будете реализовывать, я бы советовал запоминать для каждого пользователя номер последнего прочитанного им сообщения в каждой теме. Так сделано в SMF, и он отлично с этим справляется в довольно посещаемых форумах, и это очень удобно для пользователей. Просто "новые сообщения с последнего визита на форум" - мало что даёт. Может я вчера спешил, заглянул в одну темку, а сегодня не спешу, и хочу обстоятельно прочесть всё, что ещё не прочёл, но этот форум мне пометит новыми только темы, изменившиеся со вчера, хоть я может остальные 100 тем не прочёл. Обидно :(---------- Добавлено 16.07.2012 в 06:45 ----------Расскажу о своём опыте реализации движка форума. Извиняюсь за длинный текст. Кому не интересно, прошу не тратить время на прочтение.
Когда-то давно, как я упоминал, я активно общался на одном форуме. В те времена не было фейсбука, "одноклассников" и "в контакте", и люди общались в форумах. Многие (в т.ч. я) сидели на форуме часами, переходя из темы в тему. Пока напишешь что-то в одной теме, в другой уже появились новые сообщения. И, к стати, очень удобно было, что такая тема помечалась, хотя у меня длился всё тот же сеанс посещения форума.
Линии интернета были тогда узкими, страницы грузились очень долго. Порой весма раздражало, что приходислось по целой минуте ждать заргузки длинющей страницы, в которой появилось одно новое сообщение в 2 байта: "+1". И тогда я решил написать свой движок форума. Я задумался, и изобрёл две вещи: аякс, и голосования. Знаю, что это звучит смешно, и на самом деле аякс изобрёл конечно не я. Но термин аякс ввели в 2005 году, а дело было примерно в 2003. Тогда не было (хотя может и было, но я не искал) стандартных JS-библиотек для работы с аяксом, да и стандарта для XmlHttpRequest не было, был только проприетарный микрософтофский синтаксис работы с ним, и 99% рынка браузеров занимал IE. Поэтому я написал клиентскую сторону движка под IE, и форум работал только в нём.
Когда посетитель заходил на форум (начинал сеанс), открывал тему, то для него загружались 10 последних прочитанных им сообщений в этой теме + все непрочитанные. Все эти сообщения сохранялись в памяти его компьютера, в формате XML, в течение сеанса. Если он переходил в другую тему, а затем, когда в первой добавлялись новые сообщения, возвращался в неё, то с сервера подгружались только эти новые сообщения, и пользователю снова показывались 10 уже прочитанных (из памяти) + новые (с прокруткой к первому новому).
Что касается голосований, речь идёт не о темах-голосованиях, а о голосованиях за и против каждого сообщения. Сейчас похожая система, с голосованием за коментарии, реализована в большом количестве проектов, начиная с хабра. Но в отличие от коментариев, сообщения форума не сортировались по количеству голосов. Количество проголосовавших за сообщение (как бы, поддерживающих мысль, присоединяющихся), и против (возражающих, протестующих), указывалось в види миниатюрной графической диаграммы (двумя цветными дивами) под каждым сообщением. Это позволяло избавиться от таких неинформативных новых сообщений, как "+1" или "чушь". И если пользователю давали, к примеру, совет, то он мог легко увидеть, сколько людей одобряют этот совет, а сколько протестуют против него. И эти одобрения и протесты делались легко, одним кликом.
К сожалению, у меня не хватило запала переработать этот движок для кросс-браузерности, и я его бросил. Сейчас можно глянуть на него (только в IE) на одном, тоже брошеном, сайтике: http://bela-massage.info/forum/ . Если интересно, попробуйте открыть одну длинную тему, потом вторую, а потом вернуться в первую, и обратите внимание, сколько времени уйдёт на её показ.
post_title будет воспринято как имя поля таблицы, потому что оно заключчено в косые кавычки ``. Можно и без них, главное чтобы без одинарных или двойных ковычек. Для каждой строки будет взято значение из поля post_title, и подставлено вместо строки 'это заменится на заголовок' в тексте, находящемся в поле post_content этой же строки. Советую сделать копию таблицы, попробовать на ней, посмотреть что получится. Если то, что надо, тогда уже запускать на реальной таблице.
Вообще-то можно это сделать и SQL-запросом, без регулярных выражений. Дамп-то в любом случае сделайте, на случай если ошибёмся, и что-то не то заменится.
UPDATE wp_post SET post_content = CONCAT(LEFT(post_content,LOCATE('\n<b><u>Скриншоты:</u></b><br />\n',post_content)),RIGHT(post_content,LOCATE('<br /><br />',post_content,LOCATE('\n<b><u>Скриншоты:</u></b><br />\n',post_content))+12)) WHERE post_content LIKE '%\n<b><u>Скриншоты:</u></b><br />\n%'
В первом, более простом варианте, тоже всё должно работать. Там тоже двумерный массив. Просто с синтаксисом вывода проблемка, как уже K_V_S указал.
