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