Documentatie · Ontwikkelaarsdocumentatie

Coding-standaarden

Deze pagina beschrijft de conventies waaraan een bijdrage aan de plugin moet voldoen, op een niveau dat veilig is om te publiceren. Interne klassenamen, interne constanten, capability-identifiers en conventies voor optiesleutels zijn implementatiedetails en worden hier niet gepubliceerd.

Wanneer u dit document gebruikt

Gebruik dit document wanneer u:

  • Op het punt staat PHP, JavaScript, CSS, templates of vertaalbare strings toe te voegen aan een bijdrage.
  • Een pull request beoordeelt en een referentie nodig heeft voor wat "consistent met de codebase" betekent.
  • De plugin uitbreidt vanuit een aparte plugin of een thema en wilt dat uw eigen code natuurlijk aanvoelt.

PHP

  • Taalniveau. Richt u op de PHP-versie die in de plugin-header als minimum is gedeclareerd. Vermijd functies die daar niet beschikbaar zijn.
  • Type-declaraties. Gebruik scalar- en return-type-declaraties bij nieuwe methoden, in lijn met de omringende code.
  • WordPress-stijl. Volg de WordPress PHP-coding-standaarden (tabs voor inspringing, spaties binnen haakjes, Yoda-voorwaarden waar de codebase deze al gebruikt, snakecase voor functies en methoden, TitleCaseWithUnderscores voor klassenamen).
  • Eén klasse per bestand. Elk PHP-bestand bevat één klasse. Bestandsnamen komen overeen met klassenamen in kleine letters en met koppeltekens, consistent met de conventies die al in de codebase aanwezig zijn.
  • Geen nieuwe globals. Geef de voorkeur aan klasseconstanten en dependency injection boven verspreide globals.

WordPress-integratie

  • Eerst capability-controles. Elke bevoorrechte actie moet de juiste capability controleren voordat er werk wordt verricht.
  • Nonce-controles voor formulieren en admin AJAX. Gebruik de standaard WordPress nonce-API's (check_admin_referer, check_ajax_referer, wp_verify_nonce) voor elk eindpunt dat de status wijzigt.
  • Sanitisation en escaping. Saniteer bij invoer en escape bij uitvoer met behulp van de juiste WordPress-API's voor het type en de uitvoercontext. Zie Sanitisation en escaping.
  • i18n. Omhul voor de gebruiker bestemde strings met het textdomain van de plugin. Zie Internationalisering voor ontwikkelaars.
  • Logging. Gebruik de gedeelde logger van de plugin in plaats van PHP's error_log rechtstreeks aan te roepen vanuit nieuwe functionaliteitscode.

JavaScript en CSS

  • De plugin maakt geen gebruik van een JavaScript-build-pipeline; assets worden als gewone bestanden geleverd.
  • Houd front-end JavaScript vrij van afhankelijkheden en progressief; de plugin moet blijven werken in browsers die scripts van derden blokkeren.
  • Voorzie nieuwe CSS-klassen consistent van een prefix volgens de bestaande front-end- en admin-conventies om conflicten met thema's te voorkomen.

Tests

  • Nieuwe gedragswijzigingen moeten worden gedekt door tests waar ze redelijkerwijs door unit-tests kunnen worden getoetst.
  • Geef nieuwe testklassen een naam naar de klasse of het gedrag dat wordt getest met een Test-achtervoegsel, in lijn met bestaande tests.
  • Zie de Testgids voor de algemene testwerkstroom.

Documentatie

  • Werk de relevante pagina's onder docs/en/ bij telkens wanneer een bijdrage openbaar waarneembaar gedrag verandert.
  • Houd documentatie veilig voor het publiek; voeg geen interne klassenamen, optiesleutels, REST/AJAX-routenamen of capability/nonce-identifiers toe aan de openbare documentatieset.

Kennisgeving openbare documentatie. Deze pagina biedt uitsluitend een globaal integratie-overzicht. Interne implementatiedetails, privé-API's, opslagdetails en beveiligingsgevoelige release-infrastructuur worden afzonderlijk beheerd en maken geen deel uit van de openbare documentatie.