Новая домашняя страница WordPress.org, приобретение Cloudways, WebP приостановлено ️ Сентябрь 2022 г. Новости WordPress с CodeinWP

DesktopServer, локальный инструмент разработки WordPress, закрывается навсегда

Печальная новость: ServerPress объявила о закрытии локального инструмента разработки WordPress DesktopServer после 12 лет работы (наряду с бизнесом ServerPress в целом).

Насколько мне известно, DesktopServer был одним из первых инструментов локальной разработки для WordPress и предлагал ряд удобных функций для пользователей WordPress.

Команда DesktopServer работала над новой версией (5.0), но прекратила работу над ней после того, как пришла к выводу, что у нее мало шансов достичь высокой доли рынка.

Честно говоря, меня это не особо удивляет. Конкуренция в этой области действительно обострилась, особенно со стороны управляемых хостингов WordPress, выпускающих бесплатные локальные инструменты разработки в качестве дополнительной ценности/привлекательности для своих клиентов хостинга.

Например, Flywheel (и впоследствии WP Engine) начал эту тенденцию с Local WP. Затем Kinsta также присоединилась к DevKinsta.

Учитывая, что оба этих инструмента имеют функциональные и неограниченные бесплатные версии, трудно оправдать стоимость DesktopServer, даже если это надежный инструмент.

Не говоря уже о том, что существует множество новых вариантов локальной разработки, которые не являются специфическими для WordPress, но по-прежнему хорошо работают для сайтов WordPress.

Я думаю, что команда ServerPress справляется с этим очень честно. ServerPress продолжит поддерживать пользователей с лицензией до истечения срока их подписки, включая помощь в переходе на другой инструмент.

Есть шанс, что ServerPress либо продает, либо открывает код DesktopServer, но официальных новостей об этом пока нет.

Чтобы увидеть некоторые другие варианты, вы можете прочитать нашу полную коллекцию лучших инструментов локальной разработки WordPress.

WP-Optimize якобы искусственно завышает показатели оптимизации

Если вы когда-либо занимались оптимизацией производительности WordPress, вы, вероятно, заметили очень раздражающую тенденцию:

Многих пользователей, особенно в более повседневных делах, больше волнуют «показатели оптимизации» их сайтов, чем реальная производительность их сайтов.

Конечно, их сайт может загружаться менее чем за одну секунду для всех посетителей, но они получили только 79 баллов в тесте скорости, так что явно что-то не так.

Возможно, поэтому неудивительно, что некоторые плагины производительности WordPress изо всех сил стараются повысить показатели производительности любым возможным способом.

Это привело меня к этому твиту от Gijo Varghese, который делает популярный плагин для оптимизации FlyingPress, а также ряд бесплатных инструментов для оптимизации.

В твите Gijo утверждает, что популярный плагин WP-Optimize обнаруживает популярные инструменты тестирования скорости и не передает JavaScript этим инструментам, тем самым искусственно повышая производительность при тестировании (даже несмотря на то, что JavaScript по-прежнему будет предоставляться посетителям-людям).

WP-Optimize — это комплексный плагин производительности WordPress, который был приобретен той же командой, что и UpdraftPlus .

Если это правда, это возвращает нас к скандалу с выбросами Volkswagen, когда Volkswagen искусственно снижал выбросы, но только во время испытаний. В реальном мире выбросы были в 40 раз выше.

В ответ на запросы WP Tavern Дэвид Андерсон из UpdraftPlus сказал, что код был добавлен как часть включения кода из форка плагина Fast Velocity Minify и что код не трогали с момента первоначального слияния с WP- Оптимизировать плагин.

Дэвид сказал, что он поручил ведущему разработчику JavaScript команды исследовать код, и, если он действительно предназначен только для инструментов тестирования скорости игры, он будет удален.

В целом, я был счастливым пользователем UpdraftPlus в течение долгого времени, поэтому я склонен дать им презумпцию сомнения в том, что не было ничего преднамеренно зловещего. Тем не менее, этого не должно было случиться.

В любом случае, это хорошее напоминание о том, что когда дело доходит до производительности WordPress, вы всегда должны сосредотачиваться на фактическом опыте ваших посетителей-людей, а не на туманных «оценках» оптимизации.

Информационный бюллетень Glue отказывается от WordPress.org, чтобы перейти на премиум-класс

Многим разработчикам плагинов нравится каталог плагинов WordPress.org, потому что он дает им доступ к большой аудитории.

Однако есть и некоторые недостатки, в первую очередь некоторые… так сказать, уполномоченные пользователи, которым нужна качественная поддержка от бесплатного расширения.

Тем не менее, большинство разработчиков либо обходят каталог с самого начала (например, Gravity Forms), либо смиряются с требованиями поддержки этих бесплатных пользователей в обмен на то, что он их подвергает опасности.

Вот почему я подумал, что интересно, что Newsletter Glue принял решение официально закрыть свой существующий бесплатный плагин WordPress.org, чтобы перейти к полностью премиальному подходу ( после нескольких месяцев предупреждения — они не сделали этого на ровном месте). ).

Страница WordPress.org официально отключена с 15 августа.

В интервью WP Tavern Лесли Сим из Newsletter Glue сказал, что они просто не оптимальным образом настроили бесплатную или премиальную версию.

Например, пользователям приходилось удалять бесплатную версию плагина и устанавливать отдельный плагин премиум-класса, а это означало, что количество «активных установок» Newsletter Glue на WordPress.org оставалось нереально низким ( поскольку количество «активных установок» фактически уменьшалось) . если кто-то обновился до премиума ).

Если вы планируете выпустить свой собственный плагин или тему, это хорошее напоминание о том, что вы должны подумать об этих типах реализаций, прежде чем запускать их.

WebP по умолчанию находится в режиме ожидания (опять же)

Будут они или не будут? Это был вопрос об использовании WebP по умолчанию в ядре WordPress.

Под «по умолчанию» я подразумеваю автоматическое создание WebP-версий недавно загруженных изображений JPEG ( что, по сути, удвоит количество файлов изображений на сервере ).

Несмотря на то, что большая часть основной работы уже была объединена в предстоящий выпуск WordPress 6.1, похоже, что теперь она «приостановлена» после возражений со стороны ряда ведущих разработчиков WordPress.

Общие жалобы на реализацию следующие:

• Это удвоит количество файлов изображений на сервере.
• Это значительно увеличивает объем обработки, необходимой для загрузки изображений, поскольку серверу теперь потребуется дополнительно конвертировать их в WebP. Это также может привести к более частым сбоям при загрузке изображений.

В целом, я склонен согласиться с тем, что это просто не имеет смысла как основная функция, по крайней мере, в ее текущей реализации.

Если пользователи действительно хотят использовать изображения WebP, у них есть множество вариантов, включая преобразование изображений самостоятельно или использование плагина, такого как Optimole, который динамически оптимизирует изображения в режиме реального времени.

Также кажется, что разработчики, спонсируемые Google, являются теми, кто продвигает изменения, что может быть небольшим конфликтом интересов, учитывая, что Google также разработал формат WebP.

В целом, продвижение WebP по умолчанию определенно не умерло, но еще предстоит увидеть, когда и как будет реализована реализация.