user
  • 0
Гуру

Каковы плюсы и минусы использования пользовательского внешнего интерфейса для извлечения содержимого из внутреннего интерфейса WordPress

  • 0

Я занимаюсь созданием сайтов на WordPress уже несколько лет и заметил несколько вещей, которые меня беспокоят.

1. Это довольно медленно (ужасное общее заявление, прошу прощения)

Мое первоначальное желание создать собственный интерфейс возникло из наблюдения. Сайты WordPress, которые я создавал, были не такими быстрыми, как мне хотелось бы (3-5 секунд, иногда дольше).

@Kenrik — они, безусловно, были развернуты на перепроданном виртуальном хостинге, но получили хорошие оценки Yslow. Я попробовал это и обнаружил, что сайты работают примерно в три раза быстрее, когда я не загружаю накладные расходы WP. Та же машина, тот же показатель Yslow, в 3 раза быстрее. Я не эксперт по использованию ЦП WordPress, но я читал, что это довольно интенсивно, поэтому я не был удивлен достигнутым приростом скорости.

2. Часто это слишком сложно для нужд простого веб-сайта.

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

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

3. У него много проблем с безопасностью (особенно при использовании плагинов)

Что касается безопасности, я вижу, насколько двусмысленным и противоречивым был мой вопрос. Я имел в виду, что, насколько я понимаю, сайт WordPress, помимо реальных дыр в безопасности, уязвим, потому что злоумышленники знают, что это сайт WordPress. Это создает проблему (взломать популярную платформу) и неотъемлемую шпаргалку (уязвимости WordPress хорошо задокументированы). Итак, конечно, пользовательское решение может иметь больше реальных дыр в безопасности, но мне интересно, не будет ли это уравновешено тем фактом, что оно делает внутреннюю работу анонимной. Как сказал @Kenrik, «они, скорее всего, даже не будут беспокоиться, потому что кого волнует взлом одного сайта с сомнительным пользовательским кодом?»

4. Трудно оптимизировать время загрузки страницы

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

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

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

Потенциальные минусы: безопасность, отсутствие масштабируемости, отсутствие поддержки разработчиков для пользовательских решений… Что-нибудь еще?

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

Пожалуйста, дайте мне знать, если это так.

Ваше здоровье

Заключить задним числом:

Я на 100% уверен, что мои сайты работают быстрее в той же самой среде, когда я не использую собственный интерфейс WordPress.

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

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

Так что мне просто интересно, учитывая мое окружение и мои ограничения, не является ли это плохой идеей. И если да, то каковы основные причины.

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

Спасибо вам всем

