• Как сделать в WORDPRESS геотаргетинг по городам?

    @alisov
    Плагин WT-GeoTargeting отечественных разработчиков, выводит гео-данные с помощью шорткодов или функцией do_shortcode, так же можно реализовать выбор города, вывод содержимого в зависимости от локации и др.
    Ответ написан
    Комментировать
  • Как получить курсы валют, относительно USD?

    mzcoding
    @mzcoding
    Web-Разработка
    Я использовал этот сервис https://openexchangerates.org/
    Правда там на фришном тарифе только 1000 запросов в месяц.
    Ответ написан
    Комментировать
  • Как получить курсы валют, относительно USD?

    Возьмите с сайта ЦБ России
    www.cbr.ru/scripts/Root.asp?PrtId=SXML
    Ответ написан
    Комментировать
  • Как получить курсы валют, относительно USD?

    SagePtr
    @SagePtr
    Еда - это святое
    Использую сервис Yahoo:
    https://query.yahooapis.com/v1/public/yql?q=select...
    Пары валют указываются через запятую в запросе, ограничение на 2000 запросов в час с одного IP, форматы - JSON, XML, JSONP
    Ответ написан
    Комментировать
  • Yii2: Как вывести input hidden?

    Frostealth
    @Frostealth
    Backend Developer
    <?= $form->field($doctorSearch, "specialization_id")->hiddenInput()->label(false) ?>
    Ответ написан
    Комментировать
  • Какой шаблонизатор использовать в WordPress?

    HeadOnFire
    @HeadOnFire
    PHP, Laravel & WordPress Evangelist
    Если вы пишете для себя / клиента - используйте что угодно. Впрочем, любой шаблонизатор даст вам свой overhead, я не вижу причин его использовать - у WordPress есть свой шаблонизатор. Да, он не ОПП, это не MVC, он у многих вызывает попоболь, но тем не менее он есть, он хорошо интегрирован со всем ядром и он прекрасно работает. Если вам религия не позволяет "напрямую же HTML в PHP лепить" - используйте Laravel с блейдом, зачем вы WordPress вообще взяли.

    Если пишете плагин для распространения (платный для Codecanyon, фришный для WordPress.org) - тогда используйте нативный шаблонизатор и не усложняйте людям жизнь. Любой разраб под WP уже умеет работать с нативными шаблонами, template functions и тд. Не заставляйте его разбираться с вашими велосипедами (даже если это известный шаблонизатор типа Twig). Посмотрите как реализовано у WooCommerce - в папке плагина есть папочка с темплейтами, и есть функция для подключения темплейтов, которая сначала смотрит, если ли аналогичный темплейт в папке темы. Таким образом разработчики могут легко переопределять ваши шаблоны.
    Ответ написан
    Комментировать
  • Виновен ли я в самописном движке?

    iiifx
    @iiifx
    PHP, OOP, SOLID, Yii2, Composer, PHPStorm
    > Подскажите, что я неправильно так же сделал, как начинающий кодер?

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

    Есть такое правило: Чтобы написать свою первую строку хорошего кода вы должны сперва написать миллион строк плохого. Это костыли, велосипеды, неудачные и даже брошенные проекты. Никуда от этого не деться, у всех так и вы не исключение. Если вы будете делать проекты на одних лишь вордперссах, то никогда так ничему и не научитесь. То есть научитесь ровно тому, что умеет вордпресс. А умеет он... ничего. Так и останетесь шаблонным "веб-мастером", который вроде как и умеет что-то, но ничего особенного из себя не представляет. Всегда изучайте и пробуйте что-то новое, чтобы каждая завершенная неделя давала вам хоть и небольшие, но новые знания.
    Ответ написан
    6 комментариев
  • SaaS: одна БД на клиента, или общая база данных?

    abarmot
    @abarmot
    Решал аналогичную задачу и столкнулся с теми же вопросами, что и вы.

    С одной стороны по базе на клиента — недопустимое расточительство. Как правило саасы подразумевают тысячи компаний-клиентов, а тем кто просто зайдет посмотреть не будет числа.

    Если же база одна — в скором времени какая-нибудь быстро растущая таблица станет «неуправляемой» и серьезно просадит производительность. Конечно можно разносить такие таблицы на партиции, но в нашей ситуации есть более интересное решение.

    Надо держать несколько БД и в каждой несколько сотен компаний. При этом новые базы можно добавлять по мере развития.
    Какое-то время вам вообще будет достаточно одной базы.

    Несколько рекомендаций:

    1. одну из БД (очевидно первую) назначаем мастер- или «системной» базой. только в ней будет хранится данные общие для всей системы. Например новости вашей системы, глобальные настройки и конечно главное — список компаний клиентов.

    2. во все таблицы с клиентскими данными внести поле COMPANY_ID. Более того внести его в состав всех первичных и внешних ключей. Т… е. первичный ключ таблички ORDER будет (COMPANY_ID, ID)

    3. ID инкрементировать в рамках компании, а не всей таблицы. Т.е. у каждой компании будет заказ с ID = 1,
    2 и т.д.

    Пример:

    COMPANY (id, name) — «системная» таблица с компаниями-клиентами

    ORDER( company_id, id, customer ) — «клиентская» таблица заказов
    PRODUCT( company_id, id, name ) — каталог товаров компании
    ORDER_ITEM( company_id, order_id, product_id) — продукты в заказе

    первичные ключи:
    в ORDER и PRODUCT — (company_id, id)
    в ORDER_ITEM — (company_id, order_id, product_id)

    внешние ключи в ORDER_ITEM:
    (company_id, order_id) → ORDER( company_id, id)
    (company_id, product_id) → PRODUCT( company_id, id)

    Такой подход дает во-первых максимальную изолированность данных компании.
    Во-вторых — возможность переселиения компания из одной БД в другую без конфликта первычных ключей.

    Если будут вопросы — пишите в местную почту ;)
    Удачи.
    Ответ написан
    3 комментария