Да, поэтому давайте кратно упростим жизнь нерадивого начальника, требовать фотографии бюлетеней, контроль и все вот это сложно и геморно, давайте сделаем это в электронном виде - за закрытыми дверями, без наблюдателей соберем со всех работников учетные данные и сами проголосуем как надо.
А владелец не должен передавать свои учетные данные третьим лицам, и в его интересах этого не делать.
Конечно, не должен... но может, например по "настойчивой просьбе" начальника, или это может быть действительно он, но за его спиной стоит тот-же условный начальник проверяющий, что подчиненый не ошибется в своем выборе.
А я и не писал про многократное голосование, я писал про то, что в отличии от оффлайн голосования где член избирательной комиссии верифицирует вас по предъявленому паспорту визуально в онлайн голосовании это может быть кто угодно обладающий данными избирателя
Я в 1-м комментарии доступно написал принцип, ну и если вы любите писать а читать нет - повторю тезисно: на бэке считаем одно, на фронте выводим другое. И тогда вопрос: как мне проверить, что все голоса учтены верно?
Вы совершенно правы, но это фото можно отнести и к этой системе т.к. на бэке может быть все вполне честно, а на фронте вам выведут именно такое и вы никак не сможете проверить достоверность этих данных.
Добавлю в копилку еще одну довольно важную деталь: Stylus позволяет синхронизировать ваши стили, то есть на всех ваших устройствах будут актуальные css.
Таким образом, каждый элемент анимации тщательно прорабатывается и детализируется для достижения высокого уровня реализма и выразительности в итоговой анимированной сцене.
Вы его пальцы видели? И что он там усердно набирает, когда на мониторе явно видны только обои?
Та шож такое, и код у нее чистый, и ядро охрененное, и все современные подходы к разработке... но нафиг никому не уперлась и все выбирают "сплошную дыру".
Эта тема давно рассосана и поднималась разными авторами. Навскидку, в книге «Совершенный код» Стива Макконнелла.
Отлично, вы только забыли маленькую деталь, цитату/ссылку на это.
Избыточные пробелы не несут в себе никакой пользы.
Вред несут?
Со стороны может казаться, что выравненный таким способом код выглядит аккуратно, но на деле, от того что название переменной отдаляется от ее значения, восприятие только ухудшается.
Опять-же ваше оценочное суждение, я противоположного мнения.
Да, благодаря всем этим "фичам" очень легко кодить по принципу хяк-хяк и в продакшн.
А "эти фичи" во множественном числе это вы так увыжительно "на вы" называете глобальные переменные?
Начинающим разработчикам очень легко нагуглить куски кода и впихнуть их себе.
Это вообще относится к любому языку программирования, при чем тут WP?
В этом несомненный плюс вордпресса: можно быстро и без особых навыков накрутить что-то несложное. Проблемы всплывут позже, при поддержке или при росте проекта.
Именно так, у кого нет познаний, опыта накрутит как придется - как вы, например, предлагали SQL запрос менять для получения метаполей. Я таких поделок под WP за свой опыт работы видал тысячи... и ничего страшного, для более-менее серьезного проекта выбирают имеено опытных разработчиков.
Однако я именно про это и говорю: вордпресс буквально учит плохой разработке. С одной стороны может показаться удобным, что можно перехватить хуком какой-нибудь параметр и переписать его. Коварство этого подхода в том, что это может сделать кто угодно, где угодно и сколько угодно раз.
Вы пишете, право, глупости. Это можно сделать в любом другой CMS (да той-же симофони) через рефлексию или даже тупо залезть в код ядра.
И потом попробуй разобраться в результате.
Довольно несложное занятие кстати, когда знаешь как и где искать.
Это, кстати, также отвечает на вопрос про "спагетти".
Не отвечает, т.к. тот подход, что вы описали выше можно применить где угодно. Я спрашивал где "спагетти" в самом WP.
А кто сказал, что кастомные поля - это только простые метаполя?
Потому, что это так и есть. И не бывает "не простых" метаполей.
Ну а два, перехват и модификация запроса используется и в разных уважаемых плагинах (тот же ACF), и даже в ядре.
При чем здесь сторонние плагины и WP. Их пишут совершенно разные команды. Про ядро вы выдумываете, в WP объявлены только хуки и само ядро их не использует. Вам дан инструмент, хотите пользуйтесь, хотите - нет.
Начнем с того, что рекомендации вордпресса идут вразрез с PSR.
Начать надо с того, что PSR это не стандарт, а рекомендации и что WPCS обязателен только для ядра, для плагинов и тем это так-же рекомендация. То есть ничто не запрещает вам использование PSR в последних.
Например, выравнивание пробелами по оператору присваивания.
Так а что здесь плохого? Я наоборот вижу здесь только благо - это визуально намного проще читать код с таким выравниванием.
Если идти глубже, то я бы вспомнил обилие глобальных переменных, хуков и процедурного кода.
Глобальные переменные есть и от них невозможно отказаться разом ввиду обратной совместимости, а во многом благодаря этому WP и стал таким популярным. В хуках не понятно что плохого то? Это еще одна фича WP благодаря которой он относительно прост и удобен для разработки. Что вы понимаете под "процедурным кодом". Функции в глобальном scope? Большее количество функций под капотом используют вызовы методов классов под капотом, что опять-же очень удобно.
Это даже не спагетти.
То есть лучше или хуже? Что в вашем понимание "спагетти" и приведите примеры такого в WP.
Как пример, навскидку могу вспомнить, что если у нас есть пост с кастомными полями, и ты хочешь показать их в админке в списке постов, то тебе нужно перехватывать SQL через хук и редактировать его чуть ли не через регулярки.
Ну тут уже понятно, что познания в разработке под WP у вас практически отсутствуют. Для вывода метаполей вообще не стоит использовать какие-либо SQL запросы т.к. тогда не работаю все хуки для них и не работает Object Cache.
Если суммировать все выше:
WP как разработчик вы не знаете (ваш пример с "кастомными полями" это прям дичь) Я вижу одну валидную претензию - глобальные переменные, но не уверен, что это является критическим фактором Все остальные ваши пассажи я проигнорировал т.к. там или ваше оценочное суждение или нет примеров.
А зачем два раза голосовать, мы нагенерируем пару милионов избиратлей которые проголосуют "правильно"
И российский суд, славящийся своей справедливостью и непредвзятостью конечно же посодит этого негодяя
Да, поэтому давайте кратно упростим жизнь нерадивого начальника, требовать фотографии бюлетеней, контроль и все вот это сложно и геморно, давайте сделаем это в электронном виде - за закрытыми дверями, без наблюдателей соберем со всех работников учетные данные и сами проголосуем как надо.
Про БД вы сами выдумали и опровергли, замечательно - я такого не писал. Бэк/фронт это концептуальные понятия (я это объясняю на хабре омг).
Ладно, задам тогда конкретные вопросы:
Что мешает ввести в систему пару милионов Ивановых Иван Иванычей проголосующих за правильного кандидата?
Как обеспечивается тайна голосования?
Как убедиться, что проголосовавший это именно тот человек а не кто либо другой обладающий его учетными данными?
Конечно, не должен... но может, например по "настойчивой просьбе" начальника, или это может быть действительно он, но за его спиной стоит тот-же условный начальник проверяющий, что подчиненый не ошибется в своем выборе.
А я и не писал про многократное голосование, я писал про то, что в отличии от оффлайн голосования где член избирательной комиссии верифицирует вас по предъявленому паспорту визуально в онлайн голосовании это может быть кто угодно обладающий данными избирателя
Не совсем верно, вы никак не сможете проверить что именно этот человек получил электронный бюлетень а не его начальник/сосед/мошенник
Я в 1-м комментарии доступно написал принцип, ну и если вы любите писать а читать нет - повторю тезисно: на бэке считаем одно, на фронте выводим другое. И тогда вопрос: как мне проверить, что все голоса учтены верно?
Вау, криптографические методы - это все конечно же меняет, обман невозможен, ага
Вы совершенно правы, но это фото можно отнести и к этой системе т.к. на бэке может быть все вполне честно, а на фронте вам выведут именно такое и вы никак не сможете проверить достоверность этих данных.
Добавлю в копилку еще одну довольно важную деталь: Stylus позволяет синхронизировать ваши стили, то есть на всех ваших устройствах будут актуальные css.
Обратная совместимость
Вы его пальцы видели? И что он там усердно набирает, когда на мониторе явно видны только обои?
Забавно, что вы "дыра" машинально отнесли к Joomla а не к WP к которому это я и отсылал.
Та шож такое, и код у нее чистый, и ядро охрененное, и все современные подходы к разработке... но нафиг никому не уперлась и все выбирают "сплошную дыру".
То есть у вас нет никаких пруфов относительно выравнивания?
Я не увидел где вы написали какой вред наносит форматирование (конкретно выравнивание пробелами), укажите?
Все еще жду цитаты.
Это не таблица, а сущность WP. Таблица (а точнее таблицы т.к. она не одна) это реализация.
Ну явно не того уровня, что вы, у меня в проектах получение метаполей SQL запросами не практикуется.
Это не код ядра, а пример использования хука.
Отлично, вы только забыли маленькую деталь, цитату/ссылку на это.
Вред несут?
Опять-же ваше оценочное суждение, я противоположного мнения.
А "эти фичи" во множественном числе это вы так увыжительно "на вы" называете глобальные переменные?
Это вообще относится к любому языку программирования, при чем тут WP?
Именно так, у кого нет познаний, опыта накрутит как придется - как вы, например, предлагали SQL запрос менять для получения метаполей. Я таких поделок под WP за свой опыт работы видал тысячи... и ничего страшного, для более-менее серьезного проекта выбирают имеено опытных разработчиков.
Вы пишете, право, глупости. Это можно сделать в любом другой CMS (да той-же симофони) через рефлексию или даже тупо залезть в код ядра.
Довольно несложное занятие кстати, когда знаешь как и где искать.
Не отвечает, т.к. тот подход, что вы описали выше можно применить где угодно. Я спрашивал где "спагетти" в самом WP.
Потому, что это так и есть. И не бывает "не простых" метаполей.
При чем здесь сторонние плагины и WP. Их пишут совершенно разные команды. Про ядро вы выдумываете, в WP объявлены только хуки и само ядро их не использует. Вам дан инструмент, хотите пользуйтесь, хотите - нет.
Ну например по популярности в 25 с лишним раз
Начать надо с того, что PSR это не стандарт, а рекомендации и что WPCS обязателен только для ядра, для плагинов и тем это так-же рекомендация. То есть ничто не запрещает вам использование PSR в последних.
Так а что здесь плохого? Я наоборот вижу здесь только благо - это визуально намного проще читать код с таким выравниванием.
Глобальные переменные есть и от них невозможно отказаться разом ввиду обратной совместимости, а во многом благодаря этому WP и стал таким популярным. В хуках не понятно что плохого то? Это еще одна фича WP благодаря которой он относительно прост и удобен для разработки. Что вы понимаете под "процедурным кодом". Функции в глобальном scope? Большее количество функций под капотом используют вызовы методов классов под капотом, что опять-же очень удобно.
То есть лучше или хуже? Что в вашем понимание "спагетти" и приведите примеры такого в WP.
Ну тут уже понятно, что познания в разработке под WP у вас практически отсутствуют. Для вывода метаполей вообще не стоит использовать какие-либо SQL запросы т.к. тогда не работаю все хуки для них и не работает Object Cache.
Если суммировать все выше:
WP как разработчик вы не знаете (ваш пример с "кастомными полями" это прям дичь)
Я вижу одну валидную претензию - глобальные переменные, но не уверен, что это является критическим фактором
Все остальные ваши пассажи я проигнорировал т.к. там или ваше оценочное суждение или нет примеров.
about:support#media