Menu Lain
Daftar BacaGanti TemaCari
Reading List

Queue · 0 items

Daftar baca Anda kosong. Simpan artikel untuk membacanya nanti.

Start Reading

Studi Kasus: Bug Komentar Disqus Akibat Beda URL? Ini Solusinya!

Iwan Efendi3 min
Ini adalah momen yang akrab bagi setiap pemilik situs: Anda mendapatkan notifikasi email yang sudah lama ditunggu-tunggu, "Seseorang baru saja mengomentari artikel Anda!" Anda dengan penuh semangat mengklik tautan "Lihat Komentar", tetapi browser Anda membuka URL yang aneh dan panjang seperti https://...cloudworkstations.dev/... atau https://ir-web.vercel.app/..., bukan domain produksi Anda https://snipgeek.com. Ini bukan hanya mengganggu; ini adalah gejala dari masalah teknis yang lebih dalam yang dapat memecah basis komentar Anda dan merusak pengalaman pengguna. Kami baru-baru ini menghadapi masalah ini secara langsung. Ini adalah studi kasus transparan tentang penyebabnya, berbagai upaya perbaikan kami, dan solusi akhir yang pada akhirnya menyelesaikan masalah.

Bab 1: Diagnosis Awal - Lingkungan Berbeda, URL Berbeda

Masalah ini berakar pada cara Disqus mengidentifikasi sebuah halaman. Layanan komentar mengunci utas diskusi ke URL pertama tempat ia dirender.
  • Saat kita bekerja di lingkungan pengembangan, URL-nya adalah http://localhost:3000 atau https://...cloudworkstations.dev.
  • Saat Vercel membuat pratinjau, URL-nya adalah https://ir-web.vercel.app.
  • Hanya di situs langsung, URL-nya adalah https://snipgeek.com.
Karena Disqus melihat ketiga URL ini sebagai tiga halaman yang sama sekali berbeda, utas komentar menjadi terfragmentasi. Notifikasi email akan selalu menunjuk ke URL tempat komentar pertama kali "dilihat".

Bab 2: Perburuan Solusi - Dari NODE_ENV ke Nama Domain

Kami mencoba beberapa perbaikan, masing-masing dengan pelajarannya sendiri.

Upaya #1: Memeriksa process.env.NODE_ENV

Ide awalnya adalah memuat Disqus hanya jika NODE_ENV adalah "production". Ini gagal. Kami dengan cepat menyadari bahwa pratinjau penerapan di Vercel juga berjalan dalam mode production, sehingga masalah tetap ada.

Upaya #2 (Solusi Akhir): Isolasi Berdasarkan Nama Domain

Setelah beberapa kegagalan, kami sampai pada solusi yang paling kuat dan antipeluru: mencegah Disqus dimuat sama sekali kecuali diakses dari domain produksi akhir. Ini menyelesaikan masalah pada akarnya. Jika komponen Disqus tidak pernah dirender di localhost, cloudworkstations.dev, atau vercel.app, tidak mungkin ia mendaftarkan URL yang salah. Kami menerapkan ini langsung di dalam komponen PostComments.tsx dengan memeriksa window.location.hostname.
'use client';

// ...

const productionHostname = 'snipgeek.com'; // Domain produksi akhir

export function PostComments({ article }: PostCommentsProps) {
  const [shouldLoad, setShouldLoad] = useState(false);
  const commentsRef = useRef<HTMLDivElement>(null);

  useEffect(() => {
    // Observer untuk lazy-load
    const observer = new IntersectionObserver(([entry]) => {
      // Saat komponen masuk ke viewport...
      if (entry.isIntersecting) {
        // ...periksa apakah hostname adalah domain produksi.
        if (window.location.hostname === productionHostname) {
            setShouldLoad(true);
        }
        observer.disconnect(); // Berhenti mengamati setelah pemeriksaan.
      }
    });

    if (commentsRef.current) observer.observe(commentsRef.current);
    return () => observer.disconnect();
  }, []);

  if (!shouldLoad) {
    // Tampilkan placeholder jika tidak di situs produksi
    return (
      <div ref={commentsRef} className="text-center ...">
        <p>Komentar hanya tersedia di situs produksi (snipgeek.com).</p>
      </div>
    );
  }

  // Jika di situs produksi, render Disqus dengan URL yang benar
  const canonicalUrl = `https://${productionHostname}/blog/${article.slug}`;

  return (
    <DiscussionEmbed
      shortname={disqusShortname}
      config={{ url: canonicalUrl, ... }}
    />
  );
}
Pendekatan ini sangat spesifik: ia memeriksa di mana pengguna berada, bukan hanya mode aplikasi yang sedang berjalan.

Bab 3: Awal yang Baru dengan Shortname Bersih

Bahkan setelah perbaikan kode, kami memutuskan untuk mengambil satu langkah ekstra untuk memastikan tidak ada masalah di masa depan: menggunakan shortname (ID situs) Disqus yang sama sekali baru. Alasannya: Shortname lama sudah "terkontaminasi" dengan URL pengembangan dan pratinjau dari pengujian kami sebelumnya. Meskipun kami bisa menggunakan alat migrasi Disqus, memulai dengan shortname "bersih" yang belum pernah melihat URL selain domain produksi adalah jaminan terbaik untuk stabilitas jangka panjang. Kami memutuskan untuk menggunakan ID snipgeek-com untuk produksi akhir.

Kesimpulan: Pelajaran yang Didapat

Perjalanan debugging ini mengajarkan kami pelajaran penting: ketika berhadapan dengan layanan pihak ketiga yang sensitif terhadap URL (seperti Disqus atau sistem komentar lainnya), solusi teraman adalah dengan mengisolasi mereka secara ketat ke domain produksi akhir, bukan hanya ke "mode produksi". Ini mencegah "kebocoran" konfigurasi dari lingkungan pratinjau dan memastikan integritas data Anda di situs langsung. Terkadang, memulai kembali dengan konfigurasi yang bersih adalah jalan tercepat menuju solusi yang stabil.
Topics

Topik dalam catatan

Jelajahi pembahasan serupa lewat topik-topik terkait berikut.

Bagikan artikel ini

Diskusi

Menyiapkan area komentar...

Anda Mungkin Juga Suka