Помощь Вопросы и решение проблем с Битрикс

[jekadog]

Ну так конечно фича) И я правда не могу понять, почему от неё один вред то? Да, и ко всему битрикс научился отдавать изображения через NGINX, и вроде как эта фича отдается в первую очередь.

 

[pragmatik]

Ну так конечно фича) И я правда не могу понять, почему от неё один вред то? Да, и ко всему битрикс научился отдавать изображения через NGINX, и вроде как эта фича отдается в первую очередь.

Из вреда:
лишнии копии файлов - лишнее место на диске,
пути к сгенерированным файлам явно указывают на использование bitrix,
имена сгенерированных файлов не чпу (я бы предположил, что из-за этого трафик с поиска по картинкам будет меньше).

Господа, подскажите, пожалуйста, где в Управлении сайтом 14 находятся настройки кнопок визуального редактора? Всё облез. В модуле "Управление контентом" только общие настройки использования редактора.

 

[jekadog]

Ну так в настройках выставьте, что загружать файлы и оставлять их в оригинальном названии.. можно транслетировать тоже выставить.. не храните свои файлы, удаляйте их, битрикс все хранит в папке upload. Пути - и так все что есть в коде указивает на использования битрикса. Настройте сервер и отдавайте картинки в 20 раз быстрее. Я проблемы никакой не вижу, хотите все по своему сделать, напишите движок и перекотитесь с битрикса.
Какие кнопки в редакторе настроить надо? по моему в 14.5 уже HTML5 редактор, и настраивать я там не вижу чего надо..

 

[pragmatik]

Какие кнопки в редакторе настроить надо? по моему в 14.5 уже HTML5 редактор, и настраивать я там не вижу чего надо..

Мне нехватает кнопки выравнивания по ширине. В Для просмотра ссылки Войди или Зарегистрируйсяговорится, что: Настройка интерфейса редактора осуществляется вызовом диалога Настройки визуального редактора с помощью кнопки

. Форма настроек состоит из трех закладок, с помощью которых можно управлять содержимым панелей визуального редактора.
И я вот нигде не могу найти эту кнопку.. Ни в самом редакторе, при редактировании статьи, ни в настройках модуля "управление контентом".

 

[0nolek0]

Из вреда:
лишнии копии файлов - лишнее место на диске,

Вот не удержусь, отпишу.
Зато если вы прикрепите картинку к 5 элементам (и у каждого будет-таки да, по копии), а потом у ОДНОГО из них картинку замените, то остальные не пострадают.


Что касается нового редактора - для него практически нет настроек. Но зато вы можете пользоваться старым.
=)
Я так и делаю. Он настраивается так, как описано в доке для контент-менеджеров.

 

[pragmatik]

Вот не удержусь, отпишу.
Зато если вы прикрепите картинку к 5 элементам (и у каждого будет-таки да, по копии), а потом у ОДНОГО из них картинку замените, то остальные не пострадают.

Мне встречался этот аргумент, но давайте порассуждаем: мы ведь не вставляем в каждую статью одинаковую картинку.. наоборот, стремимся запихать на сайт как можно больше уникальных картинок, чтобы привлечь трафик.. я вот из своих проектов не могу вспомнить ни один, в котором бы одна картинка использовалась несколько раз.. такие ситуации действительно могут возникать, но на современных проектах они практически исключены, в силу всеобщей погони за уникальным контентом.. т.е. эту "страховочную" фичу следовало бы сделать хотя бы опциональной. А так получается, что множество проектов вынуждено хранить лишние мегабайты информации из-за атавизма.

Что касается нового редактора - для него практически нет настроек. Но зато вы можете пользоваться старым.
=) Я так и делаю. Он настраивается так, как описано в доке для контент-менеджеров.

Спасибо, я и понятия не имел, что их несколько)

 

[vava1]

Подскажите пожалуйста, как создать такую конструкцию свойств у товара: размер - большой/малый/так себе и в каждом был список свойств: вес, ширина, длина, высота?

 

[jekadog]

Используйте хайлоадблоки, по аналогии с цветом и прочим, так будет лучше чем просто свойства, хотя вам виднее, задача у вас)

 

[0nolek0]

Я жажду подробностей.

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

Вы видимо не сталкивались так же и с ситуацией, когда в b_file десятки тысяч записей, а картинок сотни тысяч и upload надо явно как-то чистить, потому что он уже занимает гигабайты...

