Анна Кузьмина (Все сообщения пользователя)

Да простят меня модераторы, но...

"«Качество рекламной сети» непосредственно влияет на продажи и экономическую эффективность рекламной кампании, а потому имеет более высокий весовой коэффициент (20%). Как мы уже говорили, наличие большого количества сайтов-ловушек для рекламы (почти по определению малоэффективных для решения задач рекламодателя) негативно влияет на общие результаты. Для оценки качества рекламной сети мы анализировали сайты, адреса которых фигурировали в отчетах рекламных служб (как вручную, так и с помощью небольшой автоматизированной системы), выделив три основных типа рекламных площадок. ... Не все они одинаково бесполезны; ряд проектов сделан весьма качественно и вполне способен генерировать клики. Выставляя им низкие оценки, мы ставили под сомнение только их способность стимулировать покупателя."

http://www.pcmag.ru/reviews/detail.php?ID=9800

Это про контекстную рекламу, однако, про "маркеты" ситуация ровно такая же.

Более интересный вопрос, как его откастомайзить, включив кастомные адреса

Лучше действительно не делать просто лишней работы. Все, что вносится стандартными средствами (из админки) индексируется и так сразу, все, что втыкается дополнительными скриптами просто требует одельного вызова UpdateSearch (например, для элементов инфоблока --

http://www.bitrix.ru/help/index.html?page=source%2Fiblock%2Fhelp%2Fru%2Fdeveloper%2Fclasses%2Fcib­lockelement%2Fupdatesearch.php.html)

Битрикс == свой сервак. Можно помаяться с виртуальными, VPS и прочим, но это все рукоблудие. И обойдется в итоге дороже.

Попробуйте без этого:

  mysql_connect($hostname, $username, $password);
  mysql_select_db($database);

А то по сути, вы отбираете у мускула коннекшн, сами в нем что-то делаете, и собственно, "Битрикс" не знает и знать не может, что именно (и закономерно, что корректного юзера не отдает, ыло бы удивительно, если бы отдавал). Лучше в начало файла включить стандартный маленький пролог и юзать функции. Или, хотя бы, в mysql_connect добавьте еще параметром TRUE, чтобы он создавал новый коннекшн и в запросах его же указывайте. При наличии нескольких коннекшнов _очень_ аккуратно надо с ними разбираться. В идеале коннекшн-пул даже, но это уже отдельная песня 8)

Кроме админа -- создаем группу, которой даем права на работу с ФГ (или добавляем это право "Зарегистрированным").

Но вообще да, разграничение доступа _очень_ нужно.

Ну пожалуйста (жалобно 8)

А зачем такой изврат?

ЗЫ <iframe> не подойдет?

Уважаемые коллеги... Вопрос. Тут имели мы очередной цикл секс... оптимизации -- с занятным итогом. Битрикс живет на выделенном тсервере, с двухуровневой конфигурацией. Походу провели эксперимент -- водрузили PHP (как CGI-сервер) на nginx, убрав нафиг Apache. Футпринт по памяти сразу раза в полтора, если не в два лучше, скорость -- вполне пристойная, подумываем а не оставить ли в таком виде жить. Еть ли у кого опыт, какие тут могут быть грабли? Пока все пучком, живет и работает (и судя по первым экспериментам с нагрузкой, вполне себе уверенно держит 30--50 активных юзеров (мучали днем, сеть зщагружена, на ночь поставлю стресс-тест, посмотрим еще).

Легко -- давай прям ща познакомимся, прааативный

А так -- все можно.

Вопрос в деньгах и времени.

Вообще, проще всего написать скрипт, заодно с API БУС разберетесь.

Посредством создания соответствующих "Свойств инфоблока", правда, с типами придется разбираться самостоятельно, но это несложно.

Гы, коллеги будем

/bitrix/templates/имя_шаблона

Но там надо гм... более или менее понимать.

Нет, многостраничных статей нет, только через костыли...

Делаем тип инфоблока "статьи и пресс-релизы", и два инфоблока соответственные, в компоненте проверяем и возвращаемся куда надо (точнее, оно само там сработает, главное все аккуратно прописать в свойствах.

Типа так.

Ага, а раздел новостей -- на форуме. Можно конечно. Но модуль напрашивается, факт.

incoldpages.php кстати редкостный образец гм... программирования.

Сейчас вот тоже столкнулись с необходимостью там ковырнуть пересылку в архив.

Рыдали

set_time_limit(60000);

(в скрипте постинга)

Есть мысль (сейчас коллега аналогичным мается) использовать для рубрикации не секции/разделы, а именно свойства. Вводим свойство "тег" (фактически это теги и есть), далее вся мощь фильтров "Битрикса" задействуется в полный рост. Аналогично вы можете сделать и номера, и рубрики...

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

Лучше бы свойства секциям приделали...

Выход через тохес, костыль, конечно, но... Создается множественное свойство "Строка", при вводе в поле значения втыкаем то, что станет названием параметра, а в поле "Описание" будут жить значения. То есть имеем пару не "жестко заданное свойство -- значение", а "любой текст в строке -- любой текст в описании".

Минусы очевидны -- исчезает возможность фильтрации по свойствам. Рисовать все надо самому из компонента. Да и вообще костыль. Но спасает, если надо просто выносить спецификации скажем, много, разных, развесистых.

Хотя кстати тема для размышления разработчикам, гибкие свойства -- это был бы мегарулез.

Видимо да, там название-то нигде не указано, но стандартные вынос свойств вроде таки не допускают.

Вполне положительно. Оно и само по себе ускорилось в нескольких местах крайне заметно, да и возможностей для тюнинга таблиц больше (хотя здесь конечно есть большой  вопрос еще, как оно все будет с обновлениями жить).

Аналогичное, пока сайт делался, собач... Битрикс успел подрасти на версию.

1. На сервер поставлен свежий Битрикс 4.x
2. Залиты шаблоны и структура базы (ибо она для 4.x была), сгенерированные с локальной инсталляции.
3. Апдейт версии на сервере до 5.x.

Собственно и все. Походу еще там с кодировками гемморой был, но это понятно.

Плюс еще были вынесены в отдельные таблицы свойства инфоблоков и перевязаны дополнительными индексами, но это уже детали.

Из реальной практики -- ноутбук IBM ThinkPad X41 Tablet (512-Гбайт ОЗУ, Pentium M какой-то средненький, довольно сильно фрагментированный диск) спокойно держал интенсивное насилие со стороны трех юзеров (они добавляли/правили с частотой где-то 3 материала в минуту

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

В первом случае БУС играет роль фреймворка и задача решается тривиально, но требует довольно квалифицированнгого разработчика (который заточит логику), во-вторым -- придется мириться с ограничениями.

Упс... Я, собственно, об этом

http://www.bitrix.ru/help/source/iblock/help/ru/developer/infoblock2.php.html

Мы пробовали OpenSTA -- до 30 одновременных активных юзеров (дальше просто канал кончился на сервере P4/2Гбайт/300 Гбайт, 10-Мбит канал (не боевой, тестовый сервак, пропускная способность ограничена шейпером).

Но -- отмечу -- там у нас есть свои засады.

После кэширования все еще быстрее.