Studi Kasus Disqus: Mengapa Notifikasi Komentar Saya Mengarah ke URL yang Salah?

Ini adalah momen yang familiar bagi setiap pemilik situs: Anda mendapatkan notifikasi email yang ditunggu-tunggu, "Seseorang baru saja mengomentari artikel Anda!" Anda dengan semangat mengklik tautan "Lihat Komentar", namun browser Anda malah membuka URL yang aneh dan panjang seperti https://...cloudworkstations.dev/... atau https://ir-web.vercel.app/..., bukan domain produksi https://irweb.info milik Anda.

Ini bukan hanya mengganggu, ini adalah gejala dari masalah teknis yang lebih dalam yang dapat memecah belah basis komentar Anda dan merusak pengalaman pengguna. Baru-baru ini kami menghadapi masalah ini secara langsung. Ini adalah studi kasus transparan tentang penyebabnya, berbagai upaya perbaikan kami, dan solusi final yang akhirnya menuntaskan masalah ini.

Babak 1: Diagnosis Awal - Lingkungan yang Berbeda, URL yang Berbeda

Masalahnya berakar pada cara Disqus mengidentifikasi sebuah halaman. Layanan komentar ini mengunci utas diskusi ke URL pertama tempat ia dirender.

• Saat kami 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://irweb.info.

Karena Disqus melihat ketiga URL ini sebagai tiga halaman yang sama sekali berbeda, utas komentar menjadi terpecah-belah. Notifikasi email akan selalu menunjuk ke URL tempat komentar itu pertama kali "dilihat".

Babak 2: Perburuan Solusi - Dari NODE_ENV hingga Nama Domain

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

Upaya #1: Memeriksa process.env.NODE_ENV

Ide awalnya adalah hanya memuat Disqus jika NODE_ENV adalah "production". Ini gagal. Kami segera menyadari bahwa deployment preview di Vercel juga berjalan dalam mode production, sehingga masalah tetap terjadi.

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

Setelah beberapa kali gagal, kami sampai pada solusi yang paling kuat dan anti-gagal: mencegah Disqus dimuat sama sekali kecuali jika diakses dari domain produksi final.

Ini memecahkan masalah pada akarnya. Jika komponen Disqus tidak pernah dirender di localhost, cloudworkstations.dev, atau vercel.app, maka tidak mungkin ia bisa mendaftarkan URL yang salah.

Kami mengimplementasikan ini langsung di dalam komponen PostComments.tsx dengan memeriksa window.location.hostname.

'use client'; 

// ...

const productionHostname = 'irweb.info';  // Domain produksi final

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 viewport...
      if (entry.isIntersecting) {
        // ...periksa apakah hostname-nya adalah domain produksi.
        if (window.location.hostname === productionHostname) {
            setShouldLoad(true);
        }
        observer.disconnect(); // Hentikan observing setelah pengecekan.
      }
    });

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

  if (!shouldLoad) {
    // Tampilkan placeholder jika bukan di situs produksi
    return (
      <div ref={commentsRef} className="text-center ...">
        <p>Komentar hanya tersedia di situs produksi (irweb.info).</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 berjalan.

Babak 3: Awal yang Baru dengan Shortname Bersih

Bahkan setelah perbaikan kode, kami memutuskan untuk mengambil satu langkah ekstra untuk menjamin tidak ada masalah di masa depan: menggunakan shortname (ID situs) Disqus yang benar-benar baru.

Alasannya: Shortname yang lama sudah "terkontaminasi" dengan URL pengembangan dan pratinjau dari tes-tes kami sebelumnya. Meskipun kita bisa menggunakan alat migrasi Disqus, memulai dengan shortname yang "bersih" dan belum pernah melihat URL selain domain produksi adalah jaminan terbaik untuk stabilitas jangka panjang. Kami memutuskan untuk menggunakan ID ie-irweb-info untuk produksi final.

Kesimpulan: Pelajaran yang Didapat

Perjalanan debugging ini mengajarkan kami pelajaran penting: saat berhadapan dengan layanan pihak ketiga yang sensitif terhadap URL (seperti Disqus atau sistem komentar lainnya), solusi paling aman adalah dengan mengisolasinya secara ketat ke domain produksi final, bukan hanya ke "mode produksi". Ini mencegah "kebocoran" konfigurasi dari lingkungan pratinjau dan memastikan integritas data Anda di situs langsung. Terkadang, memulai dari awal dengan konfigurasi yang bersih adalah langkah tercepat menuju solusi yang stabil.