alex39

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

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

Для владельцев бизнеса ответ очевиден, для "программистов" естественно всё непонятно.

Вполне возможно. Однако если работа в области модернизации CMS не является основной, весьма сложно понять где искать и с кем иметь дело. Рынка услуг в нормальном понимании нет, есть некое, достаточно замкнутое сообщество "сидящих в теме", но "страшно далеки они от народа" . Что касается "и сам могу", так ведь данная ветка совсем не про поиск исполнителей. Хотелось грамотных советов по "идеологии", если можно так выразиться. Их к сожалению не поступило. Пришлось пробовать самому. Естественно, с точки зрения тех, для кого модернизирование СМS личный бизнес - это "неправильно". Однако мне, к счастью, образование позволяет это сделать, пусть даже и с чуть большими временными затратами. Заказчик и "программист" всегда будут говорить на разных языках. Профессиональных постановщиков задач у заказчика скорее всего не окажется. Так что всё очень просто - профессиональный исполнитель всегда сумеет выжать из заказчика всю нужную ему информацию, и более того, письменно зафиксировать её в ТЗ. Если он этого не умеет, то такой исполнитель не нужен. Что касается "рисков" доступа, имелось в виду совсем иное, нежели банальные вопросы сохранения данных и обновления доступа...

Проблема, как Вы правильно заметили, совсем не в плоскости денег. Где искать, кого, по каким критериям? Как предъявлять претензии, если вдруг сделано криво, или вообще не сделано. Я уж не говорю о том, что отдать доступ - тот ещё гемор с малопредсказуемыми последствиями. Да и рынка предложений толком нет, с обозначением расценок и сроков по типовым задачам. Как то не встречались мне предложения типа "перенесу базу за 1 день за 5 000 руб.". Даже в этой ветке вопрос задавался, предложений отчего-то не поступало. А подобных веток тут уже с десяток наверное...

Интерес и получение опыта - безусловно. Тем более, что всё равно с этим дальше придётся работать. Однако по ходу задавался вопрос о стоимости, в ответах фигурировали цифры от 100 до 20 тыс., а это уже совсем иной порядок. А спрашивалось совсем не "что это за ошибка" и почему (обычно в тексте сообщения об ошибке вполне достаточно инфы для понимания её сути), а интерес был понять объём работ и целесообразность. Методом самостоятельного тыка выяснилось, что объём вполне мал, а целесообразность вполне на уровне.

Просто замены seo на meta недостаточно. Во-первых, эти поля стоят в другом порядке, и их надо переносить. Во-вторых, в некоторых таблицах добавлены новые поля, в некоторых много. В некоторых изменен вообще состав полей. Так что 5-7 минутами тут не обойтись. Однако по сути, именно это и было сделано, т.е. база приведена к новой структуре. В чём же тогда "неверность рассуждений"?

Если только этим занимаешься, всё стоит на потоке и набита рука, то конечно. Хотя насчёт "30 минут" явное преувеличение. Ну да ладно. Один день, включая установку на локалку и "въезд в тему", плюс действительно полчаса сегодня - для меня лично вполне приемлемо. Что касается "проблем, сделанных собственными действиями" - поясните pls. Про "изначально неверные рассуждения" тоже хотелось бы услышать, только не голословно, а конкретно. Что-то никто направление "верных рассуждений" не спешил давать, когда вопрос с самого начала задавался...

Не "он стал первым", а в системе русскому принудительно задан новый идентификатор - "1". А в старой системе ему же был задан идентификатор "2". Именно произвольная смена идентификаторов и прочего в разных сборках и версиях затрудняет переход на новые версии Opencart... Было бы гораздо проще, если бы соблюдались некие стандарты. Не факт, что перенос таблицы языков лучше. Всё равно придётся некоторые таблицы править. Тут что так, что так, - без разницы. Ну "разработчики", так не разработчики... До сих пор считал, что если в программном комплексе имеется критически важная переменная, тем более индексируемая primary, то при разработке новой версии её параметры обязаны оставаться неизменными. А если уж по каким-то причинам меняется, то это должно быть описано в документации. Как и смена файловой структуры кстати... Риторически - зачем например в 2.3.0.2.3 в менеджере изображений ограничили путь к папке изображений папкой demo, и отрубили выход в другие? Опять ручками в код лезть?... (Про админку 2.3.0.2.3 вообще отдельная тема, по сравнению с 1.5.5.1.2 она просто ужасна...). В результате приходится уделять дополнительное внимание тому, что по нормальному должно бы было становиться автоматически. Все эти выкрутасы с изменениями идентификаторов, переименованием полей и прочее осложняют переход на новые версии, особенно тем, для кого постоянная работа с кодом не есть основная деятельность. Но с другой стороны, видимо кому-то обеспечивают вполне себе приличный кусок хлеба .

