Да, я в курсе. В этом случае всю платежную инфу хранит у себя процессинговый центр, который как раз и сертифицирован по PCI DSS, ну и еще до кучи всяких требований к нему :)
Законно, если пройдена сертификация PCI DSS. В большинстве случаев это слишком дорого и технически сложно, поэтому платежные данные не хранятся на стороне продавца. Но в случае на самом деле больших продавцов (в т.ч. упомянутого BA) это имеет смысл, т.к. значительно упрощает процесс продажи, условно — в один клик, т.к. клиенту ничего не требуется дополнительно вводить повторно.
У кого-то был опыт работы с Axure и Sketch? В Axure приходилось немало работать, а вот про Sketch узнал впервые. Интересно было бы сравнить возможности и удобства работы в Sketch и Axure.
Я имел ввиду не тег внизу под текстом. А сам тип текста — перевод. Это делается в настройках статьи. Тогда просто статья сразу отмечается как перевод. Например: habrahabr.ru/post/259197
Лучше отметьте свою публикацию как перевод. Сейчас это выглядит как новая статья. А вообще какой смысл было это вообще переводить, ведь все уже сделано давно за Вас: github.com/yiisoft/yii2/tree/master/docs/guide-ru
Не так давно использовал в одном своем проекте. Действительно удобно, хотя написание комментариев для apidoc утомляет. Между прочим, я так и не понял, как использовать версионность в apidoc, т.е. каким образом оно различает, что вот этот вариант — из версии 1.0, а этот — из версии 1.1? Посмотрел в Вашем примере — и все равно не понял. Можно какой-то реальный пример из жизни?
Может быть Вам стоит рассмотреть также площадки типа Udemy? Там в том числе и на русском выкладывают курсы. Возможно, имеет смысл сделать пару вводных курсов бесплатными, чтобы народ поверил в Вас как толкового преподавателя. Я по себе ориентируюсь — взял несколько курсов бесплатно у одного преподавателя, понравился его стиль изложения и теперь также покупаю его платные курсы.
Уважаемые человеки, ответившие выше по ветке :) Прошу не считать меня проповедником этой CMS. Мне она нравится, использую для разработки многих сайтов, но не зациклен на ней одной. И я не собираюсь разводить здесь холивар относительно того, какая CMS круче, удобнее, гибче, ..., «лично твое главное требование» к CMS.
Пожалуй, я соглашусь с комментарием zikkuratvk в отношении того, что CMS нужно выбирать под определенные условия. Или даже создавать ее с нуля на основе выбранного фреймворка. И да, хранение кода в базе данных мне тоже не нравится, я так и написал в первом комментарии. Тем не менее, остальные достоинства этой системы данное неудобство лично для меня перекрывают этот и другие недостатки MODX при разработке сайтов указанного выше уровня. Может быть даже вполне, что в MODX 3 исправят и это. Ну, будет круто. Посмотрим.
что-то среднее между джумлой и нормальным взрослым фреймворком, типа Yii.
Есть определенная правда в Ваших словах. Хотя все же не совсем корректно, пожалуй, сравнивать CMS и голый фреймворк. У MODX есть определенные части фреймворка (API, например, хоть и правда не в лучшем его виде), а в большей мере все же это готовая к использованию CMS.
Когда то главной фишкой там было хранение шаблонов, сниппетов (php кода) в базе данных, а при исполнении кеширование этого в php файлы
Никогда не считал это главной фишкой MODX'a. Да и в принципе мне эта идея хранения кода в БД не особенно нравится, но и не могу сказать, что сильно страдаю от этого. Я бы назвал главными фишками MODX — удобство работы в админ-панели + практически полная свобода в плане оформления внешней части сайта (этим ограничением страдают многие «конкуренты» — упомянутая Вами Joomla, Wordpress, etc).
Не до конца понимаю, кто им пользуется. Но судя по сообществу — пользуются :)
Пользуются — и, кстати, очень многие пользуются. MODX уже давно один из лидеров Open Source CMS. Я бы обозначил рамки его применения как малые и средние сайты корпоративного сектора.
Крупные проекты на текущей версии MODX Revo строить уже на самом деле тяжело — влияет в том числе то, о чем пишет автор статьи про синдром «это придумали не мы». Для таких целей и предназначены фреймворки типа Yii, Laravel, etc. Использовать данные фреймворки для разработки малого или среднего размера сайта — это как из пушки по воробьям. Можно, но не имеет смысла. Проще взять готовую систему управления контентом — и в данном случае MODX будет почти идеальным решением.
Ну и вот MODX 3, кажется, должен максимально избавиться от наследованных проблем Evo/Revo. Посмотрим :) Пока звучит интересно.
Живу в одной стране все-таки недоразвитого капитализма (по личным ощущениям) — Латвии. Для примера — тарифы на депозиты двух банков: www.citadele.lv/ru/tariffs/savings/fixed/ и www.swedbank.lv/ru/cenradis/termindepozits#procentu_likmes. В общем, годовая ставка в EUR/USD в лучшем случае дотягивает до 1%. Если находишь 2% и выше, то это просто праздник какой-то. Когда-то до кризиса ставки были значимо выше. Но это всё связано с уровнем инфляции и межбанковских ставок, которые на текущий момент у нуля.
Спасибо за отзыв :) Сайт бесконечно еще дорабатывать можно, чем мы, собственно, и продолжаем заниматься с момента запуска.
А статья не только в минус уходила, так еще и я личный бан получил за нее в виде read-only :) Правда, потом админы хабра почему-то решили, что меня все-таки можно вернуть. Такой вот загадочный хабр :)
Мне кажется это 2 большие разные непересекающиеся группы девелоперов
В принципе да, я согласен, что разработчики в итоге выбирают что-то одно. Но вести два параллельных проекта довольно сложно. Ох, страшно подумать, что будет, когда выйдет MODX 3 :)
Дарю идею: если бы вы сделали cheatsheet по MODx по основным сниппетам, плейсхолдерам
Спасибо, идея действительно отличная. Нужно подумать, когда и как это реализовать.
Если долго смотреть в бездну, то бездна начинает смотреть на тебя :)
Тут можете посмотреть https://symfony.com/doc/current/configuration.html#configuration-based-on-environment-variables
Тут, конечно, кому как… :) Но я вот ничего интересного тут не увидел, чего не было уже на сотнях аналогичных сайтов и в самой документации.
Не сочтите за рекламу — я никак не аффилирован с этим человеком, но вот у этого автора www.elisdn.ru/blog/60/seo-service-on-yii2-installing-of-application действительно есть интересные статьи по Yii2 на русском. Правда, структурировано через ж..., поэтому лучше поискать так: goo.gl/yC43hN
Я имел ввиду не тег внизу под текстом. А сам тип текста — перевод. Это делается в настройках статьи. Тогда просто статья сразу отмечается как перевод. Например: habrahabr.ru/post/259197
Пожалуй, я соглашусь с комментарием zikkuratvk в отношении того, что CMS нужно выбирать под определенные условия. Или даже создавать ее с нуля на основе выбранного фреймворка. И да, хранение кода в базе данных мне тоже не нравится, я так и написал в первом комментарии. Тем не менее, остальные достоинства этой системы данное неудобство лично для меня перекрывают этот и другие недостатки MODX при разработке сайтов указанного выше уровня. Может быть даже вполне, что в MODX 3 исправят и это. Ну, будет круто. Посмотрим.
Есть определенная правда в Ваших словах. Хотя все же не совсем корректно, пожалуй, сравнивать CMS и голый фреймворк. У MODX есть определенные части фреймворка (API, например, хоть и правда не в лучшем его виде), а в большей мере все же это готовая к использованию CMS.
Никогда не считал это главной фишкой MODX'a. Да и в принципе мне эта идея хранения кода в БД не особенно нравится, но и не могу сказать, что сильно страдаю от этого. Я бы назвал главными фишками MODX — удобство работы в админ-панели + практически полная свобода в плане оформления внешней части сайта (этим ограничением страдают многие «конкуренты» — упомянутая Вами Joomla, Wordpress, etc).
Пользуются — и, кстати, очень многие пользуются. MODX уже давно один из лидеров Open Source CMS. Я бы обозначил рамки его применения как малые и средние сайты корпоративного сектора.
Крупные проекты на текущей версии MODX Revo строить уже на самом деле тяжело — влияет в том числе то, о чем пишет автор статьи про синдром «это придумали не мы». Для таких целей и предназначены фреймворки типа Yii, Laravel, etc. Использовать данные фреймворки для разработки малого или среднего размера сайта — это как из пушки по воробьям. Можно, но не имеет смысла. Проще взять готовую систему управления контентом — и в данном случае MODX будет почти идеальным решением.
Ну и вот MODX 3, кажется, должен максимально избавиться от наследованных проблем Evo/Revo. Посмотрим :) Пока звучит интересно.
А статья не только в минус уходила, так еще и я личный бан получил за нее в виде read-only :) Правда, потом админы хабра почему-то решили, что меня все-таки можно вернуть. Такой вот загадочный хабр :)
В принципе да, я согласен, что разработчики в итоге выбирают что-то одно. Но вести два параллельных проекта довольно сложно. Ох, страшно подумать, что будет, когда выйдет MODX 3 :)
Спасибо, идея действительно отличная. Нужно подумать, когда и как это реализовать.