Jump to content

Элека

Псы Войны
  • Content Count

    1,113
  • Joined

  • Last visited

  • Days Won

    3

Элека last won the day on September 20 2015

Элека had the most liked content!

Community Reputation

4 Обычный

1 Follower

About Элека

  • Birthday 10/15/1966

Контакты

  • Сайт
    http://http://ru-design.net/

Информация

  • Пол
    Женский
  • Город
    Обнинск

Recent Profile Visitors

5,436 profile views
  1. В ближайшую субботу (28 мая) Стрижи и Русские витязи выступают в Екатеринбурге (только что анонс вывешивала): http://www.strizhy.ru/page.php?cont=2 Так что всем, кто может добраться - настоятельно рекомендую сводить детей или внуков, да и самим посмотреть - масса впечатлений гарантирована. Следующее выступление через неделю, тоже в субботу 4 июня, где-то рядом с Феодосией, на полигоне Чауда, в рамках Авиадартс 2016. Точное время выступления самих Стрижей и Русских витязей в обоих случаях не знаю - не смогла Диме дозвониться, они рано завтра вылетают и он уже, похоже, дрыхнуть отвалился. У них сейчас такой график, что какую-то инфу вытащить - просто нереально. Ну не могу удержаться! Берт, тихой сапой влезщий на Су-35
  2. Всем привет. Заработались мы совсем, только с одним разгреблись, как нам в конце марта подкинули работу: сайт и вся рекламная сувенирка для пилотажной группы МиГ-29 Стрижи. Берт вообще порой по 2 часа спал, бедолага. Ну, вот, к официальному празднику закончили: http://www.strizhy.ru/ Инфы пока мало - ребята жутко заняты начиная с середины апреля, от них недопросишься ничего, так что заполнять ещё долго будем. Ну и конечно, в этом раскладе не съездить на праздник 25-летия Русских витязей и Стрижей на Кубинку в эту субботу мы просто не могли. Сегодня к вечеру я достаточно оклемалась, чтобы впечатления записать, ну и немножко фоток, в качестве иллюстрации. Кому интересно: http://anka-t.livejournal.com/34013.html
  3. Ещё раз: кодировка данных, пересылаемых в форме, если жёстко не прописана в файле коннекта отдаётся на усмотрение браузера. А в нём могут быть и настройки по умолчанию - разные для всех, и настройки пользователя. То есть данные отправляются как Бог на душу положит. Для вставки сообщений это не важно абсолютно, т.к. в базе сопоставление прописано всегда. А вот сравнение моего ника на русском, переданное в соответствии с установками браузера и неперекодированное системой в желанный формат никогда этот ник не найдёт, что мы и наблюдаем сейчас. Без этого такая дрянь будет у кого-то твориться постоянно: mysql_query('SET NAMES utf8', $connid); mysql_query('SET character_set_client = utf8', $connid); mysql_query('SET character_set_connection = utf8_general_ci', $connid); mysql_query('SET character_set_results = utf8', $connid); И если скрипты используют библиотеку iconv, а, скорее всего, это так, то проверьте наличие ещё и этого: iconv_set_encoding('internal_encoding', 'UTF-8'); iconv_set_encoding('input_encoding', 'UTF-8'); iconv_set_encoding('output_encoding', 'UTF-8'); Учите мат-часть, многое станет понятнее
  4. А я опять повторяю, что после этого залогиниться невозможно, я каждый раз захожу на форум только после сброса пароля. Думаешь я сразу не пыталась зайти какЭлека вместо Anka? И про кодировки я писала не просто так: пока логин и пароль были английскими, проблем не было.
  5. Всё не так просто: система разрешает создавать аккаунт под уже существующим логином. Кроме того, необходимость постоянного сброса пароля, по крайней мере у меня, никуда не делась. Если вхожу из иного браузера, чем в прошлый раз, приходится сбрасывать пароль снова. При этом, пароль всегда один и тот же.
  6. Поскольку форум сделан под стандарт HTML 5.0, то он просто может быть ещё сырым, то есть дело может и не в косяках переноса. Мой первый аккаунт, созданный хз сколько лет назад имеет логин Anka. После обновления скрипта, пока я не логинилась при входе, а заходила по cookies, хранящимся в браузере, всё было прекрасно. Причём, все мои сообщения отображались под ником моего перса - Элека, заданным в настройках моего аккаунта. То есть все старые данные успешно в новую базу переехали. Как только я удалила cookies, при попытке авторизации мне было заявленно, что такого логина не существует, но это явно не так, почему - уже объясняла. При этом (ВНИМАНИЕ!) я без проблем зарегистрировала новый акк на тот же логин. И некоторое время им попользовалась - логингилась неоднократно, ибо разные системы. Как только Ирди написал, что нашёл мой старый акк и отправил мне ссылку для восстановления пароля - я уже в следующий раз не смогла залогиниться, причём, с тем же самым сообщением, об отсутствии искомого логина в базе. Это наводит на мысль, что такое сообщение получается не только в результате отсутствия нужной записи, но и в случае её дублирования в таблице пользователей. А это не просто плохо, это - очень плохо! Поэтому, предлагаю вам проверить эту самую очевидную версию. Заходите в phpMyAdmin, смотрите как называется там основная таблица с данными пользователей. Я для примера создала 2 таблички. Первая - правильная, как должно быть. CREATE TABLE IF NOT EXISTS `USER_M` ( `id` int(5) unsigned NOT NULL AUTO_INCREMENT, `login` varchar(25) NOT NULL DEFAULT '', `pass` varchar(25) NOT NULL DEFAULT '', `nm` varchar(25) NOT NULL DEFAULT '', `email` varchar(25) NOT NULL DEFAULT '', `tm` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `login` (`login`), UNIQUE KEY `nm` (`nm`), UNIQUE KEY `email` (`email`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8 COMMENT='Ссылки'; Вторая - неправильная, если моё предположение верно, то так есть сейчас: CREATE TABLE IF NOT EXISTS `USWER_I` ( `id` int(5) unsigned NOT NULL AUTO_INCREMENT, `login` varchar(25) NOT NULL DEFAULT '', `pass` varchar(256) NOT NULL DEFAULT '', `nm` varchar(25) NOT NULL DEFAULT '', `email` varchar(25) NOT NULL DEFAULT '', `tm` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='Юзеры' AUTO_INCREMENT=1; INSERT INTO `USWER_I` (`id`, `login`, `pass`, `nm`, `email`) VALUES (1, 'Anka', 'pass', 'Элека', 'anka-tg@ya.ru'), (2, 'Bert', 'pass', 'Берта', 'golovan19@ya.ru'), (3, 'Anka', 'pass', 'Элека', 'anka-tg@ya.ru'), (4, 'Bert', 'pass', 'Берта', 'golovan19@ya.ru'), (5, 'Anka', 'pass', 'Элека', 'anka-tg@ya.ru');где нам критичны 4 поля: login - это, собственно логин юзера, email - понятно и nm - это ник перса, под которым отображаются записи на форуме, `tm` - дата создания записи. Посмотрите, как эти поля называются в вашей базе. Возможно, что ники персонажей в вашей базе хранятся в другой таблице, тогда смотрите пока только логин и емейл и дату. Теперь смотрите вкладку "структура" у себя, что за ключи есть в вашей таблице? Должно быть (с учётом ника перса) 4 ключа, каждый из них уникальный. Если у вас так, то можно вздохнуть с облегчением, но тогда непонятно, откуда взялись проблемы. Стоит проверить то, что написано в самом конце данного поста. Если у вас не так, и в табличке ключей нет логина, емейла и ника, то проблему мы нашли. Как её решать в этом случае? В теории в той же вкладке в самой структуре таблицы надо для всех нужных полей, как-то, логин, емейл и имя перса выставить флаг уникальности, это кнопка с буковкой "U" в строке с данного поля структуры таблицы. Но, если записи в этом поле уже продублированы, то MySQL это делать откажется и вы получите такое сообщение: #1062 - Duplicate entry 'Anka' for key 'login'Естественно, первым продублированным логином совершенно не обязательно будет Anka Поэтому, сначала надо избавиться от дублей, для чего нужно как минимум их вычислить. Это делается так - топчем в верхнем меню вкладку SQL и кидаем в окошко следующий запрос: SELECT `id`, `login`, count(*) FROM `USWER_I` GROUP BY `login` HAVING count(*) > 1Естественно, `id`, `login` вы меняете на свои названия соответствующих полей, а имя таблицы пользователей `USWER_I` - на своё. Получаем список логинов, которые продублированы, в моей табличке это соответственно Anka и Bert Теперь нужно вытащить список идентификаторов записей, которые продублированы: SELECT `id`, `login`, `tm` FROM `USWER_I` WHERE `login` IN ('Anka', 'Bert') ORDER BY `login`Будьте внимательны при составлении списка логинов, который в скобках: должны быть перечислены все имеющиеся в ответе базы логины, по одному разу, каждый логин строго должен находиться в своих одиночных кавычках (не путать с кавычками, обрамляющими имена таблиц и полей, которые вводятся вместо буквы Ё в английской раскладке!), именно так, как в моём запросе. Получаем список дублированных записей, у меня это 1, 3, 5, 2, 4. Теперь нам нужно удалить лишние, но сначала надо определиться, какие из них лишние... Сначала смотрим дату: все записи, котороые переехали из оригинальной базы, имеют одну и ту же дату. Оставляем, естественно, их. Хуже, если старых записей несколько, то есть они были продублированы при переносе. Тогда нужно смотреть, к какому идентификатору привязаны сообщения на форуме. Если только к одному для этого логина - оставляем его, если к разным - то, либо где их больше, либо где они более поздние по дате, но, давайте пока не умножать сущности сверх необходимого и предоложим, что проблема именно при переносе возникла (ведь на старом форуме таких проблем не было) и либо, записи под данным ником так же продублировались, тогда их число будет совпадать и оставлять нужно первый идентификатор, удалив остальные, либо они будут отнесены только к одному идентификатору таблицы пользователей, тогда оставлять тот, что с записями. Запрос к таблице записей для этого будет выглядеть как-то так: SELECT COUNT(*) FROM SELECT `имя_поля_с_идентификатором_записи` FROM `имя_таблицы_с_сообщениями` WHERE `имя_поля_с_идентификатором_пользователя_в таблице_записей`=`имя_поля_с_идентификатором_пользователя_в таблице_пользователей` Если результат запроса 0, то добавляем в список удаляемых именно этот ID. В результате, команда на удаление будет выглядеть так: DELETE FROM `USWER_I` WHERE `id` IN (внутри скобок - список ID через запятую и пробел, без каких-либо кавычек)Не забудьте использовать своё имя таблицы пользователей и имя ячейки с идентификатором. После удаления лишних записей вы сможете выставить флаг уникальности для ячейки с логином. После этого в списке ключей должен появиться ещё один уникальный ключ с именем поля, содержащего логин. Впрочем, если можно просто склеить данные, как было сделано для моего аккаунта, то всё становится несколько проще. Ту же самую процедуру полностью нужно проделать для емейла и имени перса... Если же ключи правильно были определены как уникальные, то причина, по-видимому, кроется в кодировках. Дело в том, что для работы с utf-8 необходимо кроме определения кодировки в тексте страниц и в базе ещё и задавать её в параметрах коннекта. Для этого ищите где в вашем скрипте лежит файл коннекта (искать нужно текстовое соответствие следующего вида: mysql_connect) и после следующей команды mysql_select_db должен наличествовать следующий набор команд: mysql_query('SET NAMES utf8', $connid); mysql_query('SET character_set_client = utf8', $connid); mysql_query('SET character_set_connection = utf8', $connid); mysql_query('SET character_set_results = utf8', $connid); где $connid - имя переменной с вашим коннектом к БД, которая создаётся и к которой приравнивается результат выполнения первой команды - mysql_connect. В данном контексте utf8 - именно так, без дефиса. Для западно-европейских языков отсутствие этих команд ничего не изменит, поэтому, если скрипт разрабатывался "там", то этих команд, скорее всего, не будет, а вот для остальных языков, включая русский, способно вызвать серьёзные проблемы. Так что настоятельно рекомендую проверить их наличие в любом случае.
  7. Спасибо. Можно небольшой совет, от человека, съевшего собаку на сложных запросах к MySQL?
  8. Не, Ирди, скорее всего, поскольку регилась на форуме я лет 10 назад, там емейл с мэйл.ру, anka-t@mail.ru которым я давно не пользуюсь, там стояла пересылка на мой нормальный мэйл на Яндексе, но из-за неиспользования ящик сдох, а для восстановления они просят больше инфы, чем я могу предоставвить и я на него уже года 3 как забила. Я тебе на фейсбуке свой мейл скинула, вот на него можно ссылку кинуть
  9. Ирди, не смеши мои тапочки. Эсли непонятно - это Элека. Ты в серьёз предполагаешь, что я пароль забыла? Я регулярно перелогинивалась из 2х разных систем своего компа, плюс другие устройства. Не говоря уже о том, что мну те же самые (естественно) логин+пасс на ДКП, где они прекрасно работают с момента разделения авторизации. Просто когда вы заменили форум я какое-то время не заходила из рабочей системы на форум. А в Хроме игровой системы авторизация была запомненна. Как только я по техническим причинам сбросила настройки Хрома игровой системы - попасть на форум больше не смогла. У Берта было то же самое абсолютно. То же самое было у Ивельки. Система не знает моего логина как явления. Думаю, вы там можете посмотреть, к какому реальному ID юзера и, соответственно, логину, привязаны сообщения Элеки. И сделай мне, плз, доступ к Псам и в офицерку, а то я только открытые разделы вижу. P.S. И - да, я, ессно, пыталась войти и под ником Элека, на случай если при конвертации ники с логинами перепутались. Логина Элека система тоже не знает.
  10. Дочь болеет, ей хелп нужен, так что мы к ней едем и нас не будет.
  11. Довольно оригинальная картина: пока браузер держит кукисы с сайта, заходишь без проблем. Стоит скинуть настройки браузера, разлогиниться, поставить новый и т.д. - всё, пишет, что с данным логином не связана ни одна учётная запись. Так что о каком-то восстановлении пароля тут говорить не приходится. Пришлось региться заново.
  12. Я буду, Берт - нет. У него осеннее обострение, он нервный
  13. Сегодня опоздаю, надеюсь в пределах получаса.
  14. Я буду к началу, Берт опоздает на час примерно.
×
×
  • Create New...