Пальцем в небо.
В шаблоне(ах) ссылок в настройках инфоблока в конце стоит пробел. Его надо убрать
В шаблоне(ах) ссылок в настройках инфоблока в конце стоит пробел. Его надо убрать
24.01.2018 17:29:21
1) #PRODUCT_URL# это весь шаблон, не нужно к нему нечего приписывать
2) В основной каталог пропишите шаблон ссылок для элементов, на скриншоте у вас же там пусто #PRODUCT_URL# это путь для товара из основного каталога, к которому предложение привязано 3) Плюс сбросьте кеш, если не сбросили. --- Еще раз Основной каталог #SITE_DIR#/shop/#SECTION_ID#/#ELEMENT_ID#/ Предложения #PRODUCT_URL# --- Если вы хотите отдельную страницу для каждого предложения, то это редкий случай и он настраиваеться чуть подругому. |
|
|
23.01.2018 11:17:28
Для доступа нужно для вашего(или одного любого) ключа лицензии битрикса прописать свой логин форума/портала, Что обычно делаеться при активации ключа. Можете проверить ключ и указанный логин Сменить логин наверно только через ТП. |
|
|
20.01.2018 06:25:55
Тогда
|
|||||||
|
20.01.2018 03:55:44
Немного сумбурно описано.
Отбор по дате, например, можно сделать так, сначала
Паджинация работает только в рамках одно запроса, и элементы вне текущего лимита не будут возвращены. То есть если вы ходите одним запросом получить все записи, то нужно своим кодом разбирать результат на ваши "сначала ..." и "а далее ... оставшиеся",. Может вам нужна сортировка по двум полям ? (в данном случае маловероятно, но вопрос изначально неясен.)
Сформулируйте свою мысль, тогда и код будет сразу ясен. А так не понятно, что у вас за сущность, что такое актуальность, у Вас одна выборка или две. Скорее всего вам и спрашивать не пришлось бы, если Вы могли четко сказать что должен делать код. |
|||||||||
|
20.01.2018 03:07:27
Во первых файлы инфоблоков нельзя трогать напрямую. Хотя теоритически критических ошибок не должно быть, если только пережимать картинки. Просто в базе храниться параметры картинки и размеры файла, и код работающий с файлами может не перепроверять фактические параметры, но скорее всего не сдохнет. Разве что вы серьезную подмену делаете типа замены png на jpeg.
Уменьшение картинки можно делать при заливке и в шаблоне где эти картинки выводяться. Я как правило не уменьшаю при заливке, а просто делаю лимиты, что бы совсем дикие фотки не лили. А в шаблоне делаю уменьшение по ситуации. Таким образом в одном месте можно поменять параметры выводимой графики и включить/выключить наложение водянки, не трогая залитые файлы. Но это именно уменьшение, а не оптимизация. Битрикс использует GD библиотеку, сомневаюсь, что из нее можно что-то получше вытянуть. Разве что снизить качество jpeg, но там реально треш выходит по качеству. Типовых решений пока нету, но тема важная, гараздо важней композита, на мое усмотрение. Я пока решил через image lazy loading. |
|
|
18.01.2018 23:42:30
Потоковое сжатие трафика вы можете увидеть в отладчике(f12),
в http ответе заголовок "Content-Encoding gzip" и сравнивая колонки "Size" и "Transferred" В вашем случае размер html страницы 72.17 KB а передано 16.52 KB Обратитие внимание, что Собственно на скрине отчет по анализу http ответа с переадресаций, сканер просто не пошел на новую ссылку. 184 байта это ж явно не html страница ![]() |
|
|
18.01.2018 18:21:42
Автоматом как правило не делают, так как изменение цены очень частое событие, а экспорт yml это дорого по ресурсам. На моих проектах как правило выгрузка раз в час и маркет не жалуеться. Для нескольких проектов делал динамический экспорт, то есть ссылка на пхп файл который отдавал контент в реальном времени, но это неактуально.
|
|
|
18.01.2018 17:53:52
Стало интересно, протестировал, работает. Технически можно спокойно использовать переменные и вызовы в определении массива с правами. Но как я уже говорил и ТП потвердило, что так делать не следует. Админская оснаска не расчитана на такое содержимое файла.
Перевожу, "Сие есть говнокод дикий", хоть и рабочий. Как вам поступить сложно сказать, не видя проекта целиком. Может вам через группы, может через инфоблоки, может хайлоад, может блоги или форумы. Я как правило запрещаю всем юзерам файловый доступ (даже менеджерам и контенщикам), а весь динамический контент в базе в виде инфоблоков или своих таблиц. Что бы 400+ человек могли загрузить любой файл, хоть и в свою дерикторию, это большая дыра в безопастности проекта целиком, и "access" файлик нечего не сделает. |
|
|
18.01.2018 16:55:21
Не тестировал, но по вашем примерам вижу, что в рабочем варианте используется "U4", а в не рабочем "4", что не есть равно.
Предположу
|
|||
|
18.01.2018 16:30:33
Леонид Малов, В исходном вопросе ссылки одинаковые, то есть это одна ссылка которая несколько раз написана. По сути о дублях на самом деле не идет речь, просто в файле карты сайта несколько раз написана одна ссылка, что не есть дубль в сео терминологии.
Работа с сео дублями это другая большая тема. |
|
|
18.01.2018 16:20:37
Могу ошибаться, но думаю дубли в карте на индексирование вообще не как не влияют, как и на ранжирование.
Вот если бы у вас были разные ссылки на один товар, например Вот тогда беда. Но я бы в любом случае исправил бы, путем настройки карты заново, так как там могут быть и другие ошибки(битые и устаревшие ссылки, редкое обновление и тд). Если это типовой функционал глючит, то исправление через ТП битрикса. |
|
|
09.01.2018 16:27:39
Не то что бы я был против JSON Data Type, но у вас есть бечнмарки, сравнение, примеры существующих проектов?
Что дает в сравнении с текущей схемой таблиц инфоблоков? Просто проблема ветки не в мускуле. Если вы напишите свой компонент каталога или свою админку на чистом мускуле, то все будет летать. База на 100к строк товаров и 10м связанных строк других таблиц для мускула это вообще нечто, это школьный проект на планшете. Еще раз повторюсь, проблема в медленных выборках в ядре с ненужными полями, утечках памяти в api и устаревшем UI фреймверка админки. Смена схемы базы не решит данную проблему. А так, если добавит скорости чтение/записи базы на том же обьеме данных, то я только за. Ну может я ошибаюсь... В любом случае я нечего не решаю, и просто хочу повысить приоритет проблемы для разработчиков битрикса. |
|
|
09.01.2018 15:45:21
В настройках интерфейса "Формы редактирования" уберите все свойства и добавте одно поле "Значения свойств".
Это одно поле будет отображать вместе все свойства этого раздела с учетом наследования. Отмечать галкой "Умный фильтр" для этого не нужно. --- Дополнение Нужно выбрать "Значения свойств" без черточек. То есть не "--Значения свойств" |
|
|
09.01.2018 13:08:41
Хайлоад почти не использую. Мне мягко говоря не нравиться интерфейс. Контенщику совсем плохо. Использую ORM и доработаную формы редактирования элемента через события. Описанный баг реально дикость. Что-то мне кажеться на конференции заявляли, что хайлоды задуманы на многомиллионные таблицы.
--- Привязка реализуеться через классы CIBlockSectionPropertyLink и \Bitrix\Iblock\SectionPropertyTable. Задаеться в /bitrix/admin/cat_catalog_edit.php?lang=ru&IBLOCK_ID=#IBLOCK_ID# (подставить свой ID инфоблока) и в редактировании разделов поле "Свойства элементов". Влияет в основном на форму редактирования элемента, что бы показывались только свойства данного раздела. Но можно использовать в своих модулях/компонентах/шаблонах. --- Редактирования списка разделов в выгрузке и их разбивка на инфоблоки делаеться в интерфейсе настройки обмена на стороне 1с, после установки модуля. Работает, как не странно, исправно. У менеджеров не было жалоб конкретно на данную фишку. --- Решения с множеством инфоблоков я избегаю, по очевидным причинам. Но можно просто в шаблонах ссылок добавить символьный код инфоблока, и перед вызовом комплексного компонента каталога добавить несколько строк кода который будет брать символьный код и подставлять ID в параметры компонента. Хоть это заочно и навскидку, но думаю не должно быть других проблем. Я так не делаю, но должно работать. |
|
|