Share
Als u iemand bent die WordPress gebruikt om uw brood te verdienen en uw verhaal te vertellen, is het behoorlijk opwindend om een wijziging te zien die u hebt toegevoegd aan de WordPress-codebasis. Ik weet dat het voor mij was.
In deze tutorial leert u de paar eenvoudige dingen die u moet weten om een patch voor WordPress te maken die kan worden geaccepteerd in de kernsoftware.
Hoewel WordPress open-source software is die iedereen kan downloaden en wijzigen, zijn slechts een handvol kernbijdragers in staat om hun wijzigingen in WordPress zelf vast te leggen. Als u een wijziging wilt aanbrengen in de kernbestanden van WordPress, kunt u dit voorstellen door een ticket te maken waarin de voorgestelde wijziging wordt beschreven en een patch te bevestigen, of door een patch aan een bestaand ticket te koppelen.
Een patch- of diff-bestand is een bestand met details over de wijzigingen die u in de bron hebt aangebracht die een versiebeheersysteem zoals SVN of GIT kan gebruiken om uw wijzigingen toe te passen. Het maken van een patch is eenvoudig via de opdrachtregel of via een GUI-tool zoals SourceTree.
In dit artikel zal ik gedetailleerd beschrijven hoe je de uitstekende GIT GUI-app SourceTree kunt gebruiken om de nieuwste versie van WordPress af te werken en je patchbestand te maken. U kunt de GUI-tool van uw keuze of de opdrachtregel gebruiken als u dat wilt.
Wanneer u uw patch naar WordPress core verzendt, moet deze worden gekoppeld aan een ticket in de probleemtracker van WordPress, die trac wordt genoemd. Daarom is de eerste stap bij het indienen van een patch het vinden of maken van een ticket.
Hoewel het mogelijk is dat een nieuw ticket met een nieuwe functie kan worden geaccepteerd, is dit niet erg waarschijnlijk. WordPress heeft letterlijk miljoenen gebruikers en het is alleen maar logisch dat de hoofdontwikkelaars heel voorzichtig zijn met het introduceren van nieuwe functies. Vrijwel alle nieuwe functies worden nu eerst afzonderlijk als plug-ins ontwikkeld en pas na uitgebreide tests en ontwikkeling worden ze samengevoegd tot de kern.
Je beste gok voor het accepteren van een patch is om een patch te maken voor een bestaand ticket. Onlangs is core trac opnieuw ontworpen om het gemakkelijker te maken om tickets te vinden met eenvoudige oplossingen en die die het waarschijnlijkst worden opgenomen in de volgende puntrelease en de volgende versie van WordPress..
Als u een nieuw ticket wilt maken in core trac, wat een goede zaak is als u een nieuwe bug hebt gevonden, kunt u dat hier doen. Zorg ervoor dat u trac hebt opgezocht voor rapporten van hetzelfde probleem voordat u een nieuw ticket maakt en dat u hebt geverifieerd dat de bug bestaat met de meest recente versie van WordPress.
Daarmee bedoel ik niet de meest recente release, maar de master branch in GIT-terminologie of trunk in SVN-terminologie. Ik zal in deze tutorial in detail beschrijven hoe je de nieuwste versie kunt downloaden.
U moet minimaal het samenvattingsveld invullen. Dit is de titel van het ticket en het beschrijvingsveld, dat de inhoud van het ticket is. In de beschrijving van het ticket, wees zo beschrijvend mogelijk.
Tijdens de workshop WordCamp Orlando in Orlando, die ik bijwoonde, ontwikkelden WordPress-hoofdontwikkelaars Mark Jaquith en Andrew Nacin deze lijst van wat in goed bugrapport staat:
Houd er rekening mee dat niet al deze voor elke bug relevant zijn, maar dat er meer relevante informatie is die u kunt toevoegen.
Tenzij u zeker weet wat u erin moet instellen, moet u de onderstaande velden alleen laten en een hoofdbijdrager gebruiken om het ticket dienovereenkomstig te categoriseren. Ik zou aanraden dat u de tag "Has Patch" of "Needs Patch" gebruikt, gebaseerd op het feit of u al dan niet een patch aanbrengt om de bug te repareren of niet.
Voordat u een patch voor een ticket maakt, is het belangrijk dat u de absolute nieuwste versie van WordPress hebt, aangezien er elke dag veel wijzigingen in worden aangebracht. Het is onmogelijk om te weten of uw fix werkt of dat uw bug nog steeds bestaat, tenzij u de meest actuele code gebruikt. Uw patch wordt waarschijnlijk niet geaccepteerd als code wordt gewijzigd die al is gewijzigd.
WordPress wordt beheerd in SVN, maar die code wordt op twee plaatsen gespiegeld als een GIT-repository:
Accentsconagua
git: //core.git.wordpress.org/De GitHub-repository is het gemakkelijkst te gebruiken. Houd er rekening mee dat, hoewel dit de officiële GitHub-repo is, deze nog steeds niet wordt gebruikt voor het bijhouden van problemen en u geen pull-aanvragen moet indienen.
Er zijn veel manieren om de nieuwste versie van WordPress te krijgen via SVN of Git. Persoonlijk vind ik het het gemakkelijkst te doen om de geweldige GIT GUI-tool SourceTree te gebruiken om de GitHub-spiegel te klonen. Dit is net zo eenvoudig als het selecteren van "Nieuw / klonen" uit het bestandsmenu, het invoeren van het adres voor de Git-repo in het veld "Bronpad / URL" en vervolgens een lokaal pad voor klonen opgeven, dat zich in uw XAMMP of Vagrant bevindt testomgeving.
Over Vagrant gesproken, de populaire WordPress Vagrant-configuratie VVV heeft een vooraf geconfigureerde testomgeving voor de kern van WordPress, inclusief de nieuwste code en de eenheidscontroles.
Nadat u de wijzigingen in WordPress hebt aangebracht die nodig zijn om het probleem op te lossen, probeert u de fix die u moet maken om een patchbestand te uploaden naar het ticket, te repareren en te testen. SourceTree bevat een manier om een patchbestand te maken of u kunt de opdrachtregel gebruiken.
In SourceTree kunt u een patchbestand maken door naar uw werkkopie te gaan en met de rechtermuisknop te klikken op de bestanden die zijn gewijzigd. Selecteer in het rechtermuisknopmenu "Create Patch".
Of ga in uw terminal naar de hoofdmap voor uw WordPress-repo en gebruik deze opdracht om de diff te maken:
git diff -non-prefix ~ / name.path
Ongeacht de manier waarop u uw patchbestand maakt, moet u het een naam geven na het ticketnummer waarvoor het is bedoeld. Als het de tweede patch is die is geüpload naar het ticket, voegt u .2 toe aan het einde van het nummer of .3 als dit de derde is, enzovoort. De vijfde patch voor ticket # 12358 zou bijvoorbeeld # 12358.5 heten
Nu uw patch gereed is voor gebruik, moet u deze uploaden naar het ticket in core trac. Op elk bestaand ticket is onder de beschrijving een knop 'Bestand bijvoegen' die u kunt gebruiken om uw patch te uploaden. Op het volgende scherm moet je een beschrijving toevoegen van wat de patch doet.
WordPress is een enorm project, dus het is onredelijk om onmiddellijk een reactie op je patch te verwachten. Begrijp ook dat de normen voor een patch die wordt ingezet voor WordPress erg hoog moeten zijn om alle gebruikers optimaal te kunnen bedienen.
Nadat u uw pleister hebt ingediend, wees geduldig en begrijp de feedback die u ontvangt. De hoofdontwikkelaars zijn erg aanspreekbaar, als je vragen hebt over je patch of waarom deze niet is verbeterd, kun je een van hen vragen in het # wordpress-dev IRC-kanaal.
In afwachting van een reactie en het aanbrengen van wijzigingen kan frustrerend zijn, het is de moeite waard wanneer uw patch is toegewezen aan WordPress en de changeset-beschrijving u erkent.
