미디어위키 개발자가 되는 방법

이 문서는 개발자가 미디어위키 코어 및 미디어위키 확장 개발에 기여하는 데 필요한 기본 기술을 배우도록 돕기 위해 작성되었습니다.

미디어위키에 기여하는 것이 어려운 경우가 많으므로 대신 위키미디어 개발에 참여하고 싶다면 멘토링을 제공하는 위키미디어 프로젝트에 기여해야 합니다. 멘토링이 없는 대안은 좋은 첫 번째 버그를 수정하는 것입니다.

이미 미디어위키 개발에 익숙하다면, 개발자 허브 를 방문하십시요.

위키미디어 공동체에 참여하는 다른 방법을 보려면 기여하는 방법 항목을 참고하십시오.

개요

미디어위키는 위키백과, 위키백과의 자매 프로젝트, 그리고 전 세계 수천 개의 위키 사이트를 지원하는 소프트웨어입니다.

대부분의 미디어위키와 확장기능은 PHP 프로그래밍 언어로 작성되었습니다. JavaScript is used for providing interactive interface elements along with jQuery and Vue.js as client JavaScript libraries.

Some supporting tools are written in other languages, including batch files, shell scripts, makefiles and Python.

미디어위키는 주로 LAMP 플랫폼용으로 작성되었으며 대부분의 운영 체제에서 실행됩니다. 미디어위키는 주로 MySQL 또는 MariaDB 데이터베이스 서버를 사용합니다.

개발은 오픈 소스 스타일로 이루어지며, 대부분 온라인에서 조정되고 위키미디어 재단의 지원을 받지만, 자원 봉사 커뮤니티 개발자들도 큰 역할을 합니다.

• 개발 토론은 파브리케이터 와 메일링 리스트 , IRC 채널들에서 이루어지고 있습니다. 메인 개발자 목록은 wikitech-l에 있습니다. 주요 개발자 IRC 채널은 #mediawiki ^connect 및 #wikimedia-dev ^connect입니다.
• 소스 코드는 게릿 에 저장되어 깃 버전 관리 시스템을 사용하여 관리되며 여기서 볼 수 있습니다.
• 코드 검토는 게릿 에서 수행되며 여기에서 볼 수 있습니다. 패치를 제출하기 위해 깃과 게릿을 설정하려면 이 튜토리얼을 따르세요.
• 버그 보고서와 기능 요청이 접수되고 프로젝트가 조정되는 곳은 파브리케이터 이며, 여기에서 볼 수 있습니다.

Find or create a task

Before you ever develop a feature or fix a bug in a MediaWiki project, it is important that you do your research about it. This includes:

1. Search Phabricator if an open or closed Task (Document Types field) already exists. If it doesn't, create one. If this is a very small change, don't create one.
2. Find and investigate the code that needs to be changed to implement the feature. Comment your findings on the Phabricator Task if they might be helpful to others who implement it or review your changes.
3. Determine if you can likely add the feature or fix the bug based the code you investigated and the changes needed. If the task is large or complex, you should find something easier and work your way up to eventually be able to handle tasks of that size. If you believe you can complete it, assign yourself to the Task and begin working on it.

개발 환경 구축하기

Once you have found something you can work on, the next step to developing MediaWiki or an extension is creating an environment to run MediaWiki, its database, and any other external features so that you can develop and test them.

You can install and develop MediaWiki on Linux, Windows, or macOS using any of the three solutions below.

도커 개발 환경

• MediaWiki Docker – Docker를 사용하여 MediaWiki를 실행합니다(Linux, Windows 또는 macOS 호스트에서 사용할 수 있음).

Docker is a good option if you want to setup a MediaWiki installation quickly and are not planning on installing many extensions.

You can also try the mwcli tool which sets up Docker with a few simple commands and provides basic orchestration functionality between MediaWiki, MySQL, ElasticSearch, Memcached, and other types of containers.

