Joomla! Documentation™

Untuk melaporkan bug ke penelusur bug Joomla, anda harus membuat item penelusur. Setelah dibuat, developer akan memeriksa validitasnya dan mengambil tindakan. Jika anda ingin membantu pengujian patch Joomla, silakan ikuti petunjuk detail mengenai bagaimana caranya.

Melaporkan bug

Pendaftaran Akun di GitHub

Anda harus punya akun di GitHub; Joomla! Issue Tracker menggunakan akun-akun GitHub sebagai pengesahan.

Akses ke penelusur isu Joomla!

• Joomla! Issue Tracker- Open

Periksa apakah bug yang ingin dilaporkan sudah pernah dilaporkan

Bermacam filter untuk menampilkan item penelusur dan dapat diakses dengna mengeklik tombol "Search Tools" di bagian paling atas. Jika isu yang anda alami belum pernah dilaporkan, klik tombol "New Item" yang ada di navigasi.

Halaman baru akan ditampilkan dan di sana, semakin banyak informasi yang anda berikan, akan semakin mempermudah developer.

Masukkan data yang diinginkan sebanyak-banyaknya. Anda dapat mengaktifkan tips untuk setiap bidang yang ada di sana dengan mengalihkan toggle "View Mode" Pro atau Help yang ada di sebelah kanan.

• Priority : Gunakan standar "Medium" kecuali anda paham mengenai kode untuk pilihan lainnya.
• Build : Ketik versi yang terkena dampak isu.
• Categories : Ini sedikit rumit. Gunakan saja "Administrasi" jika anda tidak mengerti.
• Title : Ringkasan isu.
• Description : Rincian isu. Lihat bagian di bawah untuk lebih lengkapnya.
• Uploads : Pengguna dibolehkan untuk mengupload gambar ke laporan. Persyaratan upload ada di formulir laporan.

Berikan ringkasan

Jelaskan dengan singkat isu yang anda alami. Manfaatkan item penelusur yang sudah ada sebagai contoh jika ini adalah pertama kalinya anda melaporkan bug.

Contoh:

• Front-end: Peringatan ini dan itu.
• Back-end: Tidak dapat menyimpan artikel ketika "namaplugin" diaktifkan.

Catatan: Perjelas ringkasan anda karena ini adalah apa yang dilihat developer pertama kali saat mereka meneliti penelusur sebelum memperbaiki masalahnya.

Berikan detail bug

Agar informasinya lengkap sebanyak mungkin, penelusur membagi deskripsi ke dalam lima sub bagian templat.:

• Steps to reproduce the issue : Langkah-langkah detail bagaimana seseorang dapat menghasilkan kembali isu tersebut.
• Expected result : Apa yang anda harapkan terjadi saat melakukan langkah di atas.
• Actual result: Apa yang sebenarnya terjadi saat melakukan langkah di atas.
• System information : Informasi mengenai lingkungan sistem anda. Termasuk browser apa yang digunakan, versi PHP server anda, atau jenis database yang digunakan website anda. Agar hasilnya optimal, anda bisa salin data dari Informasi Sistem website anda saat login ke Administrasi.
• Additional comments : Informasi tambahan yang tidak dicakup pada bagian-bagian di atas yang bisa jadi menguntungkan untuk menemukan dan memecahkan permasalahannya.

Format umumnya bisa seperti ini:

1. "Here is exactly what I did."
2. "This is what happened."
3. "This is what I think should have happened."
4. "Other information, possible solution, proposed code patch."

Semakin rinci akan semakin baik. Juga, penting untuk dapat menghasilkan kembali bug tersebut dengan contoh website Joomla! yang mudah dan petunjuk yang jelas bagaimana mendapatkannya. Ingat bahwa orang lain tidak akan dapat mengakses database website anda, jadi anda harus dapat memberitahukan bagaimana orang lain dapat melihat bug tersebut dengan data yang siap tersedia -- dengan contoh website.

Contoh A

What I did

Started with sample website. Everything was ok. I enabled "nameofplugin". Try to save any article from back end.

What happened

I get a blank screen and article is not saved.

What should have happened

Articles should save correctly.

Other information

These are the plugins enabled at the same time. SEF is on (or Off). My site is in a sub-folder. I also remark that... etc. Files such and such are the issues IMHO (if you know what you are talking about).

Contoh B

What I did

Navigate to Back-end. Click on "menu_name" Menu.

What happened

Page opened is blank.

What should have happened

Menu should have opened correctly.

Other information

Any other menu works OK. etc.

Contoh Nyata

• What I did

1. Started with the sample website.
2. Added an unpublished article from the back end, with Section=FAQ, Category=General.
3. In the advanced parameters for the article, set Show Title to "No" and Print, PDF, and Email Icons to "Hide".
4. Save the article and navigate to front end. Login to the front end as admin and navigate to the Example Pages -> Category Blog menu item.

