Dios__deactivated (Все сообщения пользователя)

Плохое описание задачи, нечего не понятно.

Разделы каталога добавляются через "*.menu_ext.php" файлы, например компонентом bitrix:eshop.menu.sections

Пример из демо магазина:


Формат ссылок на разделы задается в настройка инфоблока каталога.

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

Это конечно да, часто встречаю такие работы, но это облегчает жизнь ТОЛЬКО разработчику, так как большая часть заказчиков не может проверить качество работы. Дорабатывать и обновлять сайт владельцу весьма затруднительно.

Такие нетиповые решения не поддерживаются не кем кроме написавшего, а зачастую таковые пропадают с горизонта через некоторое время. Нет документации, не кто не проконсультирует. Когда такие сайты нужно доработать, то нужно влезать в чужой индусский код (в моем опыте такой код всегда индусский), владельцы сайта не могут обратиться к большинству разрабов, так как не кто не будет ковырять такой код, а если и будут то запросят больше денег чем делать сайт с нуля. Единственный предлагаемый сценарий это все сносить и делать по новому, что накладно.


Наработки можно делать и из типовых решений.

Активность пользователя дает или блокирует авторизацию.
Вхождение в группу дает или забирает права на доступ к разделам, функциям, услугам.

Удалять акки, сомнительное радикальное решение, на аккаунты вешается много связанной инфы за время активности, смотря какой у вас сайт. Удаляя аккаунты, нужно чистить их деятельность, например удалить их заказы. Я бы просто дезактивировал бы... чистил бы акки только неактивные больше 2х лет, например.




У вас задачи, как я вижу
1. Разрешить авторизацию пользователя сразу -> Отключение типовой проверки почты и активация аккаунта сразу.
2. Ограничить функционал временными рамками -> Вхождение в группу в диапазоне времени, выдача прав на функционал группе.
3. Снять ограничение времени по подтверждению почтового адреса -> Разработка своего механизма подтверждения почты.
4. Удаление левых аккаунтов без подтверждения почты -> Агент с зачисткой.



Думаю, должно существовать типовое решение для такой политики, без стадий разработки.

Маркетплейс и Идеи уже глянули?

Видео с ютуба нужно вручную редактировать.

Любая флеша с описанным поведением должна иметь:
Параметр '<param name="wmode" value="opaque" />'
и атрибут '<emb ed ... wmode="opaque"></embed>'.

wmode не рекомендуется выставлять в значение "transparent" из за меньшей производительности чем "opaque".

Если хтмл код флеши по порядку находиться после кода элементов, которые должны быть выше, то:
Родительскому элементу и элементу который должен быть выше флеши задаете стиль "z-index" c такими значениями, что бы у родительского всегда цифра была меньше чем элемента который должен быть выше.



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

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

Если вы хотите деактивацию пользователей не подтвердивших email по истечению определенного срока то:

Делаете обработчик события "OnAfterUserRegister", в обработчике добавляете вхождение в группу с временным интервалом, то есть сроком до подтверждения почты.

Код на вскидку







Дату вычисляете (Текущая + Нужный срок)

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

Пока что такие мысли... подумаю еще... Теоретически распространенная практика в инете, должно быть типовое-простое решение.

"очень большого количества записей выборки. " - нужны цифры, кол записей и обьем как мин.
"Попытался вытащить огромное количество записей прямым запросом к БД, " - фу фу фу

Также нужна инфа о хостинге и тарифе.

Базу большинства сайтов можно получить всю за несколько секунд или даже меньше.


Также покажите код запросов и удостоверьтесь что вешается мускул, а не пхп, может у вас просто напросто пхп дает крит, а ошибку не выводит.

Весьма запутанное описание, я бы не стал бы браться с такой постановкой.
Рекомендую сделать\заказать\затребовать дизайн-макет.


Функции являются частью API, как они работают смотрите в официальной документации. Но не знаю как они вам помогут в вашей ситуации.

Судя по путанице в описании задачи, у вас есть пробелы в базовой терминологии, вы не прошли базовые курсы и не прочитали документацию разработчика. Что рекомендую незамедлительно проделать.

По описанию вроде вам достаточно типового функционала. В документации есть руководство и примеры публикации и настройки каталога и меню каталога. Но все таки мутное описания, сложно говорить наверняка.

bitrix 8.51 чрезвычайно устарел, врятли кто то будет ковыряться что бы исправить такую ошибку, когда она с 99% вероятностью уже исправлена.

На вскидку:
Код который выводиться должен был выполняться. Начать стоит с отладки в файрбаге и смотреть обработчик нажатия кнопки, отловить ошибки если есть и исправить. Дальше только детальное изучение подобных запросов...

Если ошибка была не всегда (что скорее всего так и есть) то можете сравнить слепки резервных копий. Софт для пакетного сравнение файлов и папок в гугле. Файлы отвечающие за такую работу находятся в тех местах куда не кто лазить не должен, не при работе сайта, не при разработке.

Еще вариант усиленно гуглить может у кого была ошибка...