Vagrant 를 이용한 가상 머신

• Vagrant 설치 — 이 단계는 Linux 가상 머신(Linux, Windows 또는 Mac 호스트에서 사용할 수 있음) 내부의 모든 요구 사항과 함께 MediaWiki 서버를 설치합니다.

Vagrant allows you start a MediaWiki instance you can develop as well as allowing you to add and develop any of 250+ extensions - all with a single command.

This saves you installation and configuration time compared to manually adding extensions in a Docker or local installation, but it runs a bit slower than the other two options.

수동 설치

• Local development quickstart – Run MediaWiki locally using PHP and Composer.

Local installation is a good option if you want to set up a simple development environment quickly without using Docker.

Open a code editor

The two recommended code editors for editing MediaWiki are VSCode and PhpStorm. VSCode is free and PhpStorm is paid, however, you can acquire a PhpStorm license for free if you are a student by linking your GitHub Education account to your JetBrains account, or by requesting a license granted to Wikimedia.

To determine which editor you should install and use, know that all-around, PhpStorm has more and more-powerful features than VSCode. However, PhpStorm takes significantly longer to load on start than VSCode as it builds an index of the entire repository whereas VSCode progressively loads. Therefore, VSCode is typically useful for file-viewing sessions or small changes and PhpStorm for larger changes. It makes sense to have both installed for these reasons.

To develop the MediaWiki codebase that is inside a Docker container you can establish a remote connection to it and open the MediaWiki folder inside it using VSCode or PhpStorm.

Change and test the code

Change the code and view your changes by reloading your MediaWiki browser tab. Make sure to follow Manual:Coding conventions . Write and run tests on your code to make sure it works and is formatted properly.

Note, you can save time by ensuring your changes will be accepted before taking the time to write tests. Create a patch without needed tests and ask for someone to review it stating that you will add tests after they review it.

Create a patch

Finally, to submit your code to be reviewed and added to the repository you are contributing to, follow Gerrit/Tutorial .

커뮤니케이션 팁 및 지침

개발자가 조사, git 커밋, 검토 및 병합, Bugzilla 티켓 닫기(현재 파브리케이터 으로 대체)를 포함하여 MediaWiki 확장의 버그를 수정하는 모습을 지켜보십시오.

Follow these tips to communicate effectively and get help from community members.

Use Phabricator tasks effectively

When you plan to work on a 파브리케이터 task:

• No need to ask for permission: You can work on unassigned tasks without asking someone to assign them to you. There is no authority who assigns tasks or who needs to be asked first.
  • If a task already has a recent patch in Gerrit, choose a different task to work on instead.
  • If an existing patch in Gerrit has not been merged and has not seen any changes for a long time, you could improve that existing patch, based on the feedback in Gerrit and in the task.
• Do your research: When you consider working on a task, do research before you start coding. Look at the code, try to understand what it is supposed to do, read related documentation, and try to find the places where you need to make code changes.
  • In a 파브리케이터 task, use the project tags in the side bar to find the code repository for the task.
  • If you have no idea at all how to fix the bug, consider finding an easier one first.
• You do not need to announce your plans before you start working on a task, but you should communicate that you are working on the task.
  • When you start work, set yourself as task assignee by clicking Edit Task… in Phabricator, and set your Phabricator username in the Assigned To field. This communicates to others that you are working on it, so they don't duplicate work.
  • When your plans or interests change: If you are no longer working on a task, remove yourself as the assignee of the task. This tells others that they can work on the task, and they won't expect you to still work on it.
• Follow Phabricator etiquette.
  • In Phabricator tasks, discuss only specific questions about the topic of that task. Don't use Phabricator to ask general questions, like how to set up a development environment or how to fix problems with Gerrit.

Compose good questions

• Don't ask to ask...just ask!.
• Be specific and provide context: Instead of simply asking "Can you give me more info?", "Please guide me", or "Please tell me how to start", include the following information in your question:
  • What are you trying to achieve?
  • What have you already tried? Copy and paste your commands and their output (if not too long) instead of paraphrasing in your own words.
  • What have you found out already during your research? Include links to code, documentation, or other resources you already consulted.
• Use specific titles and subject lines in your communication. "Proposal draft" or "Need help" is not specific.
• Keep conversations readable: When you reply in Zulip, in Phabricator tasks, or on mailing lists, only quote sections of previous comments that are relevant to your response. If you quote a complete previous comment, it makes threads hard to read.

Follow communication policies and best practices

Before you send or post your question:

• Read and follow the code of conduct for Wikimedia technical spaces.
• Use inclusive language : Instead of using terms that assume a gender identity (like "guys", "madam", or "sir") use the name of the person instead.

Ask in the right place

• Ask in public: Do not send private messages if your conversation topic is not secret. Private messages don't help others.
• Ask and discuss in the best place:
  • In Phabricator tasks, discuss only specific questions about the topic of that task.
  • Ask general technical questions, like how to set up a development environment or how to fix problems with Gerrit, in the places listed on 커뮤니케이션 .
  • If you take part in an outreach program, then Zulip is for discussing questions about the outreach programs themselves.

Be patient

After you post your question:

• Do not ask people for code review in a separate message. People receive Gerrit and Phabricator notifications and will respond when they can.
• When seeking input and comments, especially during weekends and holidays, you may need to wait until business hours resume. On chat channels like IRC: if nobody answers, try again at a different time; don't just give up!
• If you don't get an answer even after waiting and being patient, consider if other Communication channels might be a better place to ask your question.

부록

미디어위키 개발자들은 인도 방갈로르에서 일하는 중 입니다.

PHP

MediaWiki는 PHP로 작성되었으므로 MediaWiki의 핵심을 해킹하려면 PHP에 익숙해져야 합니다.

PHP 배우기

• PHP 튜토리얼 — 다른 수많은 언어로 이용할 수 있습니다. PHP에 대한 지식은 없지만 다른 객체 지향 프로그래밍 언어로 프로그래밍하는 방법을 알고 있다면 PHP를 쉽게 배울 수 있습니다.
• PHP Programming at Wikibooks.
• PHP at Wikiversity.

PHP 리소스

• PHP 매뉴얼 — 많은 다양한 언어로 사용가능합니다.
• PHP coding conventions 미디어위키 커뮤니티 내에 존재합니다.

알아야 할 것

• 미디어위키의 maintenance/eval.php 스크립트는 미디어위키 객체와 클래스가 로드된 기본 PHP 인터프리터를 제공합니다.
• 또한 MediaWiki의 maintenance/shell.php 스크립트는 PsySH를 기반으로 하는 maintenance/eval.php를 대체합니다. Manual:Shell.php

데이터베이스

많은 기능에는 어느 정도의 데이터베이스 조작이 필요하므로 MySQL/MariaDB에 익숙해야 하는 경우가 많습니다.

MySQL/MariaDB 배우기

• MySQL 튜토리얼 — MySQL 레퍼런스 메뉴얼부터
• MySQL at Wikibooks.

MySQL/MariaDB 리소스

• MySQL Reference Manuals — 많은 다양한 언어로 사용가능합니다.
• MariaDB Knowledge Base
• PHP coding conventions 미디어위키 커뮤니티 내에 존재합니다.
• 데이터베이스에 접근하기

알아야 할 것