• What happened : The newly added article shows but there is no edit icon for the front-end user to click on.
• What should have happened : The edit icon should show, allowing a front end user to edit this article.
• Other information : This only happens with the rhuk_milkyway template. By changing this code [code proposed] in file [name and hierarchy of file], line(s) #, the issue looks solved on my settings.

Tambahkan pull request secara langsung di repositori GitHub Joomla!

Apabila anda ingin mengajukan suatu perbaikan dengan memberikan kode secara langsung ke Joomla, lakukanlah dengan membuat "pull request" ke repositori kode Joomla! di GitHub.com yang ada di sini: https://github.com/joomla/joomla-cms

Proses ini memerlukan pengetahuan mengenai sistem Source Control Management dan Git khususnya. Jika anda tidak tahu apa itu Git SCM dan bagaimana cara kerjanya, prosesnya sederhana:

• Daftarkan akun gratis GitHub.com
• Fork repo Joomla!
• Lihat ke cabang "staging" jika anda ingin mengajukan perbaikan ke rilis Joomla! 3.x atau cabang yang lain apabila anda ingin mengajukan perbaikan ke Versi Joomla! berikutnya.
• Tambah/update file-file terkait dengan Joomla! di dalam cabang yang benar lalu klik tombol "review & compare" - selengkapnya bisa dibaca di sini https://help.github.com/articles/using-pull-requests - memulai proses "pull request".

Tips dan Trik tambahan

Laporan bug yang ditulis dengan baik sangat membantu. Namun, ada beberapa hal lain sehubungan dengan cara kerja sistem penelusuran bug mana pun, jadi sangat dihargai apabila anda membantu dengan penelusur tiket yang berguna. Khususnya:

• Bacalah FAQ untuk melihat apakah isu anda merupakan pertanyaan yang sangat dikenal.
• Lakukanlah penelusuran untuk melihat apakah isu anda sudah pernah ada.
• Tanyakan ke forum Joomla 3.x sebelumnya apabila anda tidak yakin apakah yang anda temukan itu bug atau bukan.
• Tulis laporan bug yang lengkap, dapat diproduksi ulang, dan spesifik. Masukkan informasi sebanyak-banyaknya, lengkapi dengan contoh-contoh kode, uji kasus, dll. Contoh minimal yang menggambarkan bahwa bug tersebut adalah suatu uji kasus sederhana adalah laporan bug yang paling baik.
• Jangan pakai sistem penelusur untuk bertanya. Gunakan Joomla! forum untuk hal-hal itu.
• Jangan gunakan penelusur untuk meminta fitur berskala besar. Kami senang sekali berdiskusi mengenai kemungkinan peningkatan kode inti Joomla! melalui forum developer sebelum mulai mengerjakannya.
• Jangan membuka kembali isu-isu yang sudah ditandai dengan "expected behaviour". Tanda ini artinya bahwa keputusan telah dibuat yang menyatakan kami tidak dapat atau tidak akan memperbaiki isu tersebut. Jika anda tidak mengerti, silakan bertanya ke forum developer.
• Jangan gunakan penelusur sebagai tempat diskusi yang panjang lebar, karena kemungkinannya akan tersesat. Jika item penelusur tertentu sifatnya kontroversial, silakan diskusikan ke forum developer.

Melaporkan isu keamanan

Laporkan isu-isu keamanan ke security [at] joomla [dot] org. Ini adalah daftar email privat yang hanya terbuka untuk para developer Joomla! lawas dan sangat terpercaya, yang arsipnya tidak dapat dibaca secara umum.

Dalam kasus kerentanan terkonfirmasi di Joomla! itu sendiri, kami akan ambil tindakan-tindakan berikut:

• Memberitahukan kepada pelapor bahwa kami telah menerima laporannya dan perbaikan akan segera dilakukan. Kami akan berikan jangka waktu kasar dan meminta pelapor untuk menjaga kerahasiaan isu tersebut sampai kami mengumumkannya.
• Menangguhkan pengembangan lain selama waktu untuk memperbaiki isu itu dilakukan, termasuk patch ke rilis saat ini dan dua rilis sebelumnya.
• Menentukan tanggal go-publik untuk pengumuman kerentanan dan perbaikannya. Mencoba untuk mengurangi kemungkinan "adu otot" antara penerapan patch dan eksploitasi, kami tidak akan mengumumkan masalah keamanan secepatnya.
• Mengumumkan secara publik mengenai kerentanan tersebut dan perbaikannya pada tanggal go-publik yang sudah ditetapkan sebelumnya. Ini bisa jadi berupa rilis baru Joomla! tetapi dalam banyak kasus hanya berupa patch sederhana ke rilis saat ini.