Всего 125 336 комментариев

Лев Вербицкий
15 апреля 2013, 11:49
0
Обновил тикетс, сделал вывод через getTickets. Проблема ушла))
Clean
15 апреля 2013, 10:57
0
Использую WinSCP таких проблем нет.
сам iptables действительно только на новый конект с IP смотрит, видимо перезакрывается сессия
Василий Наумкин
15 апреля 2013, 06:30
0
Пока по другому никак, скоро сделаю.
Василий Наумкин
15 апреля 2013, 04:28
0
На здоровье.

Сейчас пишу mSearch2, там такого не будет.
Василий Наумкин
15 апреля 2013, 04:27
0
1. Внутри одной группы можно сделать несколько уровней доступа, так как политика назначается с учетом роли. То есть, будет группа менеджеры, а внутри:
— Главный менеджер, с политикой Administrator
— Обычный менеджер — Content Editor
— Копирайтер — Text edit only

Это надо для очень больший сайтов с толпой юзеров, я пока не пользовался.

2. Ты можешь реализовать всю эту логику в своём процессоре. Но вообще да, так сделанно именно для CRC. Например, товары MS2 дублируются немного иначе, чем обычные ресурсы.

3. Да, просто накатываешь сверху setup и core, а потом обновляешь. Чтобы не было проблем — сначала сделай бэкап. Важный файл там только один — config.inc.php, он не затирается.

Лично у меня все обновления завершались без ошибок.
Василий Наумкин
15 апреля 2013, 04:18
0
Прикольный.

Особых косяков не заметил, разве что на странице с корзиной пропадает footer и «заказ звонка» работает только на главной.

Ну а каталог сайтов давно есть — on-modx.ru, добавляйся.
Василий Наумкин
15 апреля 2013, 04:13
0
Категории отлично сортируются перетаскиванием в дереве.
Алексей Вахрамеев
14 апреля 2013, 23:36
0
Сделал напрямую сей SQL запрос, в ответ услышал ругонь о том, дескать таблицы `modx_mse_modResIndex` не существует… Как же так, подумал я? )) И вспомнил свой давний пост — http://modx.pro/help/321/, в котором уже писал про нечто подобное. Правда там дело было не в [[!mSearch]], а просто товары не отображались, но причина та была весьма схожей.
Вина всему — корявый экспорт дампа с другого сервера без учета регистров в названиях таблиц. По дефолту все экспортнулось с малыми буквами, а в названиях таблиц MS2 присутствуют заглавные, а это как раз и стало источником проблем. Переименование таблицы излечило болячку.

Василий, еще раз спасибо за подсказку, она меня навела на правильный путь.
Алексей Вахрамеев
14 апреля 2013, 22:54
0
Ок, спасибо, буду пробовать…
Василий Наумкин
14 апреля 2013, 22:46
0
Попробуй скопировать и выполнить этот же запрос через phpMyAdmin.

Может, на хостинге какая-то версия MySql древняя, что не позволяет такие запросы проводить? Как таковой ошибки в твоей записи не вижу.

И эта, используй тег code, для оформления логов.
СикретНаме
14 апреля 2013, 21:47
0
Тек-с, вот результаты тестов и поиска:
1. Увеличение до 31 секунды вернуло знакомые «помирания», вернулся на 10 — нормализовалось.
2. Уменьшение до от 7 секунд и ниже + явное указание в настройке конкретного подключения режима передачи «пассивный» даёт отсутствие не закачавшихся файлов и маааленькое улучшение скорости.
3. Не нашёл в FileZilla «конкурентный подключения», ни в ней ни в поиске
4. Канал у меня — 7 метров/сек железно гарантированная минималка
5. Снял в FileZilla галочку «разрешить возврат к другому режиму при сбое» (к п. 2, думаю, относится).
Василий Наумкин
14 апреля 2013, 21:01
0
Попробуй в FileZilla убрать конкурентный подключения, подозреваю — проблема в этом.

И таймаут на реконнект 31 секунду поставь.
Василий Наумкин
14 апреля 2013, 20:59
0
По идее, эта защита работает только на инициализацию нового соединения. Если ошибка подключения — клиент банится на 30 сек.

Думаю, выходит так: ты соединился, начал качать, интернет отвалился, но ты сессию-то не закрыл. Ломишься опять на сервер, 30 секунд не прошло и тебя не пускают. Пока будешь ломиться — будут банить снова… Надо подождать 30 сек и тогда зайдешь.

Видимо, тебе надо просто связь улучшать.
СикретНаме
14 апреля 2013, 20:56
0
Я то только за, но больше, чем 10 сек у меня выдаёт кучу обломов — на 10 то секундах из 56 файлов 3 файла на повтор кача пришлось ставить (на 30 и вовсе 10-15 бывало не зальётся и на повтор надо ставить). Не знаешь, как решить проблемку?

Кстааати, что вспомнил!

Вот ещё траблочка небольшая — сам по себе кач довольно медленный. Какой бы тот же Петерхост туповатый ни был, но чистая установка MODX Revo заливается через FileZilla весьма, весьма и весьма быстро. А тут что-то не то — очень долго. Подскажешь куда и как копать для решения?
Василий Наумкин
14 апреля 2013, 20:55
0
Можно, никаких.

Он грузит свой jQuery только если не было загружено вообще никакого.
Clean
14 апреля 2013, 20:45
0
Все равно, тайминг ниже 30 секунд на попытку ставить я бы не советовал, у меня auth лог забит брутфорсом ботов с абсолютно разных геолокаций, но как правило это страна узкоглазых желтых друзей…
Думаю у других пользователей такая же штука…
СикретНаме
14 апреля 2013, 20:36
0
Спасибо, Василий, вроде бы проблема устранилась. Хотя, конечно, день-два покажут только, всё ли норм. Но сейчас, вроде как нормально стало. Судя по всему, я не рестартил iptables. И, да, не смотрел изменения настроек — смотрел бы, понял бы, что не изменилось ничего = что-то не так сделал я.

П.С.
Пока писал, тестил нормализацию и нарвался я на то же самое, притих такой и вдруг — БАЦ, и скачалось (раньше, если влипало на такой зависон, не скачалось бы 100%).

Так что двойное спс :0)
СикретНаме
14 апреля 2013, 20:18
0
Тек-с, вот этого не делал, косяк… Но изменения ssh рестартил, разумеется, для случая, когда удалён iptables должно нормально всё быть, вроде бы.

АП:
Да, так и есть в записях IPT.
Василий Наумкин
14 апреля 2013, 20:07
0
А ты не забываешь потом запускать сам этот скрипт?

Активные настрйоки проверяешь командой?
sudo iptables -L

При отключении всех правил должно быть вот так:
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination