Reborn

Штатный редактор — не добавляются картинки в тело материала. prntscr.com/ejdy9

Средствами html и css в com_user_profile.tpl

Предлагаю сменить понятие " дырявой " на более подходящее IT сообществу, на пример, безопастность 3 из 10 .
Реально, стрёмно звучит, Господа.
И при описании уязвимостей тоже нужно рассматривать уровень. Школота через post/get запрос,sql injection и линки дыбает (такое нужно срочно решать)!!!, или мастер, который всегда найдёт.
Лично я перейду на 1.9.1 (1.10) только из соображений безопастности и в надежде, что будет нормально работать редактор.Кодировка меня и cp1251 вполне устраивает.

по разному бывает...
Хотя, я признаюсь честно, ни какого решения я не увидел, за исключением одного, о котором писать не буду)

Всё, замяли.Акима более не тронут.

Hunter (Роман), без обид, но… не решение.

Было так /admin/.htaccess с паролем
и соответственно .htpasswd
Вот так...
Пока не удалил, в админку не попал…

А еси через Тор работает, тогда Iptables поможет?

вот интересно посмотреть что там выдал этот сканер?

На рутрекере есть, если не найдете, могу в личку скинуть.
Да что там интересного то… много пожеланий по поводу закрытия от sql иньекций, и не только.

кстати. этот чел мне обещал ддос на завтра.

Мне кажется, не стоит по этому поводу напрягаться, мало, кто может сделать это профессионально.А обычный Hoic4 ////это смешно)

[hide]Мдааааа… есть дыры (да простят меня админы). И жаль, когда они не в сервере, а в движке… Проверил Acunetix Web Vulnerability Scanner 8, волосы дыбом встали. Печалько( .[/hide]
Очень надеюсь, всё же, что 1.9.1, и тем более 2.0 будут без этого.

На чистый вряд ли.Используют nginx в связке с апач для фронтенда (только для статики). http://nginx.org/ru/
Nginx фронтендом от апача
instantcms.ru/blogs/zapiski-gorodskogo-trolja/nginx-frontendom-ot-apacha.html

что бы удалить компонент полностью, нужно:
В админке удалить его.
Там же удалить его модули и плагины .
После этого удалить на сервере все файлы компонента и сопутствующие (модули, плагины) (можно еще и tpl в шаблоне).
Удалить все его таблицы в базе.
В cms_comment_targets удалить запись об этом компоненте.

После Мака, хоть и триал, дезендер (для хрю) вряд ли сможет…

2. Мигратор большой и ёмкий, на слабых хостингах и при больших базах миграция попросту невозможна будет стандартными средствами, которые мы закладываем — необходимо заранее продумать варианты ГДЕ проводить саму миграцию — лучший вариант — это конечно свой пк или сервер, на котором вы сможете убрать все ограничения времени выполнения php и т.п. Так же будет заложена возможность в основном миграторе не выполнять непосредственно конвертацию базы, на случай, если вы захотите это сделать сами, например в консоли mysql или иными средствами.

Денвер для этого подойдёт? (если php.ini правильно настроить)
Если да, то вполне удобно забрать сайт с базой, апгрейдить, и вернуть на хостинг.