Да, именно так и есть. Вчера уже не стал дальше ковырять, а там всё очень просто оказалось. В старой версии id русского установлен как 2, а в новой как 1. А английский у меня был снесен за ненадобностью. Лечится командой типа UPDATE `ххх` SET ` language_id ` = REPLACE(`language_id `, "2", "1"); в таблицах типа ххх_description, ну и ещё где надо, и всё завертелось... Единственный "подводный камень" - в некоторых таблицах language_id имеет Primary индекс. Почему language_id для русского в разных версиях имеет разное значение - вопрос риторический. Для обеспечения совместимости логичнее было бы сохранять id языков прежними, а не менять их от версии к версии, ну да разработчики - они такие разработчики... .

"Кучи проблем" не усматриваю. Внимательно ещё раз посмотреть базу и только. Чтобы за 1 день с налёта все заработало - такого не бывает. Для меня, и многих других, озабоченных аналогичным вопросом важнее было понять насколько это сложно, а главное - будет ли результат. Оказалось что не сложно, и результат вполне хороший. Именно это и есть полезный опыт. Я, когда свой первый вопрос в этой ветке задавал, ожидал, что знающие люди расскажут, аргументированно "за" и "против", наставят так сказать на путь истинный.. Ну не сбылось... Вместо этого пошли околовсяческие дискуссии. Попробовал сам, потратил ровно 1 день. Выяснилось, что никаких заморочек там нет.. Вот и всё.

Перенёс базу 1.5.5.1.2 на ocStore 2.3.0.2.3, возможно кому-нибудь пригодится описание процесса и выводы. Вчера вечером скачал ocStore 2.3.0.2.3 и поставил на локалке. Ставил на Оpen Server, правда плохо, что у них нет архива старых версий, т. к. были некоторые проблемы совместимости версий софта при установке на ту же локалку старого 1.5.5.1.2. Затем взялся сравнивать базы. Сравнивал на Meld, - очень хорошая штука, специально заточенная на сравнение файлов и директорий. Правда сначала ошибся, - начал сравнивать не дампы, а бэкапы, полученные из админки. Естественно часть данных пропустил, к тому же потратил лишнее время. Хорошо, быстро спохватился... Сравнивать надо только дампы! Базы не то чтобы слишком отличаются, но творческая мысль разработчиков от меня порой ускользала. В некоторых таблицах просто переставлены местами поля, в некоторых чуть изменены имена и типы данных. Некоторые таблицы естественно пришлось просто добавить. Всего в моей базе было 110 таблиц, а в дефолте ocStore 2.3.0.2.3 их 132. В итоге потребовался почти целый день, чтобы всё привести к общему знаменателю и запустить свою базу на 2.3.0.2.3. Всё работает, правда пока кривовато, где-то что-то пропустил... В общем, ничего сложного в процессе нет, хотя это долго и монотонно. Проблемы: Магазин работает только при включении переключателя английского языка, правда показывает на русском. А админка не работает совсем. В неё можно зайти, но ничего кроме надписи «Панель управления» не отображается . Это странно, в таблице oc_setting значения config_admin_language и config_language установлены как ru-ru, а ос_language просто тупо заменена на новую. Да и вообще, всё что касается language при сравнении выглядит одинаково. Добить не успел, завтра буду смотреть... Теперь по смыслу работы. В браузерах (Crome и Firefox) адаптивный дизайн выглядит замечательно даже на дефолте. Так что можно уже сразу и запускать... Хотя браузеры показывают с погрешностями, увиденного вполне достаточно, чтобы понять что моя задача обеспечения работы на мобильниках полностью решается. Это самое главное. Доработка шаблона много времени не займёт, тем более, что все изменения на 1.5.5.1.2 детально документировались. Структура файлов и папок на 2.3.0.2.3 практически мало отличается. Бегло просмотрел несколько основных файлов, различия в коде конечно есть, но в общем логика (как это понятно) вполне узнаваемая. Так что у тех, кто знает структуру старых версий, проблем возникнуть не должно. Резюме - никаких мобильных версий, переход на 2.3.0.2.3 вполне реализуем. Конечно при большом числе модулей придётся поработать, но... на 2.3 всё вполне красиво и действительно адаптивно.