Share
  1. Сначала вы утверждаете, что WP небезопасен и его трудно масштабировать, а позже вы признаете, что пользовательский интерфейс может страдать от тех же проблем. В чем тогда смысл?

    • 0
    • Одно соображение: ваша индивидуальная реализация для вашего личного проекта или для клиента? Если второе, я думаю, вы оказываете им большую медвежью услугу, создавая собственный интерфейс, понятный только вам. Одним из преимуществ WP является его мобильность: существует большое сообщество разработчиков и фрилансеров, которые могут поддерживать код, если первоначальный разработчик уходит в самоволку.

      • 0
    • Это действительно плохой вопрос, если его не пометить, чтобы удалить. Ничего конкретного, сплошь обобщенное мнение, никакой ценности.

      • 0
    • @Wyck Я не согласен, особенно после правок, предоставленных по моему запросу. Вполне уместный вопрос от человека, который имеет не очень большой опыт работы с WordPress в силу специфики своей работы. Я думаю, что это правильный вопрос, чтобы поделиться такой точкой зрения и попросить помощи и комментариев. Он также может получить конкретные и действенные ответы о том, что следует решать (хостинг, кэширование, альтернативы).

      • 0
    • Также в ответ на обвинение @Wyck в троллинге, я хотел бы знать, где можно высказывать такие опасения, как не на этом форуме? С ростом числа кодеров-самоучек, я думаю, должно быть больше терпимости к общим вопросам, которые возникают, когда после нескольких лет в игре вы начинаете задаваться вопросом, может быть, вы все делаете неправильно. Спасибо @Ryan, @Rarst и @Kenrik за конкретные советы. Я собираюсь переварить всю вашу мудрость и узнать как можно больше о разработке плагинов, кэшировании и администрировании серверов. Ваше здоровье.

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

      • 0
    • @Matteo Riva да, стабильная версия может быть небезопасной. Однако [значительно] устаревшая версия гарантированно небезопасна. Возможность дыры в стабильной версии ни в коем случае не является оправданием для запуска старых версий с известными и активно эксплуатируемыми уязвимостями.

      • 0
    • Я, конечно, вовсе не сторонник использования старых версий. Я держу все свои установки WordPress в актуальном состоянии. Но успех WordPress также означает, что это первая цель попыток эксплойта.

      • 0
    • @Matteo Riva Мне неизвестно о каких-либо массовых уязвимостях против стабильной (на тот момент) версии WordPress. Все крупные события такого типа (о которых я знаю) относились либо к хостингу, либо к старым версиям.

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

      • 0
    • Спасибо @Rarst за ваше терпение. Как вы можете себе представить, у меня есть длинное объяснение: должен ли я предоставить его как редактирование, комментарий или ответ?

      • 0
    • @Martin Мартин, лучше добавить к вопросу подробные сведения. Комментарии предназначены для обсуждения конкретных ответов, ответы для публикации конкретных решений вопроса.

      • 0
    • Хорошо. Что ж, спасибо за быстрые ответы, мудрость, которую вы предоставляете. Позвольте мне начать с того, что я не имел в виду неуважение к WordPress: его неотъемлемое качество и сообщество, безусловно, здесь не обсуждается. Любая интерпретация неуважения проистекает из общего характера моего вопроса, которого было трудно избежать, учитывая его характер. Я давно хотел спросить об этом и не знал, как это сделать. В конце концов, я надеюсь, вы заметите мою неуклюжесть и отдадите должное намерению.

      • 0
    • Я добавил уточнение к моему первоначальному вопросу. Это все еще очень общий вопрос, но, надеюсь, я предоставил достаточно контекста, чтобы кому-то он был интересен. Спасибо.

      • 0
  2. Вы ссылаетесь на более ранний опыт работы с WP, чем мой… Тем не менее, я не считаю эти проблемы столь важными. О каком масштабе сайтов идет речь?

    Это довольно медленно

    Я чувствую, что это слишком много обобщения. Медленное можно рассматривать в контексте конкретного оборудования, задач и уровня трафика. В противном случае это общее заявление.

    Часто это слишком сложно для нужд простого веб-сайта.

    Комплекс для кого? Пользователи? Разработчик? WP легко установить и запустить. Создайте некоторый контент, и у вас есть этот простой сайт. Где здесь сложность?

    У него много проблем с безопасностью (особенно при использовании плагинов).

    Опять же, слишком много общего заявления. Сам WP относительно безопасен, и большинство проблем с безопасностью, которые оказали серьезное влияние, по-видимому, связаны с использованием сильно устаревших версий WP.

    Состояние плагинов и безопасности определенно далеко от совершенства, но ничто не мешает быть очень избирательным или разрабатывать безопасные и надежные плагины, верно?

    Трудно оптимизировать время загрузки страницы

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

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

    У меня к вам только один вопрос — вы абсолютно уверены, что делаете это лучше, быстрее и безопаснее, чем родной интерфейс WP?

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

    Обновлять

    Мое первоначальное желание создать собственный интерфейс возникло из наблюдения. Сайты WordPress, которые я создавал, были не такими быстрыми, как мне хотелось бы (3-5 секунд, иногда дольше). […] Они, конечно, были развернуты на перепроданном виртуальном хостинге, но получили хорошие оценки Yslow.

    YSlow (и PageSpeed) — отличные инструменты, но они по своей сути ограничены. Они могут только анализировать и консультировать по производительности интерфейса и тому, как сайт обрабатывается браузером. Они не дают представления о производительности вашего сервера, а слепая погоня за высокими показателями внешнего интерфейса может на самом деле нанести вред серверной нагрузке.

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

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

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

    Пробовали ли вы статическое кэширование страниц? Он эффективно удаляет ядро ​​WP из большинства запросов, и это примерно так же быстро, как вы можете получить на виртуальном хостинге. Если вы пробовали и вас не устраивают страницы, обслуживаемые из статического кеша, то проблема не в WordPress, а в хостинге.

    Я имел в виду, что, насколько я понимаю, сайт WordPress, помимо реальных дыр в безопасности, уязвим, потому что злоумышленники знают, что это сайт WordPress. Это создает проблему (взломать популярную платформу) и неотъемлемую шпаргалку (уязвимости WordPress хорошо задокументированы).

    В стабильной версии WordPress нет общедоступных и известных уязвимостей безопасности. Те, что возникают, фиксируются в считанные часы.

    Плохая конфигурация сервера (обычное явление на дешевых хостах) или использование устаревшей версии WP — вот что вас взломает, а не сам факт использования WP.

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

    Да, некоторые плагины понятия не имеют, как правильно загружать скрипты. Это действительно аргументы в пользу тщательного выбора плагинов, а не против ядра WordPress.

    Объединение и оптимизация скриптов с хорошим плагином кэширования — тривиальная задача.

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

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

    • 0
  3. Чтобы добавить к тому, что сказал Рарст, но я думаю, что этот пост — пограничный троллинг.

    1. Это довольно медленно. Вам нужно предоставить более подробную информацию, сайт с сотнями тысяч страниц и 1 миллионом просмотров в месяц — это не то же самое, что обычный блог/портфолио. Довольно просто и очень часто сайт WordPress загружается менее чем за 2 секунды в зависимости от хостинга/плагинов/медиа/оптимизации. На самом деле это не проблема WordPress, если только у вас не очень большой сайт. Кажется, вы плохо понимаете скорость страницы, оптимизация веб-сайта — это намного больше, чем Yslow….

    Например, у меня есть динамический сайт с достаточным количеством изображений, виджетов, 5 удаленных элементов RSS-канала и 10 сообщений, начальная загрузка составляет 2,9 секунды без кеша, перезагрузка с кешем — 1,02 секунды. Я могу сказать, что это нормально для всех моих сайтов WordPress. (Большая часть начальной 2,9-секундной загрузки — это изображения, которые кеш явно использует при перезагрузке.)

    2. Часто она слишком сложна для нужд простого веб-сайта WordPress, без сомнения, является одной из самых простых CMS, которая поддерживает некоторые довольно продвинутые функции. Если вы не пользуетесь этими функциями, то почему вы используете WordPress? Если вы находите это сложным, с чем вы это сравниваете,.net, статический html, nodejs?

    3. У него много проблем с безопасностью (особенно при использовании плагинов). WordPress сам по себе безопасен, особенно за последний год+, серьезных проблем не было. Большинство проблем с безопасностью WordPress возникают из-за полного невежества со стороны пользователей, загружающих вредоносные темы, плохо написанных плагинов, не обновляющих свой сайт и плохого хостинга. На сегодняшний день подавляющее большинство проблем безопасности вообще не связаны с ядром WordPress. При необходимости могу привести очень конкретные примеры.

    4. Трудно оптимизировать время загрузки страницы. Я действительно не думаю, что это правильно, есть несколько отличных плагинов, которые делают оптимизацию WordPress проще простого по сравнению с ручным выполнением всего (что раньше было нормой). Эти плагины буквально экономят дни работы за счет оптимального кэширования, минимизации, использования CDN и т. д. буквально одним нажатием кнопки, как вы находите это сложным? У вас есть какие-то конкретные данные, которые мы можем посмотреть?

    • 0
  4. Мартин: Прочитав этот вопрос и сопутствующие ответы, вот мои два цента на ваш вопрос:

    Плюсы использования пользовательского интерфейса по сравнению с WordPress

    • Потенциально более быстрое время загрузки, поскольку вы можете уменьшить количество загружаемых скриптов и т. д. (но см. Ниже)
    • Больше контроля над запросами к базе данных, что потенциально может привести к ускорению загрузки страниц.

    Минусы использования пользовательского интерфейса по сравнению с WordPress

    Скорость. Одной из ваших проблем с WP является скорость. По моему опыту, если вы не используете плагины, которые вставляют свой собственный JS в заголовок (через wp_head() ), WordPress загружает только то, что вы ему говорите.

    Например, исключение wp_head() из шаблона заголовка не позволит WP загрузить новую панель администратора.

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

    Сложность: кажется, что ваша забота о сложности направлена ​​на серверную часть, а не на переднюю часть. Хотя я думаю, что у WP отличный пользовательский интерфейс, я могу понять желание адаптировать его функциональность для конкретных проектов. Во многих случаях вы можете изменить файл functions.php и указать WordPress, что отображать ( см. этот пост для некоторых примеров).

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

    Безопасность: я не согласен с тем, что запуск пользовательского интерфейса более безопасен. Если вы работаете на серверной части WP, хакер может так же легко обнаружить этот факт, просмотрев ваши пути URL (включая /wp-content/ и т. д.).

    Существует множество плагинов, которые удаляют метаданные «сгенерировано» из внешнего интерфейса и делают множество других вещей для повышения безопасности ( хороший пример — Secure WordPress ). Я действительно считаю, что менее безопасно полагаться на собственное собственное решение. Это не комментарий к вашим навыкам программирования, но… мне кажется, что целая команда разработчиков, зарабатывающая на жизнь ничем, кроме WordPress, будет более надежной, чем один парень.

    Вы действительно поднимаете хороший вопрос в том, что у WP есть своего рода хакерская яблочко. Однако… Меня взламывали только на устаревших версиях WP и на виртуальном хостинге, где виноват хост. Начиная с 3.0 проблем не было. Я думаю, что если вы будете в курсе своей установки, убедитесь, что используемые вами плагины безопасны и поддерживаются, и будете руководствоваться здравым смыслом, у вас не будет проблем с безопасностью.

    Время загрузки страницы: я полностью согласен с вами в том, что использование множества плагинов (или определенных плагинов) может отрицательно сказаться на времени загрузки страницы. Однако это больше возлагает вину на плагины и выбор разработчика для их использования, чем на WP, не так ли? Вы можете использовать прямой jQuery с вашим пользовательским интерфейсом или без него, поэтому я не вижу преимущества в том, чтобы делать это здесь, когда разумно разработанная тема WP подойдет так же.

    Портативность. Больше всего меня беспокоит использование пользовательского внешнего интерфейса в том, что он не такой портативный или ориентированный на будущее, как те, которые поддерживаются сообществом. Моя компания никогда не создает собственные CMS для клиентов, потому что к нам приходили многие люди и говорили: «Наш старый веб-мастер создал эту нестандартную штуку, и теперь он в Греции, и я не могу найти никого, кто бы ее обновил».

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

    Последние мысли

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

    Для меня минусы такого подхода перевешивают плюсы.

    • 0
  5. Я действительно не знаю, много ли вы использовали WordPress, основываясь на том, что вы опубликовали? Мы будем использовать мой сайт в качестве примера. Он получает показатель yslow 90% и загружается за 1,5 секунды для нового пользователя. Если они кэшируют его в своем браузере, это происходит мгновенно. Я даже не использую статические страницы.

    Теперь я на выделенном сервере… так что мне не нужно иметь дело с виртуальным хостингом, и я могу оптимизировать свой сервер (gzip и т. д.)

    Я думаю, что вы использовали сервер виртуального хостинга, который продан на 120%… тогда дело доходит до обхода.

    Любое пользовательское приложение будет иметь гораздо больше уязвимостей безопасности, чем что-то вроде WordPress, с которым сталкиваются каждый день. За исключением того, что они, скорее всего, даже не будут беспокоиться, потому что кого волнует взлом одного сайта с сомнительным пользовательским кодом?

    ОБНОВИТЬ:

    Я немного больше понимаю, откуда вы. Однако большая часть того, что делает WordPress «медленным», — это плохо закодированные темы или неоптимизированные серверы. Если у вашего хостинг-провайдера настроены серверы только с базовой установкой Apache/php/mysql, более чем вероятно, что он не оптимизирован для запуска WordPress. Существуют настройки php.ini/httpd.conf/mysql, которые ускоряют его работу с базой данных. сайт.

    Однако это проблема «сервера», а не WordPress. У меня есть сайт, который находится на моем выделенном сервере (Mac Mini Server, 2.66 C2D, 4 ГБ), который загружается за 1,5 секунды, а ЖЕ САЙТ загружается за 4 секунды на InMotion, который является одним из лучших/лучших провайдеров виртуального хостинга.

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

    • 0

Оставить ответ

You must login to add an answer.