Ваше желание спекулировать на тему SEO хоть и объяснимо, но вы пытаетесь навязать как "общеприменимую" свою практику. С ней не согласятся многие мои заказчики.
Ибо 1 картинка на 1 статью - это нормально. Потому, что с поиска по картинкам человек должен перейти на конкретную статью, а не на сайт вообще.

В общем, я вам сказал как оно устроено.
Я вам сказал, что для подобного устройства есть аргументы.
Если вы их не видите, ну значит или рано или просто вы работаете в другой области, у вас другая специфика.

Это я не заикнулся про унификацию. Ой, заикнулся.
Ну, в общем, это хорошо когда все картинки в аплоаде, а все картинки для инфоблоков в разделе ИБ. И это плохо когда все картинки хрен знает где по всему сайту.
Если вы против, то я не против чтобы вы сами копались в той помойке в которую превратиться проект, придерживающийся правила "кину картинку там, где хочу". Я вам помогать в этом не буду.
И думаю, многие со мной согласятся.


Ну в конце концов просто примите как данность это.
"И сказал Рыжиков да будет Битрикс. И сотворил он инфоблоки. И отделил он данные от картинок, поместив данные в таблицу, а картинки в upload. И понял он, что это хорошо. Аминь!"
Уже 10 лет как так сделано, особых причин делать иначе нет.
Не нравится? Храните в свойствах пути к картинкам, а картинки заливайте туда, куда хотите.

 

[pragmatik]

Я регулярно сталкиваюсь с интернет-магазинами, где продаются несколько одинаковых или схожих товаров. И это не товарные предложения. На первых порах для них берётся 1 общая картинка, а вот потом всё может поменяться.

А в чем проблема то? Ну есть у нас какое-то общее фото для всех позиций к которым нет уникальной картинки - лежит оно спокойно в определенной папочке и для каждого товара мы указываем путь к нему. Появились фото какого-то товара - поменяли в записи этого товара с пути к общей картинке на путь к его новым фото, а остальные товары без фото спокойно продолжают использовать старую картинку. При этом:
а) не создаются (и следовательно не хранятся) копии этой "общей" пустой картинки для каждого товара
б) если "общая" картинка перестала нам нравиться - достаточно ее всего один раз перезалить (а не менять в настройках каждого товара без фото)

Ибо 1 картинка на 1 статью - это нормально. Потому, что с поиска по картинкам человек должен перейти на конкретную статью, а не на сайт вообще.

А я разве не об этом говорю? Я и говорю, что сейчас заточенных на SEO проектов, в которых 1 картинка на несколько статей, почти нет. Наоборот стараются не только уникальную картинку для каждой статьи использовать, но и название файла картинки давать ревалентное контенту. Какая по-вашему картинка будет выше в результатах по запросу "Президинт поздравил ветеранов", prezident-pozdravil-veteranov.jpg или сгенерированная bitrix - wtrwerwerwerwerwerwerfbfg.jpg?

Вы видимо не сталкивались так же и с ситуацией, когда в b_file десятки тысяч записей, а картинок сотни тысяч и upload надо явно как-то чистить, потому что он уже занимает гигабайты...

Так я поэтому и критикую используемую в bitrix технологию, что не хочу столкнуться с такой ситуацией.. Ведь возникает она как раз из-за того, что для всех картинок создаются дубли с идиотскими названиями, да еще и сваливаются в одну папку.

Ну, в общем, это хорошо когда все картинки в аплоаде, а все картинки для инфоблоков в разделе ИБ. И это плохо когда все картинки хрен знает где по всему сайту. Если вы против, то я не против чтобы вы сами копались в той помойке в которую превратиться проект, придерживающийся правила "кину картинку там, где хочу". Я вам помогать в этом не буду.

В моих проектах структура папки с картинками дублирует структуру контента, поэтому никакой путаницы не возникает.

Уже 10 лет как так сделано, особых причин делать иначе нет.

Какой-то у Вас не айтишный образ мыслей. Мы имеем ситуацию, когда предложенное разработчиком решение очевидно далеко не во всех случаях идеально. Что мешает разработчику сделать его опциональным? Чтобы те, кому оно не подходит могли его отключить и не тратить лишние ресурсы на его использование. Чем забота о потребителях не причина? Я бы понял, если бы за эту фичу не айтишники отвечали, а люди, которые не заморачиваются с тем сколько ресурсов жрет система.