Дешево и сердито использовать hangouts или тот же youtube, да вообще любой софт который позволит проводить вебинары у себя на сайте.
ТС, бери любую CMS и ищи сервисы для проведения вэбинаров (они и деньги позволяют принимать).
Если вы хотите сами такой сервис поднять, то тут слово "простенький" лишнее
Попробуйте добавить пару атрибутов к форме
<div class="social-likes" data-url="http://domen.ru/page.html" data-title="Название страницы">
Ответьте сами себе, вот вы поставили MySQL, сам по себе MySQL не умеет параллелить запросы, так вот вопрос, у вас много маленьких запросов или мало больших? В первом случае лучше больше ядер, так как будет больше обслуженных процессов (пользователей), во втором лучше частота, потому что будут запросы выполнятся быстрее. На столько равно и для PHP (это в случае вычислений, а так обычно PHP это прослойка между сервером и БД, которая ничего не вычисляет), то есть за один промежуток времени, 1 процесс php на ядре с больше частотой выполнит больше вычислений. Но большее число ядер сможет обслужить большее число процессов. Но по факту процессор всегда простаивает и я бы лучше взял то, где больше частота, на проектах с вменяемой, а не предельной по железу посещаемости.
Тут важен характер приложения и нагрузка на него. А такие вещи как nginx/apache действительно раньше упруться в память чем в процессор.---------- Добавлено 13.01.2017 в 19:15 ----------
Нет, не правильно. Процессор с частотой 2.5 всегда будет работать с частотой 2.5. Вы тут предложили родить 3 женщинам ребенка за 3 месяца.
Одно ядро процессора в один момент времени обрабатывает 1 процесс в системе. И каждый процесс обрабатывается со скоростью ядра. Но большее количество ядер в один момент времени позволяет обработать больше процессов. То есть ядра круто тогда, когда в операционке начинается очередь на ожидание процессорного времени, пока очереди нет, количество ядер никак не ускорят выполнение. То есть если у вас одно ядро и вы выполняете какое то вычисление, то все остальные процессы в системе ждут (типо распаковки архивов на древних процессорах), если у вас ядер больше, то и вычисления делаются и остальным процессам есть возможность трудиться
danforth, Подустал я что то вам доказывать если честно. Смысла нету, если вы пытаетесь доказать то, чего не знаете.
А это забыли тут просто так в репозитории Magento2. При том я не говорил что только симфони. Весь прикол симфони в том (и собственно её популярность) - это модульность. Это слабосвязанный фреймворк построенный на компонентах и любой компонент можно использовать в отрыве от других (встраивать в ваши приложения), хоть в магенто, хоть в друпале, да можете хоть в вордпресс воткнуть. При этом всегда остается возможность в любой момент подменить любой компонент на свою реализацию без переписывания всей системы.
Только в симфони, как и любом другом тоже всё это есть. Как и еще в 100500 разных CMS, и в ворпрессе в том числе. Только у вас для магазинов Магенто, для визиток вордпресс, прикольно наверное такой зоопарк технологий сопровождать? Делали бы тогда визитки на магенто или магазины на вордпрессе. Я лишь по вашим комментариям понимаю что вы даже свои инструменты не знаете достаточно хорошо. Наверное потому что распыляетесь. Или подождите, вы сейчас предложили натянуть 3 статических страницы на Magento2? Прям да, симфони тянуть не стоит.
Клиенту не важно, будет делать программист за 20$ или программист за 10$ или за 300$. Для клиента цена всеравно конечная. И почему вы считаете что программист за 10$ сделает быстрее чем тот что за 20$? В моей практики обычно наоборот, тот человек что с огромным опытом сделает за час, пусть и за 20$ работы столько, сколько программист за 5$ не сделает и за целый рабочий день. Есть должности, где квалификация особой роли не играет, но программирование не из них.
Что вы привязались к инструментам? Я не оцениваю разработчиков по знанию какой то технологии, я оцениваю по адекватности в основном. Сегодня инструмент популярен, завтра может быть мертв, зачем к нему привязываться? Хороший разработчик должен уметь отказываться от мертвых вещей в пользу новых, живых. И разработчики растут по опыту, меняют инструменты на более сподручные. Еще хороший разработчик с опытом меняет проекты/команды и должен, вот прям должен, уметь осваивать новые инструменты, а не строить из себя какого то там просветлителя. Привязались вы и говорите что одно не подходит, а другое подходит, а я говорю что подходит всё, когда ты владеешь этим в совершенстве и инструмент никак не влияет на стоимость конечного продукта, вообще никак. Точнее нет, влияет, обычно инструменты сокращают время разработки. Чем больше времени может сократить иснструмент, тем дешевле будет разработка и голый html это не тот инструмент уж поверьте. Сейчас даже голый html На голом html не пишут, не подскажите почему? Наверное все вокруг дураки один вы умный.
UPD. Все таки чтобы закончить этот нелепый спор, который идет непонятно куда, я просто хочу выразить коротко свою мысль. Если вам жалко времени натягивать верстку на любую cms, а это действительно требует времени, даже той же настройки. То все равно лучше натянуть верстку хотябы на фреймворк (и желательно популярный), у которого есть шаблонизатор и возможность быстро реализовать какие то базовые возможности, так как клиенту точно они понадобятся. А на голом html сайты лучше не делать, если это не лендинг. Для других типов сайтов с большой долей вероятности понадобятся эти доработки. вот так как то.
Ничего не мешает. Просто проще сразу сделать все за раз.
Не делайте с симфони монстра, она и для визиток норм. Дорого, потому что с ней в основном работают программисты с высшим образованием, а не джуны, которые только вчера закончили читать книгу "Wordpress за 24 часа для чайников". На самом деле где то я слышал очень хорошую фразу со смыслом: "Дороже профессионала - только любитель"
Ядро может пишут и профессионалы, но на голом ядре вы ничего делать не будете (кстати Magento2 тоже использует симфони в ядре, как и любая CMS современная имеет в ядре фреймворк). А вот "миллион бесплатных плагинов, которые удешевят разработку" пишут все кому не лень, даже те кто оч далек от программирования в целом. Так что это не аргументы, аргумент тут только один, что вы симфони знаете чуть больше чем никак, а вордпресс видимо хоть как то, по этому визитку на нем вам конечно сделать проще, а на хтмл и подавно, там вообще библиотекарь справиться, даже джун не нужен.
Margo239, я дико извиняюсь, но я админку Эво даже в глаза не видел :) Но в Рево это в настройках, и то если прав на это достаточно.
401 код означает — Неавторизованный запрос
Может сменились ключи/доступы к апи? Либо способ авторизации. Ну я бы копал в эту сторону.
Вы реально уверены что час работы проф адвоката по деньгам равен часу работы средненького программера который может ковырять сайт юр компании? Если вы станете хорошим адвокатом, у вас времени на чашечку кофе в тишине и одиночестве редко найдеться (как и у хорошего спеца в любой сфере), а о том чтобы что то как хобби ковырять — забудьте. Лучше как хобби подтягивайте что то профильное, чтобы ваши консультации стоили примерно как полет на луну и обратно😂 Лучше быть кем то в чем то одном, чем быть никем во всем
Это на собеседование что ли?
В самом JSON нет ошибок (синтаксисе), формат то примитивный. В данном случае используется валидация документа по конкретным правилам. Схема есть в самом ответе JSON по которой валидировать, а пример того как это делать на том же сайте
Если вы думаете что кто то это сделает за вас, ну хз хз :) Хотя судя по всему там и куча валидаторов
Староват ответ, но может кому пригодится.
Видимо в поле отправитель, у вас ставится пользовательский email. Мейл.ру запретил рассылать почту от своего имени и не со своих IP, DMARC называется. То есть вся почта автоматом реджектиться, даже не попадая в ящик и папку спам. То же происходит и с не существующими ящиками, так как обратно ящик не резолвится, ведь его нет на том хосте, почтовик считает все спамом. А вордпресс отправляет, потому что отправитель там какой нибудь noreply@вашдомен.ru---------- Добавлено 12.01.2017 в 01:08 ----------
Вам надо проверить что выводит [[!++site_url]]
Есть подозрение, что у вас просто не задана данная настройка. Так как снипет url формирует именно с этим параметром:
$url = '[(site_url)][~'.$doc['id'].'~]';
Вы можете зайти в настройку контекста, во вкладку Настройки контекста и добавить там новый параметр с ключом site_url и значением - вашим доменом вместе с протоколом
