في بعض الأحيان، ويبدو أنه مباشرة بعد استيراد جديد لبيانات المستخدمين من موقعنا القديم المستند إلى phpBB3، نواجه مشكلة حيث تتلف بعض بيانات المستخدم مع بيانات مستخدم آخر أثناء المزامنة من ووردبريس إلى ديسكورس. لا يحدث هذا كثيرًا، ولا يمكن تكراره عند الطلب، مما أدى للأسف إلى تجاهل فريق التطوير لدينا إلى حد كبير لهذه المشكلة.
في الحالة الأولى، تمت إزالة إحدى حسابات المستخدمين التجريبية الخاصة بي كجزء من استيراد جديد للبيانات، ولكن تم تعيين صورة المستخدم التجريبي هذا لملف تعريف مستخدم آخر وتم تسجيل دخولي كـ هذا المستخدم بمجرد اكتمال الاستيراد.
في حالة ثانية، قمت بتسجيل مستخدم تجريبي في ووردبريس وعندما حدثت المزامنة مع ديسكورس، استولى هذا المستخدم التجريبي على اسم مستخدم مستخدم موجود في ديسكورس وبعض بيانات ملفه الشخصي والمجموعة المخصصة الخاصة به. انظر لقطة الشاشة..
في كلتا هاتين الحالتين، شارك مستخدمون مكررون في ديسكورس في تلف حساب المستخدم التجريبي. على سبيل المثال، agmolnar و agmolnar1 و tbm960c و tbm960c1.
كان لدينا عدد من هؤلاء المستخدمين المكررين الذين أفترض أنهم جاءوا على الأرجح من مستخدمين مجهولين في ملف استيراد phpBB3.
هل رأى أحد شيئًا مشابهًا من قبل أو لديه أي تلميحات حول المشكلة المحتملة هنا؟ هل سيكون من المفيد لفريقنا تنظيف ملف استيراد phpBB3 من المستخدمين المجهولين قبل إجراء استيراد جديد؟
شكراً لك Coin-coin. إذا قمنا بإزالة المستخدمين المجهولين من ملف بيانات المستخدم قبل الاستيراد، أفترض أنه سيتم تعيين جميع المشاركات المجهولة للمستخدم “system” كما هو الحال دائمًا. هل هناك أي سبب قد لا أكون على علم به لمنع المستخدمين المجهولين من مثيل phpBB الخاص بنا من ملف الاستيراد؟
أفهم من هذا ومن خيوط أخرى مثل..
تبدو المشكلة بالنسبة لنا مرتبطة بالمستخدمين المجهولين، وهم في الأساس مستخدمون مكررون غير موجودين في WP، واستيراد جديد إلى WP يغير بنية معرفات مستخدمي WP ولكن ليس معرفات Discourse عن طريق إزالة مستخدمي الاختبار الذين تم إنشاؤهم حديثًا في WP، وحقيقة أن Discourse يحاول ربط المستخدمين أولاً بمعرف WP الخارجي.
عندما نقوم باستيراد جديد، فإنه يزيل بعض مستخدمي الاختبار في WP من قاعدة البيانات. تبدو معرفات المستخدم لعدد قليل من المستخدمين المجهولين في phpBB الذين بحثت عنهم جميعًا على أنها أعلى معرفات مستخدم صحيحة في Discourse (4505، 4506، إلخ). لذلك يبدو أنه عندما نقوم بتشغيل استيراد جديد وحذف حسابات الاختبار في WP، يتم مزامنة مستخدم تم إنشاؤه حديثًا في WP بواسطة المعرف القديم للمستخدم القديم غير الموجود الآن.
من خلال إجبار المستخدمين على المطابقة عن طريق البريد الإلكتروني بدلاً من المعرف الخارجي أثناء الاستيراد الجديد، كما هو موضح في المنشور رقم 5 المرتبط أعلاه، يجب أن نمنع إمكانية دمج غير مرغوب فيه للمستخدمين القدامى والجدد.
تكمن المشكلة في هذا في أن نسبة المشاركات للمستخدمين الفريدين ستضيع، لذلك سيكون من الصعب متابعة محادثة تبدو فيها جميع المشاركات وكأنها تأتي من مستخدم system واحد - لن تتمكن من التمييز بين المشاركين المختلفين.
بالضبط؛ من الناحية المفاهيمية، يمكنك إما ترك الأمور كما هي واستخدام واجهة ملف تعريف المستخدم الإداري يدويًا لدمج المستخدمين الذين يجب أن يكونوا نفس الأشخاص، أو يمكنك ببساطة إرسال البريد الإلكتروني كمعرف خارجي بدلاً من ذلك كما تقترح، مما سيؤدي إلى ربط تسجيلات الدخول الجديدة بحساب موجود به عنوان بريد إلكتروني مطابق.
هذا ما يبدو عليه الأمر في هذه المرحلة مع استمرار تطوير موقعنا الجديد المبني على ووردبريس/ديسكورس، ولكن لا، ديسكورس لا يزال قيد التطوير. نحن نستبدل موقعًا مخصصًا تم بناؤه حول phpbb3.
لقد أجرينا استيرادًا أوليًا ثم قررنا إجراء اختبار استيراد آخر قبل الاستيراد النهائي قبل الانتقال. أنا سعيد لأننا فعلنا ذلك، لأنني لا أرغب في مطاردة هذه الأخطاء في موقع مباشر.
مرحباً يا رفاق، لدي متابعة إذا كنتم لطفاء. شاركت النتائج المذكورة أعلاه مع فريق التطوير فيما يتعلق بإجبار المستخدمين على المطابقة بواسطة البريد الإلكتروني بدلاً من المعرفات الخارجية أثناء الاستيراد/الترحيل النهائي قبل أن نبدأ العمل مباشرة، بالإضافة إلى حذف سجلات الدخول الموحد (SSO) حتى يمكن نشرها بشكل نظيف.
لكنهم الآن يعتقدون أن هناك خطأ ما في بيانات التصدير الأصلية لـ phpBB3، وتحديداً وجود مستخدمين مكررين/مجهولين في تلك البيانات بالإضافة إلى بعض مستخدمي phpBB بدون رسائل بريد إلكتروني مرتبطة. يبدو كل ما يلي شيئًا يمكن لـ Discourse التعامل معه فيما يتعلق باستيراد بيانات phpBB3. هل أنا مخطئ؟ خاصة فيما يتعلق بكيفية تعيين Discourse لأسماء مستخدمين وهمية للمستخدمين المجهولين، فهذا إجراء تشغيلي قياسي.
إذا احتجنا إلى الحصول على بيانات أنظف من تثبيت phpBB3 الحالي لدينا، فيمكننا القيام بذلك على الأرجح. لكن لا يبدو أننا بحاجة إلى العبث ببيانات phpBB أو يجب علينا ذلك. لم تكن هذه هي المشكلة حقًا.
أجرينا تثبيتًا جديدًا لـ Discourse ونجحنا في استيراد البيانات من phpBB.
إليك النتائج التي توصلنا إليها:
يحتوي جدول “…_users” على ما مجموعه 3270 سجلًا.
عند تنزيل المستخدمين المستوردين من Discourse، لاحظنا وجود 3251 مستخدمًا في Discourse.
أثناء تحليلنا، اكتشفنا أن العديد من المستخدمين لديهم “1” مضاف إلى أسماء مستخدميهم في Discourse، والتي نشأت بالفعل من أسماء المستخدمين الخاصة بهم في بيانات phpBB. مستخدم واحد فقط هو “redacted_username1”، والذي لا يوجد في بيانات phpBB. ومع ذلك، فإن المستخدم “redacted_username” موجود في بيانات phpBB.
البريد الإلكتروني المرتبط باسم المستخدم في Discourse “edacted_username1” هو “anonymous_52996ba94025464fdf3e5f3ae131bdf5@no-email.invalid”. هذا يشير إلى أن اسم المستخدم “redacted_username” كان مشغولاً بالفعل بواسطة مستخدم مجهول، والذي قام بعد ذلك بإضافة “1” إلى اسم المستخدم الخاص به.
لمنع حدوث مثل هذه الحالات في عمليات الاستيراد المستقبلية، نحتاج إلى الحصول على بيانات جديدة تستبعد المستخدمين المجهولين وغيرهم من المستخدمين غير المرغوب فيهم.
الفرق في عدد المستخدمين بين phpBB و Discourse هو 19. ضمن بيانات phpBB، هناك 53 مستخدمًا يفتقرون إلى بريد إلكتروني مرتبط بحساباتهم.
عند البحث عن المستخدمين “المجهولين” في Discourse، يعرض 32 مستخدمًا لديهم رسائل بريد إلكتروني مجهولة وهوية معلقة حاليًا. لا يمكن العثور على أسماء المستخدمين المعينة لهؤلاء المستخدمين المجهولين في بيانات phpBB. هذا يعني أن Discourse يقوم بتعيين أسماء مستخدمين وهمية للمستخدمين المجهولين، مما قد يتسبب في أخطاء مستقبلية.
باختصار، لم يتم استيراد 19 مستخدمًا بدون بريد إلكتروني، بينما تمت مزامنة 32 مستخدمًا كرسائل بريد إلكتروني مجهولة بأسماء مستخدمين ملفقة.
يرجى مشاركة بيانات PHPBB النظيفة حتى نتمكن من استيرادها.
علاوة على ذلك، إذا كانت لديك أي أفكار حول هذا الموضوع، فيرجى إخبارنا.
ما لم تكن ستحذف هؤلاء المستخدمين من قاعدة البيانات، سأقوم بتعديل البرنامج النصي لتجاهل هؤلاء المستخدمين. من المحتمل ألا يكون الحصول على تفريغ جزئي قابلاً للتكرار بسهولة.
إذا كان بإمكانك فقط حذف هؤلاء المستخدمين من الموقع الحالي، فذلك يبدو حلاً جيدًا. تفضيلي في المواقف مثل موقفك هو قراءة قاعدة البيانات المباشرة مباشرة بدلاً من نقل تفريغ بشكل متكرر.