Отсутствие понимания что именно целесообразнее делать. То ли на мобильный шаблон на 1.5.5.1.2 , то ли переходить на 2.3 и уже оттуда делать нужное для работы с телефона. С 2.3 никогда не работал, поэтому никак не могу оценить ни целесообразность, ни объём работы. Именно с вопросами об этом и пришёл. Действовать в режиме "война план покажет" пока нет необходимости, поэтому вопрос изучается.

2 dexion, приношу извинения за неверное цитирование в предыдущей записи. Проявил невнимательность... Ога. Потратить кучу времени на эксперименты с новой версией без какого то ни было понимания эффективности, трудоемкости, и уверенности в конечном результате? Пока мне лично непонятно - какова сравнительная "тяжесть работы", по двум вариантам: мобильный шаблон на 1.5 vs переезд на 2.3 с переносом шаблона и обеспечении работы на мобильнике. Преимущества и недостатки вариантов пока можно опустить, там не всё однозначно. Чтобы упростить - переведём вопрос в плоскость финансов. Допустим и та и другая работа заказываются для сайта с упрощенным функционалом без особых излишеств. Чисто качественно, пусть будет ошибка 10, 20, даже 50%. Т.е. просто порядок цифр можно оценить? По этим цифрам всё и будет ясно. Риторический вопрос - а кто должен определять это видение? Верстальщик, программист, гуру SEO? Их конечно можно и нужно слушать, но при всём уважении, голос у них только совещательный. Ибо кроме того, что они скажут каждый со своей колокольни, владелец руководствуется ещё массой соображений, им зачастую неведомым. И то, что с их точки зрения супер хорошо, для владельца может оказаться неприемлемым в принципе. Ведь он совсем другими категориями мыслит. Кстати, зачастую именно этого те самые программисты/гуру и не понимают и понимать не хотят. Что есть развитие магазина? Регулярная смена версий движков, шаблонов и внешнего вида ? Наверное всё же нет. Наверное это работа c продвижением товаров, статьями, общение с клиентами во всех формах проявления, та же SEO оптимизация и ещё масса всего, но уж никак не скакание с версии на версию движка через год-два. "Пинков для развития" мы и так достаточно получаем, со всех сторон... ;)). Эта тема про перенос с 1.5х на 2.3, так давайте этим тут и ограничимся.

Это не мой случай. Некоторым образом связана, считай всю жизнь, не только и не столько сайтов конечно. Другое дело, что уже давно перестал сам практиковать, да и с магазинами дело имел лишь раз, но... Тогда мне непонятно что Вы имели в виду Вроде прямо противоположное написано... Что значит "от финансовых возможностей"? Я не планирую покупать модули и кому-то что-то заказывать. Вечерочком, в свободное время, ручками, не спеша... Именно поэтому и спрашиваю, уже в который раз, но никто не отвечает. Насколько будут различаться трудозатраты по созданию моб.версии для 1.5.5.1.2, и переходу на 2.3 имея в виду, что она должна работать в том числе и в мобильном варианте.

Естественно если работает то нефиг... Однако необходимость назрела, это очевидно. Шаблоны "не показываются", поскольку как правило сделаны программерами без предварительной отрисовки правильными дизайнерами, и в спешке. Поэтому до изучения функционала обычно не доходит, ибо отвратность внешнего вида отбивает охоту напрочь ;). Плохое оформление мыслей и идей как бы даёт повод усомневать само наличие этих мыслей и идей. По поводу Не факт. Во-первых, магазин мой, а стало быть и видение прежде всего моё ;). Тем более, что тематика весьма узко специализированная. Да и с чего бы это он может "таким" получиться, если мы этим делом более 20 лет занимаемся... Начал было разворачивать "во-вторых" и "в-третьих", но у нас тут всё же не философско-мировозренческий форум, так что снёс (хотя конечно тема философии бизнеса штука интересная). Более конкретный вопрос. Я правильно понял, что Вы всё же считаете что надо пробовать 2.3? Мне бы просто хотелось понять насколько будут различаться трудозатраты при создании мобильной версии и переходе на 2.3, ибо своё время придётся тратить. Да и само существование коллизии с про гуглпейджспид тоже заставляет дополнительно задуматься... И ещё одно. Когда начинал весной 2014. уже двойка была на подходе, но все сказали, что надо 1.5.5.1.2. Прошло 5 лет, теперь оказывается, 1.5 морально устарела уже года два как. Т.е. начав сейчас возиться с 2.3, и потратив на это пару месяцев в неторопливом режиме, не получится ли так, что через два года 2.3 тоже морально устареет, и придётся переходить на 3.х?

