Dotrox

Десятки раз уже писал на форуме - все редиректы надо добавлять после строки: RewriteBase / А не где попало!

Если вы уверены, что проблема в этом, то почему на сайте всё ещё не подхватывает текст введёный в поле поиска?

С таким уровнем знаний вам бы лучше на фриланс за помощью обратится. Вот это селектор (один из): 'header input[name=\'search\']' отсюда и нужно было убрать. Я ведь выше даже скинул код, в который нужно было внести правки.

Что именно убрали? Убрать нужно было только header!

Примерно так же, как сахар солью заменить - на глаз же одинаково. И там ведь даже примеры есть: Так откуда у вас там появилась полная ссылка на сайт? Но вот тут: Должен быть реальный путь к файлу в корневой директории сайта (соответственно, и файл должен лежать там). Путь спрашивайте у хостера.

Заменить каталог на админ.

Вы поле поиска вынесли из header, а он есть в селекторах: /* Search */ $('#search input[name=\'search\']').parent().find('button').on('click', function() { url = $('base').attr('href') + 'index.php?route=product/search'; var value = $('header input[name=\'search\']').val(); if (value) { url += '&search=' + encodeURIComponent(value); } location = url; }); $('#search input[name=\'search\']').on('keydown', function(e) { if (e.keyCode == 13) { $('header input[name=\'search\']').parent().find('button').trigger('click'); } }); Уберите его из селекторов для начала.

А не проще поделить часовую ставку пополам? Как заказчику определить, что с него по фиксированной ставке не взяли 100 баксов за то, что стоит 5 баксов? Ответ на этот вопрос такой же, как и на эти: А именно - никак. Если у кого-то есть острое желание обмануть заказчика, он найдёт способ при любом раскладе. Я рассматриваю вариант, когда никто никого обманывать не собирается. Почасовая ставка не означает, что надо обосраться (буквально), потому что оценил работу в час и теперь не можешь на 10 минут в туалет отойти. Существуют тайм трекеры. Остановил трекер - и можно хоть спать пойти. Заказчик платит по трекеру только за чистое рабочее время, а программист работает в удобном ему графике. Ну а сроки оговариваются исходя из рабочего графика, а не чистого времени. А теперь самое интересно про фиксированную ставку: программист оценивает работу, начинает работать и понимает, что работы намного больше, чем ожидал (соответственно, стоит она в разы дороже). Что дальше? Варианты: 1. Работать в убыток. 2. Попросить больше денег. 3. Забить на роботу и "пропасть". 4. Делать как попало, чтоб уложиться в начальную оценку, а потом рассказывать, что то и это не доделано, потому что стоимость этого и не предполагала. Мне не раз приходилось доделывать за теми, кто выбрал варианты 3 и 4, перед этим оценив работу значительно ниже реальной стоимости. С почасовой ставкой такой проблемы нет. Фиксированную ставку можно выставлять только, когда выполняешь задачу, которую уже делал (вот прям 1 в 1) и точно знаешь сколько она занимает времени. Потому что запросто может оказаться, например, при установке какого-то модуля, что у него возник конфликт с каким-то другим модулем (для ОК ситуация довольно обычная) и устранение этого конфликта занимает больше времени, чем сама установка, за которую была названа фиксированная сумма.

Вы же сами написали уже из-за чего - Dr. Web. Как я уже написал вам в другой теме (где про Dr. Web вы упомянуть забыли) - это, скорее всего, конкретно ваша проблема, а не сертификата или хостинга. Если сомневаетесь, проверьте сайт тут: https://www.ssllabs.com/ssltest/

Надо срочно рассказать об этом все аутсорсерам, которые применяют почасовую оплату, а то ведь они и не догадываются, что больше всего платят тем, кто знает меньше всего Всё решается размером часовой ставки! Кто меньше знает (джун без опыта) получает 3 - 4 бакса в час, кто больше знает (мидл с опытом 3 - 4 года) получает 12 - 15 баксов в час. А почасовая оплата - это наиболее адекватный вариант оценки работы.

