เหตุใด Drupal จึงต้องการสถาปัตยกรรมความยินยอมที่ตั้งใจ

จุดแข็งของ Drupal และความเสี่ยงด้านความยินยอมมาจากที่เดียวกัน ความยืดหยุ่นด้านบรรณาธิการของแพลตฟอร์ม การเข้าถึงตามบทบาท และโมเดลเนื้อหาที่มีโครงสร้างคือสิ่งที่ทำให้มันเป็นตัวเลือกเริ่มต้นสำหรับพอร์ทัลรัฐบาล เว็บไซต์มหาวิทยาลัย และมรดกเว็บขององค์กรระดับโลก — เว็บไซต์เดียวกับที่มีแนวโน้มสูงสุดที่จะได้รับการตรวจสอบ มีรายการแท็กบุคคลที่สามที่หลากหลายที่สุดที่สะสมมาในช่วงหลายปีของงานแคมเปญ และมีพื้นที่คุกกี้ที่ไม่จำเป็นที่ใหญ่ที่สุดที่ต้องควบคุม เว็บไซต์ Drupal 10 ทั่วไปที่รันสแต็กการวิเคราะห์ พิกเซลการตลาดอัตโนมัติ การฝังวิดีโอ แบบฟอร์มเว็บพร้อม reCAPTCHA และวิดเจ็ตการแชร์โซเชียลอาจส่งออกการดำเนินการจัดเก็บที่ไม่จำเป็นมากกว่าโหลรายการในการโหลดหน้าเดียว มักผ่านโมดูลที่ผู้ใช้งานดั้งเดิมไม่จำได้อีกต่อไปว่าได้กำหนดค่าไว้

การดำเนินการแต่ละรายการเหล่านี้ใช้งานประตูความยินยอมแยกต่างหาก ภายใต้ Article 5(3) ของ Directive ePrivacy คุกกี้ที่ไม่จำเป็นหรือการดำเนินการจัดเก็บและเข้าถึงที่คล้ายคลึงกันทุกรายการต้องการความยินยอมล่วงหน้าที่ให้โดยเสรี เฉพาะเจาะจง มีข้อมูล และชัดเจนใน EEA, UK และเขตอำนาจศาลใดๆ ที่นำมาตรฐานเดียวกันมาใช้ ภายใต้ GDPR ข้อมูลพฤติกรรมที่การดำเนินการจัดเก็บเหล่านั้นสร้างขึ้นคือการประมวลผลข้อมูลส่วนบุคคลเนื่องจากการรวมกันของตัวระบุคุกกี้ ที่อยู่ IP และรอยพฤติกรรมเพียงพอที่จะระบุตัวบุคคล คำถามด้านการปฏิบัติตามกฎระเบียบบนเว็บไซต์ Drupal จึงไม่ใช่ว่าจะติดตั้งแบนเนอร์หรือไม่ — ทุกทีมที่รับผิดชอบได้ทำสิ่งนั้นไปแล้ว — แต่ว่าแบนเนอร์นั้นป้องกันแท็กไม่ให้ทำงานก่อนที่ผู้ใช้จะให้ความยินยอมได้จริงหรือไม่ และการตัดสินใจความยินยอมรอดพ้นชั้นแคชของ Drupal หรือไม่

ภูมิทัศน์โมดูล: EU Cookie Compliance, Klaro และตัวเลือกที่รวมเข้ากับผู้จัดจำหน่าย

