Андрей Николаев (Все сообщения пользователя)

Проверяли события?

Работать с данной СУБД через ORM.


Компоненты работают с таблицами модулей, а те, в свою очередь лежат в СУБД сайта.
Таким образом ни с какими компонентами в стандартной поставке Вы работать не можете (или это не та работа, которую вы подразумеваете)

1) Проверяемый пользователь должен:
- Быть активен
- Находиться в орг.структуре
- Иметь группы: Сотрудники (обычно 12), пользователи с правом на голос и авторитет (3 и 4 группы)

Для того чтобы пользователь попадал в эти группы, нужно чтобы на 3 странице настроек подключения к AD был соответсвующий маппинг и авторизуемый пользователь находился в этих группах!

2) Проверку этих параметром нужно проводить ПОСЛЕ того как пользователь залогинился, так как при логине происходит запрос к AD и данные ОБНОВЛЯЮТСЯ!

3) Поведение с переходом при входе на портал попадают на  /stream это нормальное поведение, т.к. главная страница может быть переопределена пользователем (дефолтно главная страница это живая лента - /stream/)

4) Выделенные права менять не нужно иначе любой НЕЗАЛОГИНЕНЫЙ пользователь сможет читать портал

Нет, так делать на корп. пораталах не нужно.


Либо Вы должны тянуть орг.структуру так же из AD
Либо Вы должны тянуть структуру из 1С в связке с АД
Либо Вы должны маппить руками (самостоятельно распределять после добавления) *

* - можно через php-код на событиях

Маппинг их в группу сотрудники не обеспечен или они не находятся в орг.структуре

1) Почта на сайте (на сервере у MTA) должна соответствовать отправителю письма. Т.е. если почта с сайта отправляется с noreply@site.ru, то и письмо о заказе должно отправляться с noreply@site.ru, но никак не sale@site.ru
2) Проверьте не только E-mail отправителя по-умолчанию с сайта, но и почтовый шаблон уведомления о заказе.

Мне кажется, что Вы сильно усложняете.

1) Посмотрите "средний чек" который есть у Вас в интернет-магазине, может быть больше 30 тысяч никто не покупает, а 99% людей заказывает на 5 тысяч.
2) Оттолкнитесь от чего Вы делаете эту наценку. Например, Вы страхуете груз или просто хотите больше денег - это разные политики. Попытайтесь найти "потолок" суммы с учетом истории заказов в интернет-магазине
3) Выработайте несколько простых правил.
Например, Вы выяснили что:
- 90% людей заказывает на 5 тысяч
- 4% на 10 тыс.
- 3% на 15тысяч
- 2% на 30 тысяч
- 1% на 60тысяч

Таким образом можно сделать несколько правил:
- Наценку в 150 рублей при заказе меньше 5 тысяч
- Наценку в 450 рублей при заказе меньше 15 тысяч
- 1 тысячу
- 6 тысяч

Ну или если уж совсем ничего не подходит, то всегда можно написать свой элемент для скидок

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



P.S. слово script нормально напишите, а то здесь редактор не дает.

Сергей Лещинский, а какая проблема то? Можете озвучить?

Это целая отдельная наука делать 2 независимых связанных решения.
Проще сделать 2 сайта с master-slave репликацией и чем-нибудь типа rsync взаимодействия.
Можно конечно для уменьшения использовать облачное хранилище для файлов.

И тогда можно ссылаться на 1 сайт, при его падении на 2 сервере говорить что он теперь мастер, переключать dns и работать, когда 1 заработает, сделать его slave и переключить синхронизацию.

Простой будет минимальный, но это будет равносильно двум серверам

P.S. Самый простой и топорный способ

Представляется. Всегда можно пересмотреть или верстку или компоненты переписать.
В конце концов можно саму форму изменить и загружать ее на ajax

У Вас место закончилось на диске

Что-то вроде того


P.S. Перезагрузка снимет симптом на какое-то время, но не решит проблемы

Добавив в исключение проактивного фильтра.



Запрос рвется не при выводе, а при сабмите

Omar Khazamov, можно без декодирования - проверять заголовки запроса. Так, например делает метод isAjaxRequest()

В $a у тебя при GetNext - объект. Если будет большое количество и попытка распечатать - упрешься в буфер памяти.
Попробуй достать ТОЛЬКО их и вывести на экран

P.S. Лучше ->fetch() используй, он вернет массив без всяких обработок

Выложи код .description.php

Артемий Зайцев, эм... кластер?)

А Вы пробовали достать одну ссылку и по ней пройти? Дело в том, что если картинки реально не существует, то вернется 404 страница ошибки.
Соответственно может получиться так, что картинки были, их закешировали, а потом удалили. Ссылки остались, но при попытке перехода там теперь страница

Вы храните массивые или объекты ?
Зачем Вам такое количество??

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

Удалите *.min.* и сбросьте кеш

Я об этом и говорил - при импорте из AD группы пользователя проставляются из маппинга групп, другие будут сброшены.

Не нужно так делать.
Решение приходит из поставленной задачи. Какая у Вас задача?

1) Включите в битриксе debug-режим
2) Включите в админке вывод сообщений обо всех ошибках
3) Дополнительно проверить error.log nginx (после выполнения предыдущих действий + повторения иммитации проблемы)

Есть архивация заказов (перемещение в другие таблицы с другим механизмом хранения данных)

Это не проблема битрикса, просто оба механизма пропускаются через буферизацию. А Вы не проверяете что этот хит аяксовый.


Не нужно так делать
Есть масса других способов достичь решения без внесения таких изменений.