PHP: После переноса сайта на новый хост регексп не работает. #523024

Проверяет регистрационное имя пользователя, раньше регисрировались спокойно таким макаром: "Петров_Петр" Не срабатывает где-то тут: # Only allow a basic set of characters if ( 0 == preg_match( config_get( 'user_login_valid_regex' ), $p_username ) ) { return false; } user_login_valid_regex описано как: $user_login_valid_regex = '/^[w -]+$/'; Где ковырять??? Пробовал: $g_user_login_valid_regex = '/^[w -_А-Яа-я]+$/'; Не срабатыввает :( в PHP можно сказать кофейник...

Вспоможите плиз?

попробуй добавить в конце регулярки (u): '...$/u'

вот так: $g_user_login_valid_regex = '/^[w -_]+$/u/'; Правильно?

Не срабатывает. Попробовал пару вариантов...

+ такое не поможет? To support large Unicode ranges (ie: [x{E000}-x{FFFD}] or x{10FFFFF}) you must use the modifier '/u' at the end of your expression. и какой рандж для русского? Этот? 0400-04FF

после модификатора 'u' не надо '/' Проблема только с кириллицей али как?

'/^[w -_]+$|i' ?

так тоже пробовал.может кешь. походу только с кирилицей. раньше мантиса работала на php 4, но для нового сайта хост перевели на PHP5 и конвертанули сорцы в utf-8. Юзер попросил меня поменять мыло, я полез и нарвался на то что "Петров_Петр" уже не проходит. Лазил по хосту в поисках php.ini чета не нашел...

