Тогда другой вопрос. Как вы думаете, почему при наличии таких фактов и такой реальности, которые вы описываете, множество других компаний еще не разогнали все эти высокооплачиваемые штаты десятков веб-разработчиков и не посадили вместо них по студенту на десяток уволенных программистов и не вручили им всем WP?
Клиент скорее всего не узнает или не поймет в чем тут проблема со стандартной нарезкой изображений в WP. Докупит места и всё, тем более это наверняка обойдется дешевле, чем платить за ваш сервис.
Лично я могу представить использование вашего сервиса на масштабных нагруженных ресурсах, скорее всего со своим штатом разработчиков, которые собственно и пользуются CDN'ами. Но сдавать среднестатистическому заказчику сайт или уж тем более делать какой-нибудь личный блог с завязкой на ваш сервис — не вижу никакого смысла, это банально не выгодно. Такие сайты вполне могут работать на какой-нибудь VPS'ке за 5$/мес., скажем, от Digital Ocean, а вы предлагаете платить дополнительно от 10$ просто за работу с картинками. Конечно, допускаю, что у вас может быть статистика использования вашего сервиса, показывающая, что его используют не только для крупных проектов, и которая меня удивит.
А если бы у WP не было такого недостатка с нарезкой, то и обсуждать тут толком было бы нечего.
И вы там работаете. Несколько неуместная реклама для данной статьи, я считаю.
Ваш сервис неплохих денег стоит, по крайней мере не дешевле и даже дороже хостинга, и замена нативной обработки медиафайлов сторонним платным сервисом — это, скажем так, специфическое решение. Тем более, что, как указали в иных комментариях, разработчики WordPress уже занимаются этим вопросом.
Этот тезис относится не столько к тому, что CMS должна уметь работать с дополнительно созданными разработчиком таблицами, сколько к тому, что разработчик останется только с PDO и MySQL запросами. Слой абстракции БД улучшал бы эту ситуацию, о чем и говорится в статье.
Вы попробуйте вернуться в реальный мир.
Вам придётся смотреть на вещи со многих точек зрения.
Как только вы начнете принимать иные точки зрения отличные от вашей. Вы поймете в чем сила WP.
К статье написано заключение, в котором говорится, что я сделал не один десяток сайтов на WP и буду продолжать работать с ним. Мне кажется, это несколько противоречит вашим суждениям.
Более того, я нигде не говорю, что не нужно пользоваться WordPress, я привожу конкретные примеры технического несовершенства, видите разницу?
Касательно вашего примера — какая-то удивительная история. Из нее напрашивается вывод, не относящийся к WordPress, что 20 опытных веб-разработчиков вовсе не такие опытные и чем-то не тем на работе занимались или же им неверно была поставлена задача или вы о чем-то еще умалчиваете.
Насчет популярности и простых пользователей я написал в заключении статьи. Я тоже использую WP как блогер и для рабочих проектов. Но не считаю, что по каким-то причинам не стоит обсуждать его технические недостатки. Почему популярное решение для простых пользователей не должно или не может быть и технически хорошо выполненным?
Маршрутизация это не только скрытие index.php из адреса, хотя может это и самое частое применение в контексте простого сайта на WP.
Касательно «не путать устаревшую архитектуру и говнокод» — в целом я готов с этим согласиться. Лично я готов характеризовать Wordpress как приложение с устаревшей архитектурой, а не говнокод. =)
Однажды я нашел Pro версию ACF в сети, как вы пишите. С целью посмотреть что он умеет и нужно ли это мне. Само собой в нем была зашита бяка, он подтягивал с левого адреса произвольное содержимое и встраивал в код отдаваемой страницы. У меня хватило знаний заметить это и найти глубоко закопанный и замаскированный код злоумышленника. Большое количество рядовых пользователей WP о таком развитии событий даже не задумаются. Так что такой вариант никому не рекомендую. Но это так, к слову, это не проблема конкретно Wordpress.
Это неправда, создавайте что угодно, никто слова плохого не скажет.
Я написал об этом: «Теоретически разработчик может создать свои произвольные таблицы в БД, но WordPress не будет о них ничего знать и не сможет организовать никакого интерфейса для управления данными, хранящимися в такой таблице. Всё, что останется разработчику — это PDO и MySQL запросы.»
Сама WP пишет в .htaccess только стандартный набор правил
Что если я в апаче отключил опцию чтения конфигурации из .htaccess из соображений скорости и безопасности? Что если я не пользуюсь апачем вообще?
плагин Advanced Custom Fields добавит в WP возможность встраивать свои собственные произвольные интерфейсы
Да, я использую этот плагин. Он делает встроенный в Wordpress функционал custom fields удобным для использования. Бесплатная версия урезана (мне сильно не хватало возможностей), Pro версия стоит 100 австралийских баксов, но окей, это не относится к качеству кода. Суть в том, что существование ACF не убирает описанную в статье проблему с готовыми плагинами и не опровергает ее.
Насчет «мифа» про говнокод. В статье я привел конкретные аргументы почему это не совсем миф. Часть из этих аргументов вы пропустили, на часть ответили, что это наследие. Согласен, наследие, но от того, что кто-то когда-то принял неудачные решения, через 10 лет эти решения магическим образом не становятся удачными. Я считаю, что на эти решения не нужно закрывать глаза, молчать о них и считать нормальными только от того, что они являются наследием. Также я понимаю, что отрефакторить Wordpress совсем не просто и этим никто заниматься не будет, о чем написал в заключении.
Уже не первая статья по Grunt за последнее время, и, если честно, после работы с Gulp'ом, невольно задаешься вопросом зачем кому-то сейчас начинать с Grunt'а и возиться с ним, когда можно взять Gulp.
Нельзя делать только клиентскую валидацию без серверной. Javascript может быть отключен, не говоря о том, что запрос можно отправить без помощи html-формы.
Нужна именно удобная валидация на сервере.
Отчеты меня не волнуют. Мне надо пользователю вывести ошибку — «Вы не заполнили имя», когда пользователь его не заполнил, а в атрибуте name стоит required : true. Из коробки есть возможность вывести ошибку только на английском языке, что некорректно для русскоязычных пользователей. Надо перевести.
Сейчас у меня есть service transformValidationMessage, который разбирает этот объект ошибки валидации и заменяет в нем соответствующий message. Выглядит это так.
При создании модели атрибутам можно задавать ограничения, например required: true. В последствии, если переданный набор данных не подходит под эти ограничения, то в колбэк передается объект ошибки валидации определенной структуры и с текстом на английском. Хочется его перевести, но стандартных возможностей сделать это я не нашел. Нашел костыль, который работает, но не нравится. Есть что-нибудь в этом направлении?
Постойте, а как можно вообще пользоваться браузером без закладок? Может я чего-то не знаю, но не представляю как еще можно сохранять и разбивать на категории множество ссылок на сайты с информацией, которая в будущем может пригодиться. Или большинство пользователей так не делают и эта не такая важная функция для большинства?
Лично я могу представить использование вашего сервиса на масштабных нагруженных ресурсах, скорее всего со своим штатом разработчиков, которые собственно и пользуются CDN'ами. Но сдавать среднестатистическому заказчику сайт или уж тем более делать какой-нибудь личный блог с завязкой на ваш сервис — не вижу никакого смысла, это банально не выгодно. Такие сайты вполне могут работать на какой-нибудь VPS'ке за 5$/мес., скажем, от Digital Ocean, а вы предлагаете платить дополнительно от 10$ просто за работу с картинками. Конечно, допускаю, что у вас может быть статистика использования вашего сервиса, показывающая, что его используют не только для крупных проектов, и которая меня удивит.
А если бы у WP не было такого недостатка с нарезкой, то и обсуждать тут толком было бы нечего.
Ваш сервис неплохих денег стоит, по крайней мере не дешевле и даже дороже хостинга, и замена нативной обработки медиафайлов сторонним платным сервисом — это, скажем так, специфическое решение. Тем более, что, как указали в иных комментариях, разработчики WordPress уже занимаются этим вопросом.
К статье написано заключение, в котором говорится, что я сделал не один десяток сайтов на WP и буду продолжать работать с ним. Мне кажется, это несколько противоречит вашим суждениям.
Более того, я нигде не говорю, что не нужно пользоваться WordPress, я привожу конкретные примеры технического несовершенства, видите разницу?
Касательно вашего примера — какая-то удивительная история. Из нее напрашивается вывод, не относящийся к WordPress, что 20 опытных веб-разработчиков вовсе не такие опытные и чем-то не тем на работе занимались или же им неверно была поставлена задача или вы о чем-то еще умалчиваете.
Касательно «не путать устаревшую архитектуру и говнокод» — в целом я готов с этим согласиться. Лично я готов характеризовать Wordpress как приложение с устаревшей архитектурой, а не говнокод. =)
Однажды я нашел Pro версию ACF в сети, как вы пишите. С целью посмотреть что он умеет и нужно ли это мне. Само собой в нем была зашита бяка, он подтягивал с левого адреса произвольное содержимое и встраивал в код отдаваемой страницы. У меня хватило знаний заметить это и найти глубоко закопанный и замаскированный код злоумышленника. Большое количество рядовых пользователей WP о таком развитии событий даже не задумаются. Так что такой вариант никому не рекомендую. Но это так, к слову, это не проблема конкретно Wordpress.
Я написал об этом: «Теоретически разработчик может создать свои произвольные таблицы в БД, но WordPress не будет о них ничего знать и не сможет организовать никакого интерфейса для управления данными, хранящимися в такой таблице. Всё, что останется разработчику — это PDO и MySQL запросы.»
Что если я в апаче отключил опцию чтения конфигурации из .htaccess из соображений скорости и безопасности? Что если я не пользуюсь апачем вообще?
Да, я использую этот плагин. Он делает встроенный в Wordpress функционал custom fields удобным для использования. Бесплатная версия урезана (мне сильно не хватало возможностей), Pro версия стоит 100 австралийских баксов, но окей, это не относится к качеству кода. Суть в том, что существование ACF не убирает описанную в статье проблему с готовыми плагинами и не опровергает ее.
Насчет «мифа» про говнокод. В статье я привел конкретные аргументы почему это не совсем миф. Часть из этих аргументов вы пропустили, на часть ответили, что это наследие. Согласен, наследие, но от того, что кто-то когда-то принял неудачные решения, через 10 лет эти решения магическим образом не становятся удачными. Я считаю, что на эти решения не нужно закрывать глаза, молчать о них и считать нормальными только от того, что они являются наследием. Также я понимаю, что отрефакторить Wordpress совсем не просто и этим никто заниматься не будет, о чем написал в заключении.
Нужна именно удобная валидация на сервере.
required : true. Из коробки есть возможность вывести ошибку только на английском языке, что некорректно для русскоязычных пользователей. Надо перевести.Сейчас у меня есть service transformValidationMessage, который разбирает этот объект ошибки валидации и заменяет в нем соответствующий message. Выглядит это так.
Модель User:
И потом в колбэке при обработке ошибок:
Затем во view возвращаю измененную таким образом ошибку.
Есть ощущение, что можно сделать лучше, но как — не знаю.
required: true. В последствии, если переданный набор данных не подходит под эти ограничения, то в колбэк передается объект ошибки валидации определенной структуры и с текстом на английском. Хочется его перевести, но стандартных возможностей сделать это я не нашел. Нашел костыль, который работает, но не нравится. Есть что-нибудь в этом направлении?