โมดูล EU Cookie Compliance — โมดูลที่สนับสนุนซึ่งดูแลรักษาบน Drupal.org ภายใต้ชื่อนั้น — คือค่าเริ่มต้นทางประวัติศาสตร์และตัวเลือกที่ใช้งานกันอย่างแพร่หลายที่สุด มันมาพร้อมกับแบนเนอร์ที่ปรับแต่งได้ รองรับหมวดหมู่ เปิดเผยสถานะความยินยอม JavaScript สำหรับโค้ดธีมเว็บไซต์ และจัดเก็บบันทึกความยินยอมในฐานข้อมูล Drupal จุดแข็งคือการผสานรวมที่ลึกกับระบบสิทธิ์และบทบาทของ Drupal รองรับหลายภาษาผ่านชั้นการแปลของ Drupal และความสามารถในการควบคุมแท็กที่ Drupal เรนเดอร์ตามหมวดหมู่ในระดับการสร้างหน้า จุดอ่อนคือ UI ของแบนเนอร์ล้าหลังมาตรฐานการออกแบบที่ผู้กำกับดูแลคาดหวังในตอนนี้ ป้ายกำกับหมวดหมู่เริ่มต้นคลุมเครือ และการโต้ตอบของโมดูลกับชั้นแคชของ Drupal ต้องการการกำหนดค่าอย่างชัดเจน

โมดูล Klaro Cookie & Consent Management เป็นตัวเลือกที่ใหม่กว่าที่ผสานรวมไลบรารี Klaro JavaScript — ตัวจัดการความยินยอมโอเพนซอร์สที่มี UI แบนเนอร์ที่ทันสมัยและการควบคุมรายละเอียดต่อบริการ จุดแข็งคือคุณภาพ UI ความละเอียดต่อบริการแทนที่จะต่อหมวดหมู่ และการพัฒนาต้นทางที่ดำเนินการอยู่ จุดอ่อนคือโมดูลบางกว่า EU Cookie Compliance ต้องการความพยายามด้านธีมมากขึ้น และผลักดันสถานะความยินยอมมากขึ้นไปยังไคลเอนต์ที่ต้องประสานกับการเรนเดอร์ฝั่งเซิร์ฟเวอร์ของ Drupal

ตัวเลือกที่รวมเข้ากับผู้จัดจำหน่าย — Cookiebot, OneTrust, Usercentrics และที่คล้ายคลึงกัน — เหมาะสมเมื่อเว็บไซต์เป็นส่วนหนึ่งของมรดกที่ทำให้เป็นมาตรฐานบน CMP เหล่านั้นอยู่แล้วในระดับองค์กร โดยทั่วไปแล้วตัวเลือกเหล่านี้มีความแข็งแกร่งที่สุดใน UI และเส้นทางการตรวจสอบ แต่แนะนำการพึ่งพาบุคคลที่สามที่ต้องจ่ายเงินและอาจต้องใช้ข้อตกลงการประมวลผลข้อมูลที่ผ่านเส้นทางการจัดซื้อแยกต่างหาก

กับดักแคชที่ทำลายการใช้งานความยินยอม Drupal ส่วนใหญ่

นี่คือปัญหาที่ทำให้เว็บไซต์ Drupal ที่กำหนดค่าอย่างถูกต้องในส่วนอื่นๆ จมลง: Internal Page Cache และ Dynamic Page Cache ที่ทำงานตามที่ออกแบบไว้จะให้บริการการเรนเดอร์หน้าที่แคชไว้แก่ผู้เยี่ยมชมที่ยังไม่เห็นแบนเนอร์ และการเรนเดอร์ที่แคชไว้อาจรวมแท็กสคริปต์หรือทรัพยากรภายนอกที่แบนเนอร์ควรจะควบคุม การแก้ไขไม่ใช่การปิดใช้งานแคช — นั่นทำลายเหตุผลที่องค์กรส่วนใหญ่เลือก Drupal — แต่เป็นการเรนเดอร์แท็กที่ควบคุมด้วยความยินยอมผ่านเส้นทางที่ชั้นแคชเคารพ

รูปแบบตัวยึดตำแหน่ง

