Există mai multe modalități de a aplica un patch unic la un proiect PHP bazat pe Composer. Modul clasic este de a folosi cweagans/compozitor-petice, care este modul în care ați învățat.
Acest articol explică în detaliu cum să folosiți Composer Patch-uri pentru a corela core Drupal.
Este posibil să puteți utiliza această metodă pentru a aplica acest plasture, care este abordarea recomandată de @catch in acest comentariu, prin includerea acestuia în dvs compozitor.json:
„extra”: {
„activare-patching”: adevărat,
„patch-uri”: {
„drupal/core”: {
„Permiteți configurarea identificatorilor de sortare expuși pentru Vizualizări”: „https://git.drupalcode.org/project/drupal/-/merge_requests/54.diff”
}
După cum menționează @catch:
@Giuseppe87 poți folosi https://git.drupalcode.org/project/drupal/-/merge_requests/54.diff - deși pentru a obține un patch stabil de aplicat, cel mai bine este să îl descărcați într-un director /patches din baza de cod și apoi să adăugați calea locală a corecțiilor la compozitor.
Pentru a urma aceste instrucțiuni, deschideți un terminal și CD în directorul rădăcină al proiectului Drupal 9.2, apoi executați următoarele comenzi:
$ patch-uri mkdir
$ patch-uri cd
$ wget https://git.drupalcode.org/project/drupal/-/merge_requests/54.diff
$ mv 54.diff configure-views-exposed-sort-identifiers.patch
Pentru a utiliza fișierul de corecție local în proiectul dvs., mai degrabă decât patch-ul găzduit de la distanță pe Drupal.org, dvs. compozitor.json ar arata asa:
„extra”: {
„activare-patching”: adevărat,
„patch-uri”: {
„drupal/core”: {
„Permiteți configurarea identificatorilor de sortare expuși a vizualizărilor”: „patches/configure-views-exposed-sort-identifiers.patch”
}
Utilizarea unui fișier local este considerată cea mai bună practică aici, deoarece are unele avantaje față de utilizarea unui fișier la distanță. Este atât mai sigur, cât și mai eficient.
Există o altă metodă, relativ nouă, de a aplica patch-uri prin deschiderea unui Emite Furk iar răspunsul meu inițial a recomandat acea metodă, dar nu este necesar aici.
EDITAȚI | ×: După ce ați citit comentariile de mai jos, se pare că problema dvs. este aceea !54 nu a fost niciodată aplicată la ramura 9.2 înainte de rebazare.
Revenind la MR pe GitHub, puteți anula ultimele două comiteri alegând „Versiunea 9” a MR:
Dar chiar și atunci, ținta este setată la 9.3 și nu este clar cum să o schimbi folosind interfața de utilizare bazată pe web.
Va trebui să urmați Instrucțiuni Git pentru a clona nucleul Drupal într-un mediu de dezvoltare locală:
$ git clone https://git.drupalcode.org/project/drupal.git
$ cd drupal
Apoi, reveniți la Coada de probleme și uitați-vă la instrucțiunile pentru a verifica ramura pentru o furculiță de probleme:
$ git remote add drupal-2897638 [email protected]:issue/drupal-2897638.git
$ git fetch drupal-2897638
Consultați și ramura 9.2.x:
$ git checkout -b '9.2.x' --track drupal-2897638/'9.2.x'
Acum, doriți să generați o diferență între starea proiectului la commit eaa43b0c si 9.2.x ramura:
$ git checkout eaa43b0c
$ git diff drupal-2897638/9.2.x > configure-views-exposed-sort-identifiers.patch
Aceasta va genera un patch între commit-ul pe care l-ați identificat și ramura 9.2.x.
Cu toate acestea, s-ar putea să nu fie ceea ce îți dorești. Patch-ul generat de această metodă are mai mult de 230.000 de linii de cod:
$ wc -l configure-views-exposed-sort-identifiers.patch
230134 configure-views-exposed-sort-identifiers.patch
Este posibil ca git commit-ul pe care l-ați identificat să se bazeze întotdeauna pe ramura 9.3.x. Se pare că mai este de făcut pentru a recrea munca esențială pentru acest patch și a o aplica curat pe ramura 9.x.
Este greu de spus cu siguranță, pentru că eaa43b0c este deja cu 93.000 de linii de cod înainte de ramura 9.3.x:
$ git dif 9.3.x |wc -l
93794
Este ușor să iei de la sine înțeles câtă muncă depun oamenii pentru acest software open source pe care ne bazăm cu toții. Dacă aveți nevoie de funcționalitatea furnizată de acest patch, cel mai simplu mod de a o obține va fi să faceți upgrade proiectului Drupal la ramura 9.3.x puțin mai devreme decât ați fi preferat să faceți acest lucru. Apoi patch-ul se va aplica curat și nu va trebui să înțelegeți acele 93.000 de linii de cod.
O ultimă notă - diferența generată de Merge Request 54 este mai mică de 1000 de linii de cod:
$ wc -l 54.dif
936 54.dif
S-ar putea să puteți verifica ramura 9.x și să aplicați fiecare dintre aceste 936 modificări manual pentru a genera fișierul de corecție în local. Ar fi încă multă muncă, dar poate mai puțină decât unele dintre celelalte opțiuni.
Aceasta nu este o situație comună; majoritatea Composer Patch-uri sunt mai mici decât acest monstru după ordine de mărime.
Noroc!
