Каждый веб-сайт, который мы создаем, имеет свои проблемы. Но инструменты, которые мы используем, могут помочь нам решить их напрямую.
WordPress и его бесконечная плагинная экосистема помогли веб-дизайнерам справиться даже с самыми сложными потребностями клиентов. Почти все, что нам нужно, это нажать и уйти. И если его не существует, мы можем построить его сами.
Однако для каждого из этих решений, которые мы реализуем, есть скрытые последствия. Тот, который только увеличивается, если мы более внимательно посмотрим на пользовательские данные. Только тогда мы узнаем замешательство под этой красивой внешней оболочкой.
Легкий старт
В стандартной установке WordPress пользовательские данные (по крайней мере, тип, который вы хотите экспортировать) на самом деле довольно чисты и организованы. Данные хранятся в таблице базы данных wp_usermeta. Внутри вы найдете основы, такие как имя пользователя, а также их роли / характеристики и настройки учетной записи.
Объедините это с тем, что находится в таблице wp_users (имя пользователя, адрес электронной почты, пароль), и вы можете получить много полезной информации для любого пользователя на вашем сайте. При необходимости вы также можете легко импортировать список новых пользователей в CSV.
Очевидно, что большинство сайтов не останавливаются на стандартных настройках. Вместо этого мы обычно добавляем любое количество плагинов, чтобы пользователи могли больше работать с нашим сайтом.
Например, мы хотим, чтобы они имели личный профиль, отслеживали заказы и принадлежали к определенным группам. Кроме того, в наши дни часто используются такие ресурсы, как форумы, порталы поддержки и системы управления обучением.
И просто поцарапать поверхность. Гораздо больше можно добавить на типичный сайт WordPress. Это нормально, пока вы не попытаетесь обсудить данные.
Данные, данные в любом месте
Проблема заключается не столько в виновнике самого WordPress. Во многих случаях конкретный элемент данных оставлен разработчикам плагинов. Это может привести к хранению пользовательских данных, которые вы хотите собирать где угодно. Это природа зверя.
Мы будем использовать обновленный сайт, где я работаю в качестве примера. Плагин членства используется, чтобы люди могли присоединиться к организации клиента.
Собранная информация
Когда они входят в систему, мы запрашиваем не только стандартные пользовательские метаданные WordPress. Новых участников просят предоставить такую информацию, как:
Сгенерированные данные
В дополнение к информации, которую мы запрашиваем у пользователей, существует также большое количество данных, генерируемых программой членства. Это включает:
В настройках ничего лишнего. Это, вероятно, не сильно отличается от десятков тысяч других сайтов, работающих с той же группой участников.
Сам сайт не очень сложен, но это не означает, что данные пользователя легко найти. Давайте посмотрим, как простая задача может стать трудоемкой задачей.
Соревнование
У клиента была очень основная потребность. Они хотели получить экспорт от всех активных членов, которые предпочитают получать печатную копию бюллетеня организации. Исходя из того, что у нас есть, импровизация должна занять всего несколько минут. До этого момента.
Это было намного сложнее, чем я себе представлял. Необходимые нам данные были в базе данных. Однако попытка воссоздать его оказалась почти монументальной задачей для тех, кто не является справочным руководством по базе данных.
Так что у нас есть аксессуары, верно? И есть множество различных вариантов, бесплатных и премиум. Но что бы я ни пытался, я не получил именно то, что требовалось для экспорта. Таким образом:
В результате я смог выяснить, кто запрашивал рассылку по электронной почте, но не смог выяснить, было ли их членство активным, что не очень помогло.
Да, эта информация была сохранена в соседней таблице в той же базе данных, но она также может быть сохранена в Юпитере для моих целей. Казалось, он искал ключи от дома, только чтобы обнаружить, что сосед искал их, чтобы спасти.
Наконец, я нашел плагин экспорта, который содержал плагин ассоциации, который я мог использовать для сбора необходимых данных. Если бы этого не было, вы все равно застряли бы с половиной решения.
Можно ли улучшить опыт?
Все это заставило меня задуматься о том, как эти ситуации можно улучшить или избежать. Это сложное решение.
Во-первых, я признаю, что этот тип вызовов не моя сила. Человек с большим опытом работы с PHP и MySQL может найти индивидуальное решение. МЕНЯ? Я должен попробовать плагины и стоны, если они не работают, как ожидалось.
Но вопрос, который стоит задать: Если этот опыт необходим для экспорта полного набора пользовательских данных? Кажется, должен быть более простой способ использовать это для работы.
Тот факт, что WordPress позволяет плагинам создавать свои собственные таблицы базы данных, понятен и даже выгоден. Это гарантирует, что мы можем устанавливать и удалять плагины, не беспокоясь о том, что что-то пойдет не так.
Хотя все это работает невооруженным глазом, это далеко от тех, кто пытается получить доступ к основным данным.
Может быть API, который мы можем использовать для получения всего, что связано с конкретным пользователем, где бы оно ни хранилось в базе данных. Но я оставлю это обсуждение тем, кто знает плюсы и минусы этой функции.
До этого я собирал вещи, которые нужны клиентам и ожидали более чистого процесса в будущем.