รูปแบบที่ใช้งานได้ในการผลิตคือการเรนเดอร์แท็กที่ไม่จำเป็นทุกแท็กเป็นตัวยึดตำแหน่งใน HTML ที่แคชไว้ — โดยทั่วไปคือแท็ก <script type="text/plain"> ที่มีแอตทริบิวต์หมวดหมู่ หรือองค์ประกอบกำหนดเองที่ JavaScript ของโมดูลความยินยอมเปิดใช้งานเฉพาะในฝั่งไคลเอนต์เท่านั้นหลังจากที่ประตูที่เกี่ยวข้องเปิดขึ้น หน้า Drupal ในตัวมันเองสามารถแคชได้เพราะตัวยึดตำแหน่งเหมือนกันสำหรับทุกผู้เยี่ยมชม ลอจิกการเปิดใช้งานอยู่ใน JavaScript ของโมดูลความยินยอมและทำงานในเวลาไฮเดรชันเทียบกับสถานะความยินยอมต่อผู้เยี่ยมชมที่จัดเก็บไว้ในเบราว์เซอร์ EU Cookie Compliance รองรับรูปแบบนี้ได้ทันที สำหรับ Klaro ตัวเทียบเท่าคือกลไกการแทนที่สคริปต์ต่อบริการที่ไลบรารีต้นทางจัดให้

ชั้น render-cache และ varnish

แคชเรนเดอร์ของ Drupal และ Varnish หรือ CDN แคชต้นทางใดๆ ต้องได้รับการกำหนดค่าให้แปรผันตามสถานะความยินยอมเฉพาะเมื่อสถานะความยินยอมเปลี่ยนแปลง HTML ที่เรนเดอร์แล้ว — ซึ่งด้วยรูปแบบตัวยึดตำแหน่งไม่เกิดขึ้น แบนเนอร์ในตัวมันเองเรนเดอร์เป็นบล็อกที่แคชได้แยกต่างหากพร้อมบริบทที่แยกความแตกต่างระหว่าง "ต้องการแบนเนอร์" กับ "ไม่ต้องการแบนเนอร์" และส่วนที่เหลือของหน้าเรนเดอร์เหมือนกันโดยไม่คำนึงถึงสถานะความยินยอม นี่คือทางเลือกทางสถาปัตยกรรมที่ทำให้ชั้นแคชของ Drupal เข้ากันได้กับการปรับใช้ที่ให้ความยินยอมเป็นสิ่งสำคัญอันดับแรก ทางเลือก — การเรนเดอร์หน้าต่างกันตามสถานะความยินยอมและปิดใช้งานแคชสำหรับผู้ใช้ที่ตัดสินใจแล้ว — คือสิ่งที่ทำให้เกิดพฤติกรรมหน้าช้าหลังจากยอมรับซึ่งทำให้ผู้ใช้ปิดแบนเนอร์

รูปแบบการผสานรวมทีละโมดูล

งานผสานรวมบนเว็บไซต์ Drupal ส่วนใหญ่เกี่ยวกับการเชื่อมต่อสถานะความยินยอมกับโมดูลที่ปล่อยคุกกี้ที่ไม่จำเป็นหรือทรัพยากรภายนอก รูปแบบซ้ำตัวเองในระบบนิเวศโมดูลที่สนับสนุน

• โมดูล Google Analytics และ โมดูล Google Tag Manager ต้องได้รับการกำหนดค่าให้เรนเดอร์แท็กเป็นตัวยึดตำแหน่งที่ควบคุมด้วยความยินยอม โดยแมปหมวดหมู่ความยินยอมกับประตูการวิเคราะห์ โมดูลทั้งสองเปิดเผย hook ที่โมดูล EU Cookie Compliance สามารถเชื่อมต่อได้
• โมดูล Webform พร้อม reCAPTCHA เป็นการรั่วไหลเล็กน้อยที่พบบ่อยที่สุด: reCAPTCHA ตั้งค่าคุกกี้ที่ไม่จำเป็นเมื่อโหลดแม้กระทั่งก่อนที่ผู้ใช้จะส่งแบบฟอร์ม การแก้ไขคือการควบคุมไลบรารี reCAPTCHA ไว้หลังหมวดหมู่การทำงานหรือการตลาดที่เกี่ยวข้อง หรือใช้ตัวแปร invisible-v3 ที่เลื่อนการเขียนคุกกี้ไปจนถึงการส่งแบบฟอร์ม
• การฝังวิดีโอของโมดูล Media จาก YouTube, Vimeo หรือ Brightcove ต้องใช้โหมดเพิ่มความเป็นส่วนตัวหรือห่อในตัวยึดตำแหน่งคลิกเพื่อโหลดที่เลื่อนคำขอบุคคลที่สามจนกว่าผู้ใช้จะเปิดใช้งาน รูปแบบ Lite YouTube Embed คือสิ่งเทียบเท่าที่ธีม Drupal หลายธีมได้นำมาใช้
• วิดเจ็ตการแชร์โซเชียล จากผู้จัดจำหน่ายดั้งเดิมเป็นรูปแบบยุค 2010 ที่ควรเลิกใช้เพื่อสนับสนุนลิงก์แชร์แบบสถิตที่ไม่โหลด JavaScript บุคคลที่สามเลย หากวิดเจ็ตของผู้จัดจำหน่ายต้องอยู่ต่อไปก็ให้อยู่หลังประตูการตลาด
• Drupal Commerce และคุกกี้ที่เกี่ยวข้องกับตะกร้าสินค้าถือเป็นสิ่งจำเป็นอย่างเคร่งครัดและไม่ต้องการความยินยอม แต่ตัวระบุโปรแกรมความภักดี คุกกี้เอนจินแนะนำ และเหตุการณ์ตะกร้าที่เชื่อมกับการวิเคราะห์ต้องการประตูที่เหมาะสม