Я несколько дней читал форум прежде чем начать задавать вопросы. И практически общее мнение в более чем десятке веток - переход с 1.5 на 2.3, особенно если надо обеспечить перенос шаблона, - дело весьма трудоёмкое и непростое. И если есть возможность, то лучше этого не делать. А теперь вдруг Вы говорите, что это вполне себе обычная процедура без особых сложностей... Моя цель в этой дискуссии только одна - выбрать наиболее эффективный, и по возможности менее трудоёмкий способ запуска мобильной версии. Ибо мобильный трафик уже 28%, плюс ещё около 20% - планшеты. Т.е. почти "приплыли" называется... Всё остальное, разные модули-шмодули и прочее для моих целей не нужны, и вряд-ли будут нужны. Даже у 1.5х вполне достаточно функционала для закрытия всех потребностей в нашем случае. Есть рабочая версия без проблем, и если бы не мобилы, век бы и не думал что-то там ещё делать. Касательно произведённых доработок: - делалось на дефолте, из которого выпилено всё лишнее (что и повлекло основные затраты времени); - добавлено одно поле в карту продукта, как бы второе дополнительное описание; - поставлен модуль autocalc_price_option_v2.0.22; - поставлен некий простой модуль с хлебными крошками (уже не помню что там) на vqmode; - вручную допилен вывод логотипа производителя в карту продукта (только правка шаблона); На этом всё. Самое главное, что никаких новых потребностей по функционалу нет и не предвидится. Вот и вопрос - что делать? ;)). Вариантов два - мобильная версия через Mobile detect, или переход на 2.3. Одно сразу могу сказать, - никакие посторонние шаблоны ставить пока не собираемся. До сих пор не видел вообще ни одного, ни платного, ни бесплатного, который бы "показался". У нас конечно тоже не шедевр, но хоть глаз в явном виде не режет. Поэтому при переходе на 2.3 придётся всё снова ручками править, и в общем не слишком понятен объём работы. Вот такая диспозиция... Буду благодарен если ответите. ЗЫ: Я лично тоже сайты на телефоне не люблю смотреть, - просто неудобно, и почти всегда урезанный функционал. Но молодёжь уже ничего иного себе не представляет...

С vqmod потом будем посмотреть, пока не до этого. Это то понятно, но я имел в виду другое. Попутно - Вы похоже не совсем корректно выразились - "указываете их в контроллере для моб версии", ибо контроллеры то стоят отдельно от темы (шаблона). Т.е. имеется в виду, что в соответствующем контроллере надо фиксировать факт перехода на моб.версию и задавать вывод соответствующих картинок. Дело в том, что многие картинки для дектопа ориентированы альбомно, т.е. в ширину, а в мобиле можно сказать везде квадрат. Т.е. просто ресайз при любом способе его задания мало поможет, ибо явно пострадает "художественная сторона вопроса", поскольку для моб.версии из длинных картинок придётся вырезать только содержательную, почти квадратную часть. К тому же, при большом ресайзе из админки резко падает качество (несмотря на установку качества 100%). Т.е. по любому часть картинок придётся перерисовать, и исходя из требования единой базы, придётся как-то извращаться, думать куда их класть и по какому признаку вызывать. Как именно это делать пока не решил. Проще всего видимо с картинками в header - просто сделать новую группу баннеров и установить их в слайдшоу для макета mobile. Действительно, sorry ). Это SiteMix написал Уважаемый SiteMix - что именно Вы имели в виду, говоря про слайдер? Да конечно, но гемора тоже хватит ). Я вот подумываю - а не имеет ли смысл тупо пробутстрапить текущую версию? Однако трудно оценить насколько будет трудоёмко дальнейшее, т.е. после внедрения Bootstrap, и что именно получится. Возможно и ничего хорошего если исходная верстка альбомная... Огромное спасибо dexion за подсказки и вообще общение. У меня проблема не в "коде-программировании" как таковом, а в недостатке практики именно с Opencart и так сказать в "идеологическом осмыслении". Всей практики - около 5 лет тому запустил сайт (помучавшись немного с изучением Opencart с нуля), и всё на этом. Только некие косметические доработки изредка...