• 당신의 MySQL/MariaDB 코드를 시험해 보세요.
  • 미디어위키는 현재 MySQL 및 MariaDB를 기본 데이터베이스 백엔드로 사용합니다. PostgreSQL 및 SQLite와 같은 다른 DBMS도 지원합니다. 그러나 거의 모든 개발자는 MySQL/MariaDB를 사용하고 다른 DB를 테스트하지 않기 때문에 정기적으로 중단됩니다. 따라서 특별히 다른 DB에 대한 지원을 개선하려는 것이 아니라면 패치를 테스트할 때 MySQL/MariaDB를 사용하는 것이 좋습니다. 후자의 경우 MySQL/MariaDB가 손상되지 않도록 주의하십시오(또는 끔찍하게 비효율적인 쿼리 작성). MySQL/MariaDB는 모두가 사용하는 것이기 때문입니다.

자바스크립트와 CSS

JavaScript와 CSS는 프론트 엔드 코드에서 어디에나 존재합니다. MediaWiki에서 작업하기 위해 JavaScript, jQuery 및 CSS에 익숙할 필요는 없지만 작업하기로 선택한 항목에 따라 필요할 수도 있습니다.

자바스크립트와 CSS 배우기

• JavaScript and CSS at Wikibooks.
• jQuery 시작하기 — jQuery 튜토리얼
• Learning JavaScript — references and sources.

자바스크립트와 CSS 리소스

• JavaScript 코딩 규칙 MediaWiki 커뮤니티 내에 존재합니다.
• CSS coding conventions MediaWiki 커뮤니티 내에 존재합니다.

MediaWiki

Introduction to MediaWiki core concepts

MediaWiki 코드 기반은 크고 일부는 보기 흉합니다. 그것에 압도되지 마십시오. 처음 시작할 때 기능을 작성하거나 코드의 작은 영역에만 영향을 미치는 버그를 수정하는 것을 목표로 하십시오.

미디어위키의 기본과 필독서

• MediaWiki 아키텍처 — MediaWiki의 주요 구성 요소와 이들이 서로 어떻게 작동하는지에 대한 높은 수준의 개요입니다.
• 개발자를 위한 보안 — 보안 코드를 작성하는 이유와 방법에 대한 개요입니다.

미디어위키 리소스

• Manual:Code — 중요한 파일 목록과 더 자세한 정보에 대한 링크.
• 메뉴얼:훅 — 후크 목록입니다. 코드베이스의 어떤 부분이 어떤 작업을 수행하는지 찾으려는 경우 관련 후크를 검색하는 것이 좋은 출발점인 경우가 많습니다.
• Manual:Coding conventions — 미디어위키 커뮤니티의 일반적인 코딩 규칙에 대한 개요입니다.
• 코드 문서 (class reference) — 코드 및 코드 주석에서 자동으로 생성된 문서.
• Manual:How to debug — 미디어위키 디버깅 가이드
• Manual:Eval.php — 라이브 미디어위키 개체와 상호 작용하는 도구입니다.

미디어위키 확장기능

Introduction to MediaWiki extensions

미디어위키 확장 코드에서 작업하기로 선택한 경우 다음 링크에서 추가 정보를 제공합니다.

미디어위키 확장 기본

• 확장 개발 — MediaWiki용 확장을 작성하는 방법.
• 확장 작성 튜토리얼

미디어위키 확장 리소스

• 확장에 대한 모범 사례
• MediaWiki 확장 개발에 대한 간략한 소개 — MediaWiki 확장을 만드는 방법에 대한 비디오 프레젠테이션(slides).
• MediaWiki 확장 프로그램 만들기 — MediaWiki용 확장 프로그램을 개발하는 방법, 모범 사례 및 MediaWiki 커뮤니티에 참여하는 방법을 다룹니다. 2011년 2월, 미디어위키 개발자 허브로부터
• 확장 개발자를 위한 도움말 개발자 허브

MediaWiki skins

메뉴얼:미디어위키 스킨 만드는 방법 is helpful if you choose to work on MediaWiki skins.

같이 보기

• 저장소 전체에서 코드 검색
• 개발자 허브 – 이 문서의 정보를 완전히 읽었으면 개발자 허브의 정보로 넘어갈 차례입니다.
• 행동 강령

Footnotes