rb2

С какого перепугу? Будет использоваться либо текущий язык пользователя, либо AJAX запрос пропущен "AS IS". С какого перепугу? Если нет языкового префикса - используется текущий язык пользователя. С какого перепугу? Работы там - кот наплакал. Проверка и переключение языка - штуки 3 проверки. Плюс в код формирования урл добавление текущего языка пользователя. Ну и пропуски AJAX запросов, плюс картинки можно отдавать без кода языка в урл. Хотя иногда наоборот хочется разные картинки для разных языков (например лого с графическими надписями). По сути - это всё. В общем, я это писал уже чуть выше. Там логика обработки этих языковых префиксов - всего 2 предложения. И всё логично и просто, нет никакого спагетти и неоднозначностей. Заморочки возникают только при желании оставить вариант с отсутствием кода языка по умолчанию в урл. И при обработке адреса главной страницы (чтобы адрес "/" был доступен без редиректов и без кода языка, если выбран вариант с постоянным присутствием кодов языков в ЧПУ).

Кто ж знал, что подготовленный и выложенный для всех оригинальный сеопро Yesvik-а из ocStore не будет взят в работу над ocStore? А вместо неё стали развивать копию без отдебаженного языка в урл и других исправленных ошибок. Некоторые из которых, похоже, до сих пор тянутся.

Понятия не имею, как там. Сделал так, как было в сеопро из ocStore 1.5 с доработкой кодов языка в урл от @freelancer Как было и устраивало всех до этого 4 или 5 лет, начиная с ocstore 1.01 в 2011. Нет. Код языка в ЧПУ - индикатор системного языка, урлы формируются исходя из него. Он же является переключалкой языка. Ничего там не вырисовывается. Всё прекрасно работает уже пару лет. Ну и не у одного меня оно работает на живых магазинах. Давайте без этих абстракций, я блондинка и устал от разговоров "взагалі". Что конкретно не так и как надо правильно?

Вот это и я предлагал делать, пока другого вменяемого варианта нет Сеопро с кодом языка в урл уже давно есть и работает как написано. Сделано и лежит на гитхабе ещё за полгода до появления первого ocStore на OC2, пока бушевали разговоры делать или не делать, так или не так и т.п. Ещё во времена первых релизов OC2000.

301 им делать. Как в сеопро уже давно делается. Года два ко мне уже прибегают за установками пациенты опенкарт_раши и ни разу их эта проблема не волновала. Да и 301 нормальный и правильный механизм. Приходит старый урл (без языкового префикса) и текущий язык неизвестен (первый визит или визит робота) - редиректим на новый урл (с языком по умолчанию). А в новом урле есть код языка, который переключает его в системе.

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

В админке нет модели "account/order".

Я б вообще к чертям убрал. Не понимаю, зачем их изначально надо было резать. Переключалка языков в моем варианте сеопро есть, мне хватает. Как быть в 3.0 - не думал. Я, разумеется, считаю, что язык должен быть в URL и переключать его заодно. Что-то не вижу тут никакой связи чпу с языком. Только с магазином. Может она есть где-то в коде по соседству, не смотрел. И предпочёл бы видеть предохранитель `LIMIT 1` в этом запросе. Поскольку непонятно, сколько там дублей в базе вытянется по одному кейворду.

@Yoda без перехода на личность Д. ответить на твой вопрос у меня не получится. Промолчу.

Wechat Pay. http://open.wechat.com/cgi-bin/newreadtemplate?t=overseas_open/section_detail&show=pay https://github.com/opencart/opencart/search?utf8=✓&q=wechat&type= А состояние фильтров там в гет-параметрах же передаётся? Чтоб не терять при навигации (при возврате с товара). Наверное.

`Git blame` же. Приветы - shoputils-у: $ git blame -L 46,50 header.php f4038c53 (Daniel kerr 2014-08-27 12:57:09 +0800 46) $this->load->language('common/header'); 0f8e35d7 (shoputils 2017-02-20 00:22:37 +0300 47) $data['og_url'] = (isset($this->request->server['HTTPS']) && (($this->request->server['HTTPS'] == 'on') || ($this->request->server['HTTPS'] == '1')) ? HTTPS_SERVER : HTTP_SERVER) . substr($this->request->server['REQUEST_URI'], 1, (strlen($this->request->server['REQUEST_URI'])-1)); 00046435 (dinox-pro 2015-11-11 13:03:26 +0200 48) $data['og_image'] = $this->document->getOgImage(); f4038c53 (Daniel kerr 2014-08-27 12:57:09 +0800 49) f4038c53 (Daniel kerr 2014-08-27 12:57:09 +0800 50) $data['text_home'] = $this->language->get('text_home'); А здесь shchs $ git blame -L 224,230 common.js 0833932a (shchs 2016-10-30 13:05:29 +0300 224) var now_location = String(document.location.pathname); ffcf8468 (Daniel Kerr 2015-08-18 13:06:20 +0100 225) 0833932a (shchs 2016-10-30 13:05:29 +0300 226) if ((now_location == '/cart/') || (now_location == '/checkout/') || (getURLVar('route') == 'checkout/cart') || (getURLVar('route') == 'checkout/checkout')) { 6f5fca4f (Daniel kerr 2014-09-01 21:56:13 +0800 227) location = 'index.php?route=checkout/cart'; 6f5fca4f (Daniel kerr 2014-09-01 21:56:13 +0800 228) } else { 6f5fca4f (Daniel kerr 2014-09-01 21:56:13 +0800 229) $('#cart > ul').load('index.php?route=common/cart/info ul li'); 6f5fca4f (Daniel kerr 2014-09-01 21:56:13 +0800 230) }

