Совсем недавно у меня закончились очередные . С удивлением обнаружил много нового и интересного, появившегося в 1С-Битрикс с прошлого лета, когда вел предыдущие курсы.
Решил тут не отставать от моды, но и слепо ей не следовать. И выразилось это в размещение кнопок расшаривания, но не тупо скопом все что есть в Интернет, а некоторые.
Решил протестировать новый хостинг, заливаю резервную копию и на тебе ошибка распаковки:
Fatal error: Unknown: Failed opening required '/var/www/vhosts/xxxxxxx.xx/httpdocs/bitrix/modules/security/tools/start.php' (include_path='.;C:\php5\pear') in Unknown on line 0
Не могу понять, а в чем подкол. Захожу через FTP и что вижу, в корне появился htaccess.backup и при этом имеется htaccess. При сравнении и было замечено, что прописан путь со старого хостинга.
Всему причина "Веб-антивирус". При запуске он изменяет .htaccess!
Одно решение, залив к себе архив, изменить путь в htaccess.
Пример задачи: на битриксе без веб аналитики регистрировать страницы 404. Это обычно либо ошибочные ссылки на картинки, либо переходы с внешних источников на изменённые разделы. В первом случае надо вносить исправления (может сказаться на производительности, упоминал об этом в конце ), во втором - ставить редиректы.
Рад представить вашему вниманию первый номер журнала ВЕБ-АНАЛИТИК.ИНФО, который распространяется на бесплатной основе в формате PDF и доступен на сайте издания по адресу в Интернете: .
Первый номер журнала WEB-ANALITIK.INFO предложит вам массу разнообразной тематической информации. Как видно из названия журнала, основная тематика издания – это Интернет-Технологиии и все что с ними связанно. Нам интересны такие направления как: Хостинг, Базы данных, CMS (системы управления сайтом), SEO (поисковая оптимизация), Веб-Разработки, Веб-Дизайн, Антивирусы, Интернет проекты, Программы, Игры online и многое другое. В частности для первого номера журнала мы решили подобрать статьи в большей степени начального уровня. То есть, мы хотели сделать этот номер некой начальной и отправной точкой.
Кроме этого мы призываем всех заинтересованных людей принять участие в становлении журнала. Это, прежде всего, касается авторов, которые могут делать качественный и интересный материал. На сайте журнала для авторов имеется свой раздел, где вы можете найти информацию о том, как стать одним из наших постоянных авторов.
Решил поделится мнение, а заодно узнать мнение других разработчиков, на тему разделение стилей и скриптов по шаблонам компонентов.
Мое личное мнение это зло, которое способствует долгой загрузке сайта на клиенте. Для примера, страница написания нового сообщения в блог на этом сайте:
Видим 15! файлов стилей, то есть 15 http запросов необходимо делать браузеру чтобы получить стили. Мало того эти запросы съедают ресурсы сервера на котором находится сайт, даже при наличии nginx, по чуть чуть но съедают.
Философия что шаблон компонента должен быть независимым конечно хороша, если используются шаблоны повторно. А если они не будут использоваться повторно? На большинстве проектов представление и логика сильно отличаются от предыдущих проектов, да если что вытащить стили из общего файла не так уж и сложно.
Хочется узнать мнение других разработчиков, чем больше сайтов вижу на битриксе тем больше убеждаюсь что большинство разделяет стили и скрипты (скрипты не всегда) по шаблонам компонентов.
Попросили тут меня создать подфорум на форуме. Зная, что в Битриксе стандартно это не сделать, я уже собирался сказать "никак...", как вдруг меня осенило.
Попробовал рассказать , почему маленькой компании (в которой только одна группа разработчиков) не получится делать большие и маленькие проекты одновременно.
Специфика продукта в его модульности. Это накладывает свои нюансы в разработке. Один из них: у пользователя сайта разные аватары для блогов и форума. А социальная сеть хранит фотографию в свойствах пользователя. Такая "фича" понятна не всем пользователям, можно написать обработчик, который автоматически будет создавать нужные копии аватара.
Занимаясь сайтами и настройкой веб-серверов уже более 10 лет, встречал совершенно разные ситуации с работой сайта. Часто бывает так, что сайт написан «криво», и при повышении посещаемости или при росте контента на сайте он начинает дико тормозить. Есть ли возможность заранее это предусмотреть?
Когда речь заходит о поисковой оптимизации, возникает ощущение, что касаешься чего-то волшебного. SEO оптимизаторы для меня - это некие шаманы, пытающиеся ублажить могучих Богов поиска. Они не говорят иначе как "поисковики любят" и "поисковики не любят" SEO рекомендации зачастую противоречат здравому смыслу, но они работают. Примечательно, что на основе "анализа" сайтов оптимизаторы часто дают одни и те же рекомендации. Пару из них мне посчастливилось выполнить.
Оказывается, если в настройках сайта не прописано имя сайта, то, если у вас есть две разных копии битрикс (разных!) на доменах типа site.ru (здесь в настройках был прописан site.ru) и portal.site.ru (здесь в настройках сайта стояло пустое имя), то между ними можно гулять, авторизовавшись на одном из сайтов. Даже если на втором этого пользователя нет.
В визуальном редакторе, в «Свойствах», есть раскрывающийся список «Стили». В редакциях на PHP это список стилей, определённых разработчиком. В ASP.NET этот список пуст. Я понимаю: не доделали, руки не дошли. Но это ОЧЕНЬ существенная недоделка. Мои редакторы сайта действительно не знают CSS и HTML, они не смогут применить стиль в исходном коде. Ну ведь несложно же сделать что-то вроде того, что есть в редакциях PHP, или хотя бы предусмотреть ввод имени стиля в текстовом поле.
При загрузке изображения с расширением jpeg: изображение загружается, но в списке изображений на сервере не отображается, так что вставить его средствами визуального редактора нельзя. Это именно Битрикса проблема, на сервере это расширение зарегистрировано и эти файлы обрабатываются хорошо. Я так понимаю, что забыли включить расширение в разрешённых в том классе, что отображает список файлов. Исправить легко.
В последнее время в связи с распространением кор. портала, стали появляться задачи интеграции сайта с AD, 1С:ЗУП и даже с ними одновременно. Именно последний вариант мы и рассмотрим в данной статье.
Возможно, у кого-то есть опыт. В настоящий момент имеется выделенный сервер HP Proliant BL460 (вроде) (2 4-х ядерных процессора /5 Гб RAM), на котором работает сайт (мини-портал), посещаемость около 40 тыс. страниц в день. (около 3-4 тыс посетителей), сервер БД на отдельном сервере. Загрузка - меньше 1-цы в среднем. Бывает увеличение посещаемости в 3-4 раза. Нужно где-то разместить еще один сайт со сравнимой посещаемостью + сервер БД для него). Важно, чтобы это были физически разные сервера или виртуальные машины, по внутренним соображениям безопасности Серверная операционка - RedHat EL 5.
Вот мне интересно, если я сделаю на железном сервере виртуализацию и запихну оба сайта в виртуальные машины на базе KVM, не будет сбоев? Кто-то сталкивался? Заранее благодарен за ответы.
Продолжаем тему . На сей раз опишу потенциальную проблему, с которой можно столкнуться при написании своих компонент. В качестве примера берем типовой bitrix:news.list.
Почти полтора года назад, спустя некоторое время после выхода 1с-битрикс с поддержкой utf кодировки, я принудительно перевел всю разработку в utf, поскольку читаю, что это в обозримой перспективе (3-5 лет) позволит снять вопрос с перекодировкой при обновлении сайта на новую версию.
Однако, конкретно на "сейчас" мы каких-либо ощутимых выгод от перехода на данную кодировку не получили. Что же получили?
Пару раз видел жалобы на кеширование в битриксе. Мол новость изменил, а на сайте она не изменилась. Думаю, причина проблемы всем известна - при изменении данных в админке (в данном случае - инфоблоки) кеш компонентов использующих эти данные не очищается.
Решения два: 1) После изменений идти в публичку и сбрасывать кеш компонентов 2) Автоматизировать процесс очистки
class MyHandler {
public function IBlockClearCache(&$arFields)
{
if(!$arFields["RESULT"] || $arFields["WF_PARENT_ELEMENT_ID"] || $USER->GetLogin() == "1CIntegration") return false;
// Массив хранящий ID инфоблока (ключ массива) и путь к кешу
$arIBlock2Component[3][] = "/ru/bitrix/news.list/";
$arIBlock2Component[3][] = "/ru/bitrix/news.detail/";
// Если для этого инфоблока есть пути для очищения, то очищаем их
if (count($arIBlock2Component[$arFields["IBLOCK_ID"]])) {
foreach ($arIBlock2Component[$arFields["IBLOCK_ID"]] as $cachePath) {
BXClearCache(true, $cachePath);
}
}
}
}
BXClearCache(true, $cachePath); true - удаляем весь кеш (устаревший и не устаревший) $cachePath - путь файлов кеша для компонента
Теперь все изменения будут видны посетителям сразу.
Пост скорее для новичков, ветеранам предлагаю поделиться своими решениями.
UPD: 1) Обновил обработчик - см. коммент 2) Убрал обработку события OnBeforeIBlockElementDelete т.к. для него передается только ID элемента. Выборку остальных полей реализовать не сложно, если очень нужно.