Вот то-то и оно, что верстка разная, и vqmod может не пойти... И что тогда делать? С картинками видимо придётся делать вторые копии, или плюнуть, задав лишь новые размеры в mobile_css. По слайдеру Вы говорили - Вы какой именно слайдер имели в виду? Если на сайте, то для мобильной его вполне можно выпилить, возможно и colorboх тоже (смотря по дизайну). В общем, получается полностью создание нового магазина для мобильной версии, что через Mobile detect + шаблон, что внедрять Bootstrap и потом еще много чего доделывать. Всё это не особо весело конечно...

ЗЫ: То ли вообще создавать под мобильный шаблон дополнительный магазин в админке с новым путём в той самой поддиректории...

Если правильно понял, имеется в виду, что на сервере создаётся вторая копия всех файлов Opencart из папки catalog, в которой делается свой css, а в контроллерах прописываются новые пути. При обнаружении входа с мобилы происходит переброс на вторую папку, но url остается прежний. В этой связи вопросы: 1. Что делать с vqmode? 2. Каким образом библиотека Mobile_Detect помогает изменить пути в контроллерах? Я с ней не работал, поэтому не в курсе. Контроллеров там более 100 файлов, не хотелось бы ручками... 3. Каким будет оптимальное решение ресайза изображений для мобильной версии. То ли создавать для этого дополнительные поля в админке, то ли прописывать ресайз принудительно для вывода в куче файлов?

Однако распространено мнение, что второй css, и соответственно версия m.xxx.xx гуглу не нравится, или это ошибочное мнение?

А как к Ага, значит есть смысл попробовать потестировать... "Прикрутить адаптивное" - вопрос лишь какими средствами это лучше и проще сделать... "Определенные знания" есть, нет опыта, ибо занимаюсь совсем другими вещами. Если вдруг вспомните где был шаблон на 1.5 с бутстрап, напишите pls.

Тезис "Когда человек ищет причину чтобы не делать, то ему это не надо." в данном случае неприменим, ибо как раз и стоит задача "что-то сделать", вопрос лишь в выборе наилучшего способа. За ответы на вопросы большое спасибо. Хоть какая-то конкретика появляется. Касательно Bootstrap - в 2.3 он уже встроен? Т.е. создана ли для дефолтного шаблона необходимая файловая структура и компоненты, или всё надо будет ручками с самого начала? Если ручками с самого начала, то действительно может нечего огород городить, а просто внедрить тот же Bootstrap в имеющийся сайт на 1.5.5.1.2,? Так возможно сделать, или там будут какие-то проблемы? Спрашиваю, потому что не работал c ним, просто читал пару раз. alena967 - спасибо за ответы. Что касается цитаты то это совсем не мне было сказано, однако возражать против этого хоть и древнейшего, но совершенно верного тезиса явно не приходится....

Есть то он есть конечно, известный факт, но в реале может показывать неверно. Вообще, вопрос совсем не о том как смотреть и проверять мобильные версии. Вопрос о том, целесообразно ли переходить и насколько новые версии соответствуют. C "программированием знаком" ещё со времён майнфреймов , но совсем не "разработчик" Opencart, тему её изменений вообще не отслеживал до сего момента. Сделал магазин 5 лет тому, запустил и забыл, периодически какие-то "красивости" добавляются, работает, и ладно. Трогать работающее вроде бы не с руки... Можно конечно ещё раз то же самое повторить и на новую версию, но сначала всё же хотелось бы оценить целесообразность, трудоёмкость, временные затраты и прочее. Конкретные вопросы: 1. Какими средствами организована мобильная версия на 2.3 или 3.0. Там два css или как? 2. Насколько процесс разработки мобильной версии на 2.3 (3.0) сложен или прост? К примеру, если надо с нуля писать второй css, то с тем же успехом можно написать его и для старой версии. 3. Принципиальный вопрос - на что переходить, на 2.3 или 3.0+? Читал, что 3.0 пока "сырая" - насколько это так? 4. Насколько различаются структуры баз у 1.5.5.1.2, 2.3 и 3.0. 5. Насколько поменялась "идеология" и организация работы в новых версиях с точки зрения разработчика? 5. Насколько вообще различается общая структура файлов у новой и старой версий, в том смысле, что с 1.5.5.1.2 понятно где и что, а с новой придётся ли долго разбираться, или там примерно то же самое? 6. Да и вообще понять насколько функционал новых версий лучше чем 1.5х, и в чём именно.