Задать вопрос
  • Отправить email в обратку тому, кто заполнил форму?

    @BorisKorobkov Куратор тега PHP
    Web developer
    Имеется форма, которая проверяет и отправляет письмо, проходя через php код.

    Сюда же допишите и отправку письма пользователю.
    Ответ написан
    9 комментариев
  • Какую редакцию Битрикс использовать?

    shambler81
    @shambler81 Куратор тега 1С-Битрикс
    по сути есть 3 редакции, все остальное это мелочи
    1. Стандарт - для всего кроме магазина
    2. малый бизнес -интернет магазин
    3. Бизнесс - интернет магазин с мультискладовостью и мультиценой.
    Ответ написан
    2 комментария
  • Какую редакцию Битрикс использовать?

    AlexeyGfi
    @AlexeyGfi
    YouTube >>> Битриксоид из Колхоза
    Это можно реализовать и на «Старте». У меня магазин с полноценной корзиной, оплатой, СМС-шлюзом, обработкой получения платежа...
    https://www.tiko-chako.ua/ru/
    Вообще, можно и на «Первом Сайте», но там ограничение по количеству инфоблоков и пользователям

    Coraelstraze: Алексей, но подразумевается, чем ниже редакция, тем должен быть выше уровень программирования?


    Нет. Требуемый уровень знаний программиста от разницы в редакции не зависит. API одинаков для всего фреймворка, хто это «Первый сайт», хоть «Корпоративный портал».
    Разница в редакции — это просто разный набор уже готовых решений. Предполагается, что имея набор готовых модулей, сайт должен собираться как конструктор: кирпичик+кирпичик+...= результат и радость.

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

    Вот таблица сравнений — можно прикинуть, что не нужно под задачу, но за что придётся заплатить:
    https://www.1c-bitrix.ru/products/cms/editions/#ta...

    Итак, давайте рассмотрим этап программирования, исходя из жизненных реалий.

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

    Предположим теперь, что покупаемый набор содержит то, что нужно (если чуть расширить функционал) и то, что не нужно (переплачиваете).
    Программисту нужно на основе API модулей, требующих доработок (либо кастомизацией компонентов/шаблонов), допилить функционал, натянуть дизайн.
    Имеет место несколько переплат: за ненужный функционал в наборе и за доработку неполного комплекта инструментов. Плюс не исключено, что исполняемый модуль будет в нагрузку к нужному генерить и не нужные телодвижения.
    Также, программист вынужден действовать в рамках предоставляемого набора модулей (мы ведь купили — давайте допиливать его), пока доработка не потребует кардинального решения под задачу.

    Тогда программист либо пишет своё решение на основе API, либо ищут решение на маркетплейсе:
    https://marketplace.1c-bitrix.ru/

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

    Даже если покупать на Маркетплейсе готовые решения (например, полностью собранный интернет-магазин), если сайт живёт и развивается, поддержка проекта потянет на ощутимый бюджет, который через пол-года–год уже может перекрыть затраты на первичную разработку. К тому же, при активном маркетинговом отделе, требуются постоянные доработки, чего разработчик решения делать не будет (не тематическая задача, слишком узкое решение). Готовое решение распиливается на составляющие, дорабатывается в нужном месте, но теряется возможность его обновления, если выпущен фикс или расширение, что для популярных решений происходит постоянно. Как вариант — ведётся лог локальных фиксов, накатываются обновления и поверх перенакатываются фиксы (ну вы уже поняли, что я прям по-живому пишу =) )

    Через год владелец молодого и динамически развивающегося проекта смотрит на текущую ситуацию, оглядывается назад и понимает, что:

    Третий вариант: Битрикс покупается как основа, фреймворк под проект.

    Главные фишки Битрикса:
    • удобство управления (для менеджеров, секретарей, контентщиков, владельца) — ни одна CMS ещё не переплюнула Битрикс по крутости публичной части и удобству админки. Если я чего-то не знаю, буду благодарен, если кто-то в комментариях даст мне пример. Обращу отдельное внимание на тот факт, что я говорю об удобстве со стороны клиента, а его лояльность стоит дорого.
    • инфоблоки — прослойка для управления данными базы данных теми, кто ничего в них не смыслит. Новое ядро слегка размывает кайф, но пока ещё эта фишка сильна. Практически всё построено на принципе, когда-то родившем инфоблоки.

    Итак, Битрикс покупается как фреймворк и конкретно под задачу на основе API пишутся решения и покупаются/настраиваются модули. Плюс в том, что цена редакции «Старт» относительно дорогих редакций сравнительно невысока, а решения, которые выходят из-под «пера» программиста, заточены уже конкретно под дизайн и конкретно под задачу.

    В общем, как-то так.
    Ответ написан
    4 комментария