Прикупили данное решение для одного из наших клиентов. Развернули, ахнули от вкусностей и качества реализации. И вот пришел момент, когда клиент сказал, мол хочу чтобы фотки шин были поменьше.
Мы же начитанные... пошли в настройки инфоблока моделей шин и изменили картинку анонса... Результат - пустая главная страница со спецпредложениями. В итоге - день коту под хвост. Разумеется, написали в ТП, где нам начали давать очень странные, простите, даже глупые советы... Глупые, не в том смысле, что люди не понимают что говорят, а в том что ТП даже не вникла в глубину вопроса, а посмотрела на проблему чрезмерно поверхностно. Стало обидно за державу, но потом вспомнил, программист я или нет? ТП это хорошо, а без нее быстрее (надеюсь Сергей Рыжиков сможет понять глубину проблемы и это будет +1 к проведению реформы в ТП). Развернул 2 проекта, один из них сломал настройкой, второй остался девственно чистым. Собрав мысли, сверив все скрипты перешел к изучению БД. Я признаюсь сразу честно и прошу мне не говорить, что тут это нормально, а тут нет. Я просто В ЛОБОВУЮ сделал сверку и составил запрос:
UPD ATE b_iblock SET `SECTION_PAGE_URL` = NULL, `DESCRIPTION` = NULL, `SECTION_CHOOSER` = NULL, `LIST_MODE` = NULL, `EDIT_FILE_BEFORE` = NULL, `EDIT_FILE_AFTER` = NULL WHERE `ID` = 5;
UPD ATE b_iblock SET `SECTION_PAGE_URL` = '#SITE_DIR#tyres/#CODE#/', `DESCRIPTION` = NULL, `SECTION_CHOOSER` = NULL, `LIST_MODE` = NULL, `EDIT_FILE_BEFORE` = NULL, `EDIT_FILE_AFTER` = NULL WHERE `ID` = 4;
UPD ATE b_iblock_property SE T `DEFAULT_VALUE` = NULL, `FILE_TYPE` = NULL, `LINK_IBLOCK_ID` = NULL WHERE `IBLOCK_ID` = 5;
UPDATE b_iblock_property SE T `DEFAULT_VALUE` = NULL, `FILE_TYPE` = NULL, `LINK_IBLOCK_ID` = NULL WHERE `IBLOCK_ID` = 4 AND CODE!='model_more_photos';
UPDATE b_iblock_property SE T `DEFAULT_VALUE` = NULL, `FILE_TYPE` = 'jpg, gif, bmp, png, jpeg', `LINK_IBLOCK_ID` = NULL WHERE `IBLOCK_ID` = 4 AND CODE='model_more_photos';
Таким образом мы возвращаем значения полей к виду, каким их делает мастер создания магазина колес.
Данное решение я предоставляю тем, кто столкнулся с проблемой и будет пользоваться этими "костылями", пока программисты Битрикса не выпустят фикс к продукту.
Так же я хочу обратиться к разработчикам Битрикса... Господа, дамы. Я понимаю, что тяжело проверять решения партнеров, да, там могут быть ошибки, хотя с точки зрения концепции MarketPlace это недопустимо (если это не beta). Но я отказываюсь понимать, как такие ошибки в релизе продукта совершают сами программисты из 1С-Битрикс... Ведь вам известна структура БД, известно о продукте все...
Это платное решение. Не тестирование, не freeware... Это не баг, не опечатка. это НЕСОВМЕСТИМОСТЬ.
Печаль.
p.s. когда оформляем код "апдейт" в запросе разделяет как "UPD ATE", вот этот пробел - это уже баг. Ведь при оформлении в виде кода должна быть целостность написания.
Номер обращения был дан выше: #245376 Но там, думаю, не будет особо достаточной информации по проблеме, т.к. проблема решалась напрямую мной с разработчиками решения по телефону. Поэтому, ждем апдейта решения.
Вкратце - при сохранении свойств инфоблока Шины слетала привязка с SKU моделей шин, соотв. ломался весь каталог.
Поэтому приходится всякий раз восстанавливать связь в настройках SKU, чего разумеется простой смертный просто не догадается сделать... До момента, когда мы нашли этот баг, у клиентов на руках оставался сломанный каталог товаров, который получалось чинить только SQL запросом, который я опубликовал в первом посте. Сейчас это делать не приходится, т.к. стало понятно как лечить более человеческим методом, однако не удобно и не корректно с точки зрения концепции продукта.
На самом деле лично я немного обеспокоен работой Битрикса. Прочитал сегодня все изменения над бета версиями "УС", где на самом деле, как заметил Сергей Затылкин, ведется серьезная работа для "социальных" вариантов сайтостроения. ОДНАКО! Мы разрабатываем в основном Интернет-магазины, корпоративные сайты, сайты-визитки и пр. Уверен, клиентов бы порадовали обновления фотогалереи и поиска, а разработчиков бы сильно обрадовал новый редактор для php/js/html с подсветкой синтаксиса.
Многие разработчики просят, просят... но реализация просьб не видна.
На языке Глеба Архангельского, это "слоны", которые Битриксу взять тяжелее, чем ежедневное поедание "лягушек". Лягушки действительно важны, их "ежедневность" в том числе, но сложные и важные задачи на самом деле должны как-то сдвигаться с места.
Не понимаю вас Если вы не увидели в этом обновлении того, что ожидали именно вы - то все плохо?
Фотогалерея в производстве, поиск в производстве, для интернет-магазина делают большое обновление с поддержкой характеристик в заказе и многое другое в производстве. Но это выйдет позже, в версии 10.
А сейчас мы выпустили вещи, которыми партнеры захотят поиграть на выходных и которые нужны нам будут при реализации концепций ближе к 10.
Будьте добрее, ищите плюсы в том что происходит. Мы тоже постараемся
Сергей, боюсь я был не верно понят. Моя доброта парит вокруг меня, словно облака в небесах Я всегда стараюсь видеть во всем плюсы, а когда не нахожу - ожидаю помощи в поисках от окружающих меня людей
Поэтому данная тема и появилась в блоге, дабы меня вывели на свет. С Вашей помощью и помощью других коллег, я несомненно увижу плюсы, сути, планы...
Относительно меня и моих мыслей - конечно же я мыслю субъективно. Объективную оценку работы должны давать аналитики, непрерывно погруженные в работу изнутри и снаружи одновременно. Наше же партнерское дело - видеть только внешние факторы и только их принимать в расчет.
Т.к. я не имел возможности ознакомиться с предрелизом функционала и обновлений X версии - сужу по текущим результатам. В любом случае, думаю Вы не обнародуете нововведения ранее релиза по внутренним причинам
Но проглотив наживку и подсев на крючок буду ждать
+1, много того что не надо и еще больше того, что есть но не совсем доработано, к примеру модуль рассылки, очень сырой и местами явно с незавершенной мыслей.
Сегодня возникла задача перенаправить сайт клиента с одного адреса, который успешно проиндексирован в поисковых системах, на новый.
Пример задачи: есть домен mydomain.com, разумеется он есть в Яндексе и не плохо там раскручен. Появляется второй, более интересный домен, скажем domain.ru Разумеется сайт для обоих доменов один. Как заставить скрипт определять, на нужный ли домен зашел посетитель? А в случае, если посетите зашел на новый домен сам, как сделать чтобы редирект не срабатывал?
Как видно из данного скрипта, массивом мы учитываем доменные имена mydomain.com и www.mydomain.com. Далее скрипт мягко перенаправляет посетителя на сайт www.domain.ru
Плюсы и минусы... С одной стороны скрипт в 2 строчки... С другой - у кого-то все страницы сайт отрабатываются одним скриптом, скажем index.php, а у кого-то каждая страница - свой файл, и внедрять данный код не целесообразно.
Теперь решим эту задачу не средствами скриптов, а глобально, на уровне веб-сервера Apache, с подключенным модулем mod_rewrite.
Правилами RewriteCond %{HTTP_HOST} ^mydomain\.com$ [NC] RewriteCond %{HTTP_HOST} ^domain\.com$ [NC] мы перечисляем домены, с которых ждем посетителей. В нашем примере мы прослушиваем домены mydomain.com и domain.com и перенаправляем с них посетителей на домен www.domain.ru. Для SEO очень важно, что поисковым системам мы выдаем 301 редирект.
Данный метод мне нравится больше всего, т.к. это надежно, глобально и не вызывает у поисковых систем аллергию.
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».