การตรวจสอบ เส้นทางการตรวจสอบ และมุมมองหลายภาษา

ขั้นตอนการตรวจสอบบนเว็บไซต์ Drupal คือลำดับการตรวจสอบสี่ขั้นตอนเดียวกันที่ใช้ทุกที่: การเยี่ยมชมโดยไม่มีการดำเนินการต้องไม่สร้างคุกกี้ที่ไม่จำเป็น การเยี่ยมชมแบบปฏิเสธต้องคงสถานะนั้นไว้ การเยี่ยมชมแบบยอมรับต้องสร้างเฉพาะแท็กที่ยินยอม และการถอนความยินยอมต้องหยุดการยิงแท็กต่อไปทันทีและหมดอายุคุกกี้ที่เกี่ยวข้อง โดยเฉพาะใน Drupal การตรวจสอบนี้ต้องดำเนินการด้วยแคชหน้าที่ร้อน — ไม่ข้ามผ่าน — เพื่อยืนยันว่ารูปแบบตัวยึดตำแหน่งทำงานอย่างถูกต้องภายใต้สภาพการจราจรที่สมจริง

เส้นทางการตรวจสอบใน Drupal ได้ประโยชน์จากจุดแข็งของแพลตฟอร์ม EU Cookie Compliance จัดเก็บบันทึกความยินยอมในฐานข้อมูลพร้อมการประทับเวลาและสถานะหมวดหมู่ Klaro สามารถกำหนดค่าให้ทำเช่นเดียวกันผ่าน hook ฝั่ง Drupal เส้นทางใดเส้นทางหนึ่งสร้างบันทึกความยินยอมที่สอบถามได้ซึ่งสามารถตอบสนองต่อคำขอของผู้กำกับดูแล มุมมองหลายภาษาก็มีความสำคัญเช่นกัน: ชั้นการแปลของ Drupal ขยายไปถึงข้อความแบนเนอร์ความยินยอม ดังนั้นประกาศความเป็นส่วนตัวและป้ายกำกับหมวดหมู่ต้องได้รับการแปลสำหรับทุกภาษาที่เว็บไซต์ให้บริการ และบันทึกความยินยอมต้องบันทึกว่าผู้ใช้เห็นเวอร์ชันภาษาใดจริงๆ การปรับใช้ Drupal ที่ป้องกันได้ในปี 2026 คือการที่ทางเลือกโมดูล รูปแบบแคช การผสานรวมต่อโมดูล และเส้นทางการตรวจสอบหลายภาษาได้รับการพิจารณาร่วมกัน — และที่ทางเลือกของ Drupal เป็นแพลตฟอร์มพื้นฐานถูกเปลี่ยนจากความรับผิดชอบในการแคชเป็นข้อได้เปรียบด้านความยินยอม