Доброго времени суток!

При вставке ссылки из буфера обмена в форму ответа и последующей отправки ответа ...

В сообщении криво отображаеться ссылка...

Например: иммеем ссылку вида _http://domain.ru/forum/topic/76643-novyi-forum/?p=1601360

А получаем вот такое преобразование

[url=http://domain.ru/forum/topic/]http://domain.ru/forum/topic/[/url]76643-novyi-forum/?p=1601360

http://domain.ru/forum/topic/76643-novyi-forum/?p=1601360

 

Как починить?

Форум 3.4.5

Спасибо!

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

 

Несколько ссылок в одной строке не проходят. Отображается только одна. А вот несколько ссылок, каждая с новой строки, добавляется нормально.

 

 

При всех минусах, ставить стороннюю локализацию от IBR и лишать себя оперативного апгрейда в случаях устранения критических уязвимостей считаю излишним.

Хотя, можно вставить несколько ссылок в одной строке, используя кнопку ББ-кода RTE:

 

 

Так что, проблемы скорее у IBR, чем у IPS.

За то последний не будет правильно работать с урл-ами в которых есть кириллица в utf-8 и не правильно установленной локалью в скриптах.

 

Насколько я понял из объяснений техподдержки, IPS склоняется к кодировке utf8 по умолчанию для своих продуктов в новых версиях. Типа: меняйте кодировку у себя, нам надоели ваши кракозябры в 20% случаев обращения в нашу техподдержку.

Ну с ббкодом понятно что работать будет. ИБР лопухнулись с тем, что перейдя на юникод забыли добавить поддержку числам (ссылка ТСа от того и парсилась не полностью). Логику ИПС построили хреновую, перейдя на preg_match_all не возможно составить вменяемое регулярное выражение чтобы оно соответствовало нужному формату. Если откатится на оригинальный код библиотеки, сохранив регулярку от ИПС (или ибр для юникода), все ссылки замечательно парсятся так, как нужно. Можете кстати спросить у них об этом, что за wtf.

Чтобы создавать запрос в поддержку, у меня что-то не должно работать. Пока не пойму, что же у меня не работает из вашего объяснения? :)

 

Так или иначе, все текстовые редакторы имеют ряд ограничений. Я свято верю, что в IPS пошли по этому пути по причине каких-то серьезных целей, например, безопасности или совместимости...

 

Хотя, спросить могу. Напишите, что спросить?

Изменено 17 июля 201312 г пользователем Zero108

Просто спросите почему не оставили оригинальную логику библиотеки htmlpurifier из файла ips_kernel\htmlpurifier\HTMLPurifier\Injector\Linkify.php где использовался preg_split, а поменяли на preg_match_all и теперь не захватываются все ссылки которые находятся в одной строке.

Я тоже верю, что какая-то причина все же была.

Спросил

Пока всё, что удалось узнать в личке:

 

 

Сейчас попробую изменённый linkify.php.

C изменённым Linkify.php ссылки в одной строке вставляются так:

 

 

Почти работает :)

 

Да, и чуть не забыл:

 

preg_match_all( "#(.*?)(\()?((?:http|ftp|https):\/\/[\w\-_]+(?:\.[\w\-_]+)?(?:[\w\-\.,\(\)@?^=%&:/~\+\#]*[\w\-\@?^=%&/~\+\#]))(.*?)$#ims", 

 

Поражает обилие неудалённого закомментированного кода в Linkify.php. Видимо, работа кипит, все течёт, всё меняется. IBR точно не угнаться за апдейтами. Так что, дружно пересаживаемся на IPS.

Я откатился, и у меня вставляются так

 

Меня ссылки в одной строке особо не беспокоят. Но, я подал запрос в техподдержку.

 

Интересно, в вашей версии, если вставить в LTE редакторе и сохранить в нем следующий код, два переноса строки после /center сохраняются или нет (без переключений на RTE)?

 

[center][img=http://ipbskins.ru/forum/uploads/av-32329.jpg][/center]


текст

 

У меня раньше второй перенос пропадал. Сейчас стало нормально сохраняться даже без предварительного переключения на RTE перед сохранением.

http://community.invisionpower.com/topic/391283-why-was-the-default-htmlpurifier-library-changed/?p=2423164

Я свято верю, что в IPS пошли по этому пути по причине каких-то серьезных целей, например, безопасности или совместимости...

Конечно же ради безопасности и совместимости IPS берут

$token = array(); обнуляют объект

           foreach( $matches[0] as $k => $match )
           {
               if( !$matches[3][$k] )
               {
                   $token[]   = new HTMLPurifier_Token_Text($token->data); и тут же к нему обращаются

Регулярка у ИБР давно выглядит вот так

preg_match_all( "#(.*?)(\()?((?:http|ftp|https):\/\/[\p{L}\d\-_]+(?:\.[\p{L}\d\-_]+)?(?:[_\p{L}\d\-\.,\(\(@?^=%&:\/~\+\#]*[\p{L}\d\-_\@?^=%&\/~\+\#]))(.*?)$#ims"

Это в моем дистрибе, который я скачал порядка месяца назад. Цифирьки учтены и ссылка ТСа парсится и на моем форуме и на ИБРовском.

 

Еще вот в последнем(?) патче от IPS регулярка выглядит как

#(.*?)(\()?((?:http|ftp|https):\/\/[\w\-_]+(?:\.[\w\-_]+)?(?:[\w\-\.,\(\)@?^=%&:/~\+\#]*[\w\-\@?^=%&/~\+\#]))(.*?)$#ims

Конечно, & подпадает под

preg_match("#[&]#ims", '&')

хоть и вместе с 'a','m','p' и ';', но как-то некрасиво.

 

Так что я никуда с IBR уходить не собираюсь, тем более, что у меня хостинг в \w русские буквы не включает и пересобирать php не дает.

Ну, можете порадоваться:

 

1. It was too loose and would pick up things which (although are valid URLs) are not what you might intend - for example "http://www.google.com (Google)" would link the "Google" bit. In 4.0 we've turned off that option in HTMLPurifier and using our own solution which is much more reliable.

 

http://community.invisionpower.com/topic/391283-why-was-the-default-htmlpurifier-library-changed/?p=2423164

 

Скоро ваш IBR не сможет вот так просто взять и поправить парсер, потому что это уже будет не бесплатная библиотека, а код с копирайтом IPS.

 

Так что вы там хотели сказать о преимуществах использования принципа баги IPS + баги от IBR? Ну, по сравнению с принципом: заплатил IPS и тебе все быстро делают в течение суток-двое?

Конечно же ради безопасности и совместимости IPS берут

$token = array(); обнуляют объект

$token[] = new HTMLPurifier_Token_Text($token->data); и тут же к нему обращаются

Видимо там должен был быть $match. Хотя трудно представить в каких этот условиях элемент с ссылками будет пустой при таком регулярном выражение. Либо ссылка нашлась, либо ссылка не нашлась, и соответственно нет совпадений. Поэтому, наверное, данный баг и не проявлялся до сих пор.