Мозилла? Попробуйте анонимное окно. Скорее всего, это проблема конкретно вашего браузера (персонально вашего).

Для первого варианта код в моём предыдущем сообщении. Для второго варианта тут (просто подставьте туда нужные пути): И следите, чтоб редиректы с шаблонами были после редиректов для отдельных страниц, иначе последние работать не будут.

Да. Этот шаблон должен подхватить все категории: RewriteRule ^product-category/(.*)$ / [R=301,L] Для остальных ссылок просто меняйте начальную часть на соответствующую.

А вот тут уже придётся каждый редирект прописывать вручную, либо искать в страницах что-то общее. Иначе шаблон будет редиректить и страницы нового сайта и будет та же ошибка с ERR_TOO_MANY_REDIRECTS.

Ну, это уже что-то. Можно попробовать упростить редирект, раз ru там всегда. RewriteRule ^ru/(.*)\.php$ /$1 [R=301,L]

Просто не редиректит и всё? Их надо вообще убрать.

Ну, шаблон в любом случае будет работать.

Конечно не работает, начальная ссылка ведь уже без ru, а вы ru оставили в условии редиректа. Если новые ссылки от старых отличаются только отсутствием .php на конце и ru/ в начале (которого может и не быть в старой ссылке), то можно сделать редирект по шаблону: RewriteRule ^(ru\/)?(.*)\.php$ /$2 [R=301,L]

Это директива из другого модуля. Нельзя использовать одновременно mod_rewrite (который ОК уже и так использует) и mod_alias (из которого директива Redirect) - это обычно приводит к различным глюкам. Как вы думаете, что такое _route_? Это параметр, который используется при внутреннем перенаправлении и предназначен для системы ЧПУ ОК. Так вот, в _route_ никогда не будет домена и тем более протокола! Если вы первый вариант редиректа уже удалили из .htaccess, а страница всё ещё куда-то редиректит - это браузер просто закешировал редирект, потому что ваш код вообще работать не должен! И зачем у вас на конечной ссылке вопросительный знак в конце? Вообще, для вашей задачи такой сложный редирект не нужен! Вот этого достаточно: RewriteRule ^ru/detskaya-odezhda-optom\.php$ /detskaya-odezhda-optom/ [R=301,L] Проверяйте через анонимную вкладку браузера, ибо браузеры кешируют 301й редирект.

Региональный мультимагазин - это всегда нагрузка в разы (а то и десятки раз) выше, чем у обычного магазина. Не знаю сколько товаров и поддоменов у ТС, но из моего опыта: магазин на 15к товаров и 99 поддоменов, nginx + php-fpm + memcached - нормально справляться с нагрузкой от поисковиков получилось только на сервере, где 4 ядра и 8Гб памяти. При чём, именно памяти хватало и 4ГБ, но когда было 2 ядра, их не хватало для работы нужного количества воркеров php-fpm (а в пиковые моменты их бывает работает больше сотни).

Для этого есть лимиты на количество воркеров. Память растёт не просто так - её съедают воркеры. У Апача их количество тоже можно ограничить, но жрёт он больше, так что воркеров будет меньше. Вы, кстати, Апач вручную настраивали?

Не раз настраивал такое на nginx + php-fpm и никогда не возникало мысли, что с Апачем было бы проще (скорее, наоборот).

Выкинуть Апач на свалку и поставить php-fpm. А размер базы к работе Апача никакого отношения не имеет. Разве что, если база тормозит, это заставляет воркер Апача дольше висеть на каждом запросе и, соответственно, нужно больше параллельных воркеров.

Достаточно просто в параметрах функции link поставить $secure = true вместо false и эффект будет абсолютно тот же, о чём на форуме написано уже много раз. Но не все ссылки в ОК формируются через этот класс (особенно это касается сторонних модулей), так что иногда помогает только правка конфигов. А иногда и она не помогает, если автор какого-то модуля додумался захардкодить протокол.

Если она вам не нужна, просто удалите и будет там тоже 404.