Расскажите для тормозов, что случилось. Или что было. Или что погуглить. Я проблем не заметил. Банк - П24 работает (вроде). Магазин продуктовый работает (терминалы на кассах ок, хотя на некоторых - точно, таблички о неработоспособности терминалов висели). Второй магазин (мелкий, с печеньками) - тоже ок, там тоже карточкой платил. В первом магазе терминал на кассе был ощадбанковский. Во втором - приватбанковский. Да? Я из Днепра, если что. UPD: ок, читаю про петю.

Мало ли кто что влепит от незнания. В опенкарте есть код, есть какие-то внутренние соглашения, нет документации. Это использование `_status` ничем не лучше и не хуже остальных. Вполне безобидная хрень, которая на поверхности и легко и быстро обнаруживается разработчиком.

Так не бывает. Вы наверное просто смотрите не туда. Искать надо в логах ошибок веб-сервера, а не в логах опенкарт.

Ну и рефлекторно лезем посмотреть на индексы и видим традиционно: ни по языку, ни по `store_id` индексов нет. Ламер-тормозилла.

А это случайно не связано с новым инструментом "Language translation"?

1. Убедитесь, что вносите изменения именно в тот шаблон, который используется. 2. Обновите модификации (это в разделе расширений/дополнений).

Давайте я сам решу, какими проектами с какими бюджетами мне хочется заниматься. Ваше предложение попало в зону интереса, но какие-то формулировки трактовать можно двояко и поэтому потребовались уточнения для более однозначного понимания условий сделки обеими её сторонами. Как ещё объяснить, что иногда вопрос - это просто вопрос, потому что непонятно, а не желание вытянуть с вас 1000 вместо 100? Впрочем, до свидания. Всё равно не сработаемся.

А долго ещё ждать хоть какой-то КОНРЕТНЫЙ ответ? Ну сколько обычно был занят ваш прошлый разработчик? 5 часов в месяц? 2 часа в день (40-50 в месяц)? Больше? Неужели эту оценку (уже имеющуюся) сложно озвучить? Просто квалифицированный senior PHP dev - это минимум $15 в час. Тот, что умеет ещё и фронт-энд / jQuery, и верстку, когда надо - ну 20-30. Если не больше. Причин продавать свои услуги дешевле не так уж много, хотя в принципе их придумать можно. Остальным проще на Upwork сидеть. Я пытаюсь понять - насколько вы в курсе имеющегося положения вещей. И на какой примерно объём работ рассчитываете. Может ваш предыдущий разработчик просто ничем не занят был и запасов хватало, вот и помогал хорошим знакомым. Ну или учился. А вы проецируете эти ожидания на весь мир, если кроме него ни с кем не работали.

@whiteblue это проза жизни. Борьба с ними неэффективна. Клиентов таких лучше и не хотеть. Тех, у кого это в ранге жизненной философии. Случайно залетевших и неразборчивых - мало. И рано или поздно они получат с вареза порцию шеллов и наедятся по самые гланды или поумнеют и придут за нормальным сервисом и обновлениями. Но тащить силком - я смысла не увидел. Любое кодирование - от воров защищает не очень, а порядочным клиентам жизнь часто осложняет. По некоторым данным доход после начала ионкубленья модулей растёт. Но подумайте, за счёт какой аудитории. По другим данным - процент ворья и сознательных мошенников таки очень низкий на фоне обычных потребителей. Проще и дешевле без разбирательств вернуть капризному клиенту деньги, чем выносить себе мозг и забивать его говнищем. С чем борешься - тем и становишься в итоге. Вспоминайте это почаще. Согласен с @nikifalex - лучше заниматься обновлениями и не забивать голову и карму этой проблемой вообще. Если не хватает на пропитание - оставлять в ранге хобби, а продавать свои услуги.

Да я прекрасно понимаю. Думал о таком же формате, правда он мало кому интересен. Но ответов на свои вопросы так и не вижу. Подписаться на хрен пойми какую загрузку и невозможность её спланировать - кому из разработчиков такое надо? Поэтому и вопросы возникают.

По объёмам работ непонятно. У количества и частоты ваших желаний "по два часа" ограничения есть? Пара часов в день, неделю, месяц - это мне понятно. А "любые доработки, если одна работа не превышает два часа", за 100 в месяц - непонятно. Вы бы лучше определились, сколько прмимерно будет стоить 1-2 часа доработок при вашем бюджете, и в этих кирпичах работу меряли. Всем было бы понятней и прозрачно. Ещё момент - что за задачи. А то, знаете, есть backend и серверная часть, а есть вёрстка, дизайн, фронтэнд программирование. Вам хипстеры, full-stack или бородатые сисадмины? Я понимаю, что всем хочется full-stack webdev, но не по 50 в час, а по 100 в месяц, но всё же...

Да. Оба домена должны указывать в ту папку, где один экземпляр движка установлен (на первый магазин, короче).

Здесь неправильно. Корневая директория должна в одну и ту же папку указывать.

Ага, щазз. http://php.net/manual/en/function.mb-ereg-replace.php