Я вечером поробую, щас работа горит :( Спасиб.

после модификатора 'u' не надо '/' Я думал регулярка должна заканчиваться '/' ..

к чему непонятные коды, работает все с понятными символьными наборами? $g_user_login_valid_regex это то что возвращает config_get( 'user_login_valid_regex' ) ? Конвертировали сырцы, а база в какой кодировке? Ты уверен, что проблема в регулярке, наставляй всяких echo. она заканчивается /, затем модификаторы

ааааа если только с русский проблема

>> $g_user_login_valid_regex это то что возвращает config_get( 'user_login_valid_regex' ) ? Сложно ответить однозначно, но config_get вызывает такую функцию:    function config_get_global( $p_option, $p_default = null ) {        if ( isset( $GLOBALS['g_' . $p_option] ) ) {            $t_value = config_eval( $GLOBALS['g_' . $p_option] );            if ( $t_value !== $GLOBALS['g_' . $p_option] ) {                $GLOBALS['g_' . $p_option] = $t_value;            }            return $t_value;        } else {            # unless we were allowing for the option not to exist by passing            #  a default, trigger a WARNING            if ( null === $p_default ) {                error_parameters( $p_option );                trigger_error( ERROR_CONFIG_OPT_NOT_FOUND, WARNING );            }            return $p_default;        }    } Можно ответить - да, но сори, я тупой 1С ник уверен на 95 % не на 100.

Шас буду материться. ползая по фтп увидел, что там 2 каталога с мантисами и блин ПРАВИЛ не в ТОЙ!!!

_test.php <?php    require_once( 'core.php' );    echo config_get( 'user_login_valid_regex' ); ?> Вывод: /^[w -]+$/

->

_test.php <?php if (preg_match('/^[А-Яа-я]+$/u','Вася')) echo 'true'; else echo 'false';   ?>

true

твое <?php if (preg_match('/^[w -_А-Яа-я]+$/u','Петров_Петр')) echo 'true'; else echo 'false';   ?>

<?php    require_once( 'core.php' );    $temp_user_login_ = 'Вася_Петров';    echo config_get( 'user_login_valid_regex' );    echo '<br>';    if (preg_match('/^[А-Яа-я_]+$/u',$temp_user_login_)) echo 'true';        else echo 'false';                      echo '<br>';    if (preg_match(config_get( 'user_login_valid_regex' ),$temp_user_login_)) echo 'true';        else echo 'false';      echo '<br>';    if (preg_match('/^[w -_]+$/u',$temp_user_login_)) echo 'true';        else echo 'false';   ?> Вывод: /^[w -]+$/ true false false

true

значит проблема в w или пробел надо экранировать, не помню. Так должно работать: '/^[ -_a-zA-Zа-яА-Я0-9]+$/u'

<?php    require_once( 'core.php' );    $temp_user_login_ = 'Вася_Петров';    echo config_get( 'user_login_valid_regex' );    echo '<br>';    if (preg_match('/^[А-Яа-я_]+$/u',$temp_user_login_)) echo 'true';        else echo 'false';                      echo '<br>';    if (preg_match(config_get( 'user_login_valid_regex' ),$temp_user_login_)) echo 'true';        else echo 'false';      echo '<br>';    if (preg_match('/^[w -_]+$/u',$temp_user_login_)) echo 'true';        else echo 'false';      echo '<br>';            if (preg_match('/^[w -_А-Яа-я]+$/u','Петров_Петр')) echo 'true';        else echo 'false';           ?> Вывод: ?/^[w -_А-Яа-я]+$/u true true false true

смотри,  if (preg_match(config_get( 'user_login_valid_regex' ),$temp_user_login_)) echo 'true'; << Срабатывает в true       else echo 'false';   А вот в мантисе ошибка так и осталась О_о. Может кеш какой????

а вот я (почти)тупо пихаю в БД логин и все :) и даже "№"№;% цуке 2345 6ецу кАУЦЙК е прокатывает

а пасс - это sha1 пароля с солью, так что мне вообще на него покласть

так где ошибка то, в регулярке или дальше, например при сравнении значения со значением в БД? Ты 'u' в мантис добавил?

хозяин-барин, бывает его и выводят не парясь с тегами некоторые.

Да, это в config_defaults_inc.php была настройка. И всеравно фигня, не пашет О_о

а теперь вылазиит: SYSTEM WARNING: Cannot modify header information - headers already sent by

я использую свой велосипед - там не страшно

что за бредовое выражение /^[ws-_А-Яа-я]+$/ ? букова У решает как сказано, но выражение менее бредовым не становится

php -v сделай, погляди версию, если 5.3.0+, то там убрали и порезали кучу функций, регексп в т.ч.

шО? наобороот, добавили нужные штуки типа лябда функций, позднего связывания и прочего. хотя для 1сника это все пустой звук, да.

После обновления версии php до 5.3.x все  сайты покрылись ошибками: 1. date It is not safe to rely on the system's timezone settings.. 2. Function eregi is deprecated in.. 3. Deprecated: Function session_register is deprecated in Date, так же как и все функции так или иначе работающие с датой выдают ошибку: Error: date [function.date]: It is not safe to rely on the system's timezone settings. Please use the date.timezone setting, the TZ environment variable or the date_default_timezone_set function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Moscow' for 'MSK/3.0/no DST' instead (_файл_, _строка_)

По вопросу с ereg (eregi), разработчики php решили что это очень медленная функция и приняли решение убрать её совсем, отсюда и эта ошибка. Замечательное решение, блин :( В замен они предлагают использовать preg_match:

у а что же делать тем у кого весь сайт напичкам ereg или установлен популярный движок какой нибудь cms которая во всю использует ereg? В первую очередь ищем обновления своих цмс. Если не получилось делаем следующее: 1. Открываем файл настройки PHP (php.ini) и ищем, ближе к самому концу файла, текст:

там много чего поубирали, я на 5,2,9 откатился нафиг, у меня 100+ сайтов слегло после апдейта :(

О, во кста :)

да это все на удаленном хосте происходит как туда влезть???

phpinfo

ну так выключи варнинги в продакшене, а потом потихоньку убирай... date - сначала надо задать текущий часовой пояс (или в конфиге, или функцией) ereg* - правильно, ибо prce* быстрее и мощнее session_register депрекэйтед еще с 5.0 на самом деле, юзай массив $_SESSION (ну и $_SERVER, $_REQUEST, $_POST, $_GET, $_FILE) - реально упрощает код для понимания.

выключить варнинги и спать спокойно (депрекэйт все равно работает, просто намекает о том, что есть способ лучше). установить новую версию ЦМС (если она _популярная_ - то там этих варнингов нет, только в говновелосипедо модулях, которые всякие неудачники разработали для практики и забили на них, как на мертворожденное нечто)

да ну нафиг :) это коммерческие сайты, и их админов не колышет, что мне надо обновится до 5.3.0, а за них, я такую кучу сайтов (чужих к тому же) лопатить не буду. ПОка на 5.2.9 пашет и норм :)

депрекэйт и "порезали" - весьма разные вещи

:) у меня паника после того обновления при словах пхп 5.3+

впадаю в ступор и прикидываюсь ветошбю

сменилась кодировка для пыха, теперь надо все пыховские файлики открывать и сохранять в той-же кодировке. либо mbstring юзать

"#^([^[:punct:]]|[-_])+$#"