xPoint

Да точно. Забыл. Сенкс, что напомнил. Тогда единственной проблемой может быть выборка(содержимое таблицы, сам запрос). Т.е. без дампа таблицы и вывода значения переменных не разобраться.

Тут скорее всего нужно mysql_fetch_array заменить на mysql_fetch_assoc. Или при выводе написать индекс обычного массива.

Здесь наверняка подойдет запрос с использованием JOIN

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

1. до первой 2. не подскажите сколько будет обрабатываться через цикл for строка из миллиона символов? 1. Эх, маловато. Обычно нормализуют до 3-й. Я вот недавно делал правки для одного сайта, так там база не до конца номализована была. Валютные пары в подписках были представлены в таком виде ::EURUSD::USDGPB::, способ получения (email, icq, sms) в таком же виде. По хорошему их нужно было разнести на несколько отдельных таблиц (para, subscribe2para и т.д.), потому что поиск с помощью LIKE очень неплохо нагружает базу. Нормализация обычно зависит от самих таблиц. Если у вас больше нечего нормализовать, то это очень хорошо! 2. Я не это имел ввиду. Простой пример для вас $utf_string = 'Это строка в утф'; $cp_string = mb_convert_encoding($utf_string, 'windows-1251', 'utf-8'); //display Windows-1251-string for($i=0;$i<strlen($cp_string);$i++) echo $cp_string[$i].' '; echo '<br/>'; //display UTF-string for($i=0;$i<strlen($utf_string);$i++) echo $utf_string[$i].' '; Выводит вот такую белиберду: И даже если выбрать кодировку в браузере, утфная строка не отображается корректно. Как считаете почему так происходит?

1. Я рад, что база хорошо нормализована. Позвольте полюбопытствовать, до какой нормальной формы? 2. Врядли. Потому что размер данных разный.

К сожалению, не могу. Она разрабатывалась не для публичного использования, а скорее для личного изучения принципов построения таких систем. Если хотите посмотреть на удачные системы, то лучше возьмите самые популярные сейчас: Wordpress, Joomla!, Drupal, DLE, MODx и др.

Я тоже черкану пару строк на эту тему, потому что сам когда-то страдал таким делом. 1. Функция serialize как было сказано выше плоха тем, что она медленная. PHP вообще намного медленнее бд в плане поиска и сортировки данных. Я бы вам посоветовал отказаться от использования этой функции. Даже в админке. Пользователь не станет устанавливать себе движек у которого глючит админка. По крайней мере, я бы не стал. Кроме того, хотелось бы услышать, в каких именно моментах вы используете эту функцию. Может быть у вас не нормализована бд и если вы об этом слышите впервые, то советую внимательно изучить эту тему прежде чем начинать создавать что-то свое. 2. Универсальности нигде не существует в мире. И в программировании тоже. Я бы посоветовал здесь делать оба способа отправки почты, потому что на одном хостинге может быть SMTP-сервер, а на другом нет и придется отправлять почту через ф-цию mail. Если не знакомы с SMTP, то можете почитать цикл моих статей на эту тему. 3. Кроме mb_string таких действий как mb_substr и mb_strpos с утф больше никакие функции PHP не умеют делать. Где-то слышал, что PHP хотят полностью перевести на утф и все строковые функции будут работать исключительно с утф. Но это только слух и пока-что в этой области нет никаких конкретных решений. Занесите это в системные требования и не парьтесь по этому поводу. 4. Вопрос не в количестве. А в качестве. Один запрос может повесить всю вашу базу данных на несколько секунд, поэтому старайтесь внимательно подходить к созданию таблиц и составлению запросов. Кроме того, посоветую не страдать универсализмом. Лучше подумайте над тем, какие задачи (т.е. для каких сайтов) будет решать ваша CMS и двигаться в этом направлении. Если же вы хотите сделать CMS, которая сможет подойти для любых сайтов, то вам над такой системой придется трудиться лет 5 или больше. А к тому времени технологии изменяться и ваша система будет отсталой и устаревшей. И вам опять придется переделывать весь движек, чтобы соответствовать современным технологиям, а пока вы будете переделывать.... И так до бесконечности.

Делается это следующим образом: $subject = '=?'.strtolower($charset).'?B?'.base64_encode($subject).'?='; где $charset - название кодировки, а $subject - сама тема.

А вы уверены, что форма отправляется при нажатии на ссылки?

значение нода id в index.php и номер в массиве one_com при удалении могут быть различными. При удалении нужно искать запись у которого нод id равен тому что передано по гет.

но это только если в качестве хостинга используется виндовс. У меня в линуксе все пошло как надо, без лишних проблем. И загрузка и запись в базу.

Вопрос, как я понимаю, в этом COLLATE=utf8_general_ci; Для кириллицы нужно ставить utf8_general_ci. И в filename тоже.

<form action="урл куда нужно перейти"> <input type="submit" name="wp-submit" id="wp-submit" class="button-primary" value="Назад" tabindex="100" /> </form> можно еще с помощью обработчика js ловить нажатие на кнопку и отправлять куда нужно.

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