Пальцем в небо.
В шаблоне(ах) ссылок в настройках инфоблока в конце стоит пробел. Его надо убрать
В шаблоне(ах) ссылок в настройках инфоблока в конце стоит пробел. Его надо убрать
|
Тогда
|
|||||||
|
|
|
|
Немного сумбурно описано.
Отбор по дате, например, можно сделать так, сначала
Паджинация работает только в рамках одно запроса, и элементы вне текущего лимита не будут возвращены. То есть если вы ходите одним запросом получить все записи, то нужно своим кодом разбирать результат на ваши "сначала ..." и "а далее ... оставшиеся",. Может вам нужна сортировка по двум полям ? (в данном случае маловероятно, но вопрос изначально неясен.)
Сформулируйте свою мысль, тогда и код будет сразу ясен. А так не понятно, что у вас за сущность, что такое актуальность, у Вас одна выборка или две. Скорее всего вам и спрашивать не пришлось бы, если Вы могли четко сказать что должен делать код. |
|||||||||
|
|
|
|
Во первых файлы инфоблоков нельзя трогать напрямую. Хотя теоритически критических ошибок не должно быть, если только пережимать картинки. Просто в базе храниться параметры картинки и размеры файла, и код работающий с файлами может не перепроверять фактические параметры, но скорее всего не сдохнет. Разве что вы серьезную подмену делаете типа замены png на jpeg.
Уменьшение картинки можно делать при заливке и в шаблоне где эти картинки выводяться. Я как правило не уменьшаю при заливке, а просто делаю лимиты, что бы совсем дикие фотки не лили. А в шаблоне делаю уменьшение по ситуации. Таким образом в одном месте можно поменять параметры выводимой графики и включить/выключить наложение водянки, не трогая залитые файлы. Но это именно уменьшение, а не оптимизация. Битрикс использует GD библиотеку, сомневаюсь, что из нее можно что-то получше вытянуть. Разве что снизить качество jpeg, но там реально треш выходит по качеству. Типовых решений пока нету, но тема важная, гараздо важней композита, на мое усмотрение. Я пока решил через image lazy loading. |
|
|
|
|
|
Потоковое сжатие трафика вы можете увидеть в отладчике(f12),
в http ответе заголовок "Content-Encoding gzip" и сравнивая колонки "Size" и "Transferred" В вашем случае размер html страницы 72.17 KB а передано 16.52 KB Обратитие внимание, что и разные сайты и сканеры могут по разному реагировать на переадресацию. Собственно на скрине отчет по анализу http ответа с переадресаций, сканер просто не пошел на новую ссылку. 184 байта это ж явно не html страница ![]() |
|
|
|
|
|
Автоматом как правило не делают, так как изменение цены очень частое событие, а экспорт yml это дорого по ресурсам. На моих проектах как правило выгрузка раз в час и маркет не жалуеться. Для нескольких проектов делал динамический экспорт, то есть ссылка на пхп файл который отдавал контент в реальном времени, но это неактуально.
|
|
|
|
|
|
Стало интересно, протестировал, работает. Технически можно спокойно использовать переменные и вызовы в определении массива с правами. Но как я уже говорил и ТП потвердило, что так делать не следует. Админская оснаска не расчитана на такое содержимое файла.
Перевожу, "Сие есть говнокод дикий", хоть и рабочий. Как вам поступить сложно сказать, не видя проекта целиком. Может вам через группы, может через инфоблоки, может хайлоад, может блоги или форумы. Я как правило запрещаю всем юзерам файловый доступ (даже менеджерам и контенщикам), а весь динамический контент в базе в виде инфоблоков или своих таблиц. Что бы 400+ человек могли загрузить любой файл, хоть и в свою дерикторию, это большая дыра в безопастности проекта целиком, и "access" файлик нечего не сделает. |
|
|
|
|
|
Не тестировал, но по вашем примерам вижу, что в рабочем варианте используется "U4", а в не рабочем "4", что не есть равно.
Предположу
|
|||
|
|
|
|
Леонид Малов, В исходном вопросе ссылки одинаковые, то есть это одна ссылка которая несколько раз написана. По сути о дублях на самом деле не идет речь, просто в файле карты сайта несколько раз написана одна ссылка, что не есть дубль в сео терминологии.
Работа с сео дублями это другая большая тема. |
|
|
|
|
|
Могу ошибаться, но думаю дубли в карте на индексирование вообще не как не влияют, как и на ранжирование.
Вот если бы у вас были разные ссылки на один товар, например ?offer=123 Вот тогда беда. Но я бы в любом случае исправил бы, путем настройки карты заново, так как там могут быть и другие ошибки(битые и устаревшие ссылки, редкое обновление и тд). Если это типовой функционал глючит, то исправление через ТП битрикса. |
|
|
|
|
|
Не то что бы я был против JSON Data Type, но у вас есть бечнмарки, сравнение, примеры существующих проектов?
Что дает в сравнении с текущей схемой таблиц инфоблоков? Просто проблема ветки не в мускуле. Если вы напишите свой компонент каталога или свою админку на чистом мускуле, то все будет летать. База на 100к строк товаров и 10м связанных строк других таблиц для мускула это вообще нечто, это школьный проект на планшете. Еще раз повторюсь, проблема в медленных выборках в ядре с ненужными полями, утечках памяти в api и устаревшем UI фреймверка админки. Смена схемы базы не решит данную проблему. А так, если добавит скорости чтение/записи базы на том же обьеме данных, то я только за. Ну может я ошибаюсь... В любом случае я нечего не решаю, и просто хочу повысить приоритет проблемы для разработчиков битрикса. |
|
|
|
|
|
В настройках интерфейса "Формы редактирования" уберите все свойства и добавте одно поле "Значения свойств".
Это одно поле будет отображать вместе все свойства этого раздела с учетом наследования. Отмечать галкой "Умный фильтр" для этого не нужно. --- Дополнение Нужно выбрать "Значения свойств" без черточек. То есть не "--Значения свойств" |
|
|
|
|
|
Хайлоад почти не использую. Мне мягко говоря не нравиться интерфейс. Контенщику совсем плохо. Использую ORM и доработаную формы редактирования элемента через события. Описанный баг реально дикость. Что-то мне кажеться на конференции заявляли, что хайлоды задуманы на многомиллионные таблицы.
--- Привязка реализуеться через классы CIBlockSectionPropertyLink и \Bitrix\Iblock\SectionPropertyTable. Задаеться в /bitrix/admin/cat_catalog_edit.php?lang=ru&IBLOCK_ID=#IBLOCK_ID# (подставить свой ID инфоблока) и в редактировании разделов поле "Свойства элементов". Влияет в основном на форму редактирования элемента, что бы показывались только свойства данного раздела. Но можно использовать в своих модулях/компонентах/шаблонах. --- Редактирования списка разделов в выгрузке и их разбивка на инфоблоки делаеться в интерфейсе настройки обмена на стороне 1с, после установки модуля. Работает, как не странно, исправно. У менеджеров не было жалоб конкретно на данную фишку. --- Решения с множеством инфоблоков я избегаю, по очевидным причинам. Но можно просто в шаблонах ссылок добавить символьный код инфоблока, и перед вызовом комплексного компонента каталога добавить несколько строк кода который будет брать символьный код и подставлять ID в параметры компонента. Хоть это заочно и навскидку, но думаю не должно быть других проблем. Я так не делаю, но должно работать. |
|
|
|
|