Проще всего обновиться. Хотя при обновлении с такой древней версии могут быть трудности.

Кажется вы немного углубились не туда, вы можете задавать вхождение пользователя в группу в диапазоне времени, а доступ к определенным функциям и разделам давать по условию вхождения в группу.

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

alextrust не подвергаю сомнению ваши навыки, но из моего опыта:


Использование типовых компонентов имеет смысл:
* Официальная тех-поддержка владельцев сайта разработчиками платформы.
* Бесплатное и простое обновление и исправление кода.
* (предположительно) сотни тысячи тестеров. Код работает при самых разных сценариях.
* С разработчика сайта снимаются больший объем перечисленных обязанностей.
* Владелец сайта не должен нанимать программистов что бы обновлять и дорабатывать функционал.

Меня периодически просят доработать сайты, случаи с не типовыми компонентами весьма сложны, код неопрятен, не оптимален, устарел API, устарела верстка.

Самое главное что разбираться с чужим кодом неоправданно сложно. Каждый может CMS написать. А смысл когда все готово? тем более владелец оплатил лицензию за готовое.

Код платформы вытачивается с учетом множества мнений, проверок, тестов, стандартов, сертификаций и тд.

Просто мнение не в упрек.


bonterkoz
Настройки ЧПУ ссылок в настройках инфоблока. Также формат ЧПУ ссылок нужно повторить и в вызове компонента.

http://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=18&LESSON_ID=944
http://dev.1c-bitrix.ru/user_help/content/iblock/iblock_edit.php



Для справки:
 В админ разделах сверху-слева есть ссылка "Помощь". Она ведет на документацию текущего открытого раздела.

Ответ 42... вы не задали вопрос...

При использовании любого компонента вообще, первый шаг - изучение документации компонента.

Все параметры и их значения описаны.

Для каталога
http://dev.1c-bitrix.ru/user_help/content/iblock/components_2/catalog/catalog.php

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

Думаю есть распространенная потребность в сопоставлении пользователей на сайте с контрагентами в 1с. ИНН и Наименование по мнению наших спецов по 1с(и моему) не является подходящим критерием сопоставления.

Думаю для такой цели логично использовать XML_ID. Использование данного поля обеспечит достоверность, надежность и устранит человеческий фактор.

Возможно использовать XML_ID не правильно с точки зрения объектно-ориентированного программирования, так как контрагент не есть пользователь, но это решило бы задачу на уровень качественней чем ИНН.

Я предлагаю:

1. Добавить в файл обмена поле XML_ID для контрагентов
   
2. Вариант а:
    В настройках модуля "интернет-магазин" в закладку "Экспорт в "1С:Предприятие"" добавить вариант заполнения "Параметр пользователя - XML_ID"
   Вариант б:
    В настройках модуля "интернет-магазин" в закладку "Експорт в 1с" добавить варианты заполнения пользовательскими полями
   
3. В механизм обмена на стороне 1с добавить сопоставление контрагентов по XML_ID.
   

Данные настройки были бы очень полезны в работе обмена в связке с импортом пользователей из 1с (csv импорт в моем случае) в автоматичном или полу-автоматичном режиме. В такой схеме 1с имела бы полный контроль над пользовательскими аккаунтами на сайте, контролировала бы логин\пасс, добавляла бы свой XML_ID в пользовательское свойство (для соблюдения правил объектно-ориентированного программирования), выносила бы контактные данные. Клиентская база должна быть едина(очевидность), а редактирование свой инфы контрагентом думаю не есть хорошо(1с-спецы согласны).

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


Данное предложение направлю в ТП, хоть там все и так все знают но возможно моя месага добавит весу и кто то и обратит внимание на проблему, тем не менее, я могу чего то не знать или не понимать по этому выношу на обсуждение.

Предложения\обсуждения\советы что то дописать\переделать в коде - полезны (за них отдельное спасибо), но не есть цель темы так как я считаю данные фичи востребованными в типовом функционале.

Орудовать напильником и сами могем , но Битрикс для того и сделан, что бы упрощать людям жизнь. (я так думаю:) )

Element_ID - уникальный идентификатор в базе mysql(мускул) для элементов инфоблока
Section_ID - уникальный идентификатор в базе mysql(мускул) для разделов инфоблока

открываете раздел и видете ID, это Section_ID, аналогично с Element_ID

Первый скрин указывает на Element_ID так как там список элементов инфоблока, второй скрин не знаю на что указывает, скорее всего свойство типа число, но не факт..

Рекомендую пройти курс онлайн обучения или прочитать руководства по администрированию и управлению сайтом. Это очень простые вопросы которые не должны возникать у новичков. Задача по привязке альбомов к новостям является среднего уровня администрирования или уровень прогер новичек. Данные уровни полностью покрывает официальная документация.

Использовать кириллицу в url не рекомендую (есть подвижки в мире для поддержки, но рано еще)

Вариант 1
  Добавить к инфоблоку новости множественное свойство файл и в него грузить фотографии.

Вариант 2
  Для того что бы прикреплять альбомы из фото-галереи к новостям, добавьте свойство "Привязка к элементам" или к разделам, в зависимости от реализации альбомов, а в шаблоне детального просмотра новости добавьте вызов альбома по свойству.

Вариант 3 (предположительный и не точный)
  Если у вас фото-галерея реализована не на основе инфоблоков(я не знаком с работой модуля Фотогалерея 2.0), то вам как и в вар2 нужно в шаблоне детального просмотра новости добавить вызов альбома по свойству но уже тем компонентом который используется в "Фотогалерея 2.0" с нужного типа идентификацией альбома через дополнительное свойство новости(предположительно ID - целое число).


Кстате, не понял как данный вопрос пересекается с вопросом о шаблонах ссылок.




Добавлено
а увидел разные авторы...
Вопрос шаблонов ссылок не очень понял но на скрине у вас #SECTION_ID#/#ELEMENT_ID#
то есть ссылка на фото
mysite.ru/#КАТАЛОГ_ЧПУ#/#SECTION_ID#/#ELEMENT_ID#
пример
mysite.ru/gallery/542/2548

КАТАЛОГ ЧПУ у вас похоже не правильно заполнен
Этот параметр скажем является корнем раздела для работы компонента. Все остальные шаблоны приписываются к нему при использовании.
то есть следуя вашему примеру параметр должен содержать "/Фотогалерея/"
то есть результирующие ссылки будут
mysite.ru/Фотогалерея/#SECTION_ID#/#ELEMENT_ID#

но снова же не рекомендую кириллицу.

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

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

Мой инструментарий для верстки и js "total commander + akelpad". Чисто мой стиль работы, у всех по разному. Можете использовать более продвинутые IDE.

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

не проще ли в вызове компонента задать фильтр по дате публикации не старше недели ? если нужно за текущую неделю, то просто в параметрах на пхп задаете дату прошлого понедельника

"не подгружаются скрипты" - не является описанием проблемы.
Каков статус\текст ошибки? Есть ли подключение в исходном коде страницы(ответа сервера) ?
404 - не найден файл, проверьте путь
403 - не доступа, проверьте права на файл
Отладка делается через firebug(например).

Если в html коде не описано подключение файлов то проверьте шаблон.

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

Снова же, рассрочки в типовом функционале нету и
"система" не чего не возьмет и не че не сделает.

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

В любом случае без навыков программирования задача не решаема.

По поводу связаться - не могу, так как у меня уже на неделе повисло пару халявщиков с форума, а на основную работу времени не хватает(тут я для отдыха мозгов). Может через неделю.

"ИНН" является свойством заказа, обязательность свойств заказов задается в админке /bitrix/admin/sale_order_props.php
Отредактируйте там нужные свойства и компонент sale.order.ajax будет требовать заполнение этих полей при заказе.

Тут ключевой момент, это способы оплаты... Если вы хотите что бы клиент через сайт делал предоплату и потом помесячные платежи(с напоминаниями по почте), то это не типовой функционал и надо уже программисту согласно ТЗ думать как организовать данные фичи.

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

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

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

Просто калькулятор это XHTML\CSS\JS (то есть легкотня), на стороне битрикса как вариант тарифные планы можно забить отдельными инфоблоками, а на странице товара вывести доп компонент с калькулятором.

Что бы точно знать как устроить нужно подробное описание всех схем кредитования.

http://localhost:81 - хост лучше не задавать в шаблоне, а использовать абсолютную линку от корня сайта, тогда у вас не будет проблем при переносе сайта на рабочий хостинг или какой либо смене домена, или копирования шаблона на другой сайт.

Вы через пару дней\неделю\месяц забутите эти строчки кода и будите часами искать почему у вас картинки не отображаются...

Создание миниатюр лучше вынести в файл "result_modifier.php"
http://dev.1c-bitrix.ru/api_help/main/general/component20/13.result_modifier.php

Может быть станет интересная эта статья
http://dev.1c-bitrix.ru/docs/articles/develop/277171/

Что вы называете распределением? Все заказы в одной базе и просматриваются на одной странице. Фильтрация позволяет одному пользователю видеть один список, а другому пользователю другой список.

Или вы на фасаде выводите заказы? Или вы хотите на разные почтовые ящики слать?

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

например
Заказ принят
Заказ оплачен
Заказ доставлен


можно расширить
Заказ принят
Заказ оплачен
Заказ собран и проходит сертификацию
Заказ освещен священником
Заказ проходит таможню
Заказ обмываеться
Заказ доставлен

Ну это не правильно, как минимум не удобно

Вариант решения

Создайте свойство в
Рабочий стол - Магазин - Настройки магазина - Свойства заказа - Список свойств
/bitrix/admin/sale_order_props.php
Название "Магазин", Тип "Список", код не забудьте прописать и галочку ставите "Свойство доступно в фильтре по заказам"
Сохраняете

Снова открываете и добавляете варианты значения
1 "Киев - главный офис"
2 "Киев - ул. шоколадная"
3 "Нью йорк - буржуйское отделение"
Коды не забываете прописывать

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