 Bona tarda, tots i totes. Gràcies per ser aquí, benvinguts a la darrera ponència d'aquesta World Camp Barcelona 2023, espero que ho estigueu gaudint. I ara tindrem amb nosaltres el Jordi Ruiz. Jordi Ruiz és un tortozi de 43 anys. El Jordi va estar donant molts anys tècnic de suport i va decidir canviar el món de la programació, va entrar a treballar en una empresa de desenvolupament web i es va enamorar de WordPress. I avui ve a explicar-nos com crear el nostre propi plug-in. Doncs endavant, Jordi. Gaudit. Com veu ha dit. Soc Jordi, vinc d'Emposta. Això ha significat emplacor del tèdebre. Parlaré amb l'accent de brengue. No intentaré canviar l'accent perquè si no m'hi costarà una miqueta més. És la meva primera World Camp com a assistent i com a ponent. No havia fet mai de ponen a cap lloc. Vaig tirar el riu i vaig dir, em presento. No ho sé, em van triar. Vaig dir que presentar-me bé, no ho sé. És això. Jo intentaré explicar-vos. Ja veu que toca una mica de tot. Especialment estic ara últimament en WordPress i en Shopify. Però m'agrada més el WordPress. Shopify és una cosa obscura que no volem entrar. I aquí primer que res. Això era una xerrada introductoria totalment a la creació de plug-ins. Si ja s'hau fet plug-ins ho sento. No ho sé si ja en feu, però us explicaré com començar a fer plug-ins. Primer, què és un plug-in? Un plug-in és un tros de còdia que s'executa a WordPress. És un tros de còdia que s'executa. No té cap més... Sí que té més funcionalitat, però és això. Què ha aconseguit en un plug-in? L'abstracció de còdia que mos permet anar a trobar i executar-me el plug-in i si hi ha algun problema, simplement entrar per FTP, borrem la carpeta, el plug-in desapareix. Si mos genera algun problema, el còdia està totalment aïllat dins el plug-in i el podem llevar sense cap problema. Millorem la seguretat per això, perquè fem una abstracció totalment de les dades que s'introduixen, que es gestiona el plug-in, té independència total en les actualitzacions. Nosaltres podem actualitzar tema i WordPress sense que el plug-in es vegi afectat o podem actualitzar el plug-in sense que WordPress i temes vegi afectats. No sé que el plug-in tingui alguna funcionalitat, alguna funció, algun tros de còdia que ja ha abandonat WordPress i això provoca que deixa de funcionar, com molt desvegades passa, que plug-ins que no s'actualitzen, actualitzem el core i deixa funcionar tot. Llavors, la feina de formiguetes de veure quin és el que està provocant això. I sobretot, sobretot, sobretot, la funcionalitat principal d'un plug-in és afegir funcionalitats al WordPress. Però això l'hi instal·lem, va? I ara em podríeu dir, l'aterna pregunta, què és millor, ficar la funcionalitat del tema o ficar-la en plug-in per a gustos colores? Cada ua que faci el que vulgui. Jo es recomano plug-in un tema, un client a la llarga, te'l demanarà canviar. Si canvis el tema, has de parar a compte tot el que hagués ficat al funció o hagués ficat a la modificació del tema, tot el que hagués ficat, l'hauries de passar al nou tema. Si tu tens un plug-in, canvis el tema i cap problema a la funcionalitat del plug-in, seguis estant allà. Sense cap més complicació. Comencem. El còdex. Jo fa poc que em dedico professionalment a la programació, però fa molts anys ja vaig començar a introduir-me i, si una mica de manera autodidacta, i sempre que feia alguna cosa, jo anava al còdex, al còdex de Wordpress, i ara mateix fa un temps vaig entrar i dius, ostres, se n'estan anant, m'està desapareixent el còdex, i ara què faré? Val, cap problema. Tenim el developer resource. Aquí és la bíblia del Wordpress. És el que era l'anticòdex. És el developer resource. Aquí dalt us he ficat uns QRs, depèn de quins llocs, perquè si voleu anar a aquestes URLs, així puguessiu anar mirant. Comencem. Structura mínima d'un plug-in. El mínim que ha de tenir un plug-in, perquè Wordpress el reconegui i el pugui instal·lar. Un comentari. Un comentari amb el nom de plug-in. Seria el mínim que hauria de tenir. Tu mires això i dius... Què és això? Li podem ficar més opcions. Si aneu allà al QR, ja us sortiran tot el que pot ficar-li en la capçalera, com el nom del plug-in, l'URL, qui l'ha programat, la descripció... Com més fiquem, el moment que aparegui a la pàgina dels plug-ins de Wordpress, més informació donarem a l'usuari. Els hooks. Segur que són els hooks. Punts claus repartits per tot el Wordpress. Tant el core, com si està ben fet del tema que tenim, emportarà el tema, com altres plug-ins que tenim instal·lats, també emportaran. No inventem la roda. No volguéssim fer un plug-in, no volguéssim inventar la roda. El Wordpress, en aquest sentit, està molt ben estructurat i té tots els hooks. Els hooks estan repartits en dos. Actions i filtres. Les accions mos permiten insertar un codi per afegir una funcionalitat que no existeix. Els filtres el que fan és que modifiquen una funcionalitat que hi ha, com per exemple, extraordinàries, i tu la pots preprocesar i després mostra la informació processada mitjançant els filtres. Els plug-ins et recomanen que un plug-in, com a mínim, es produeix un hug que serveix per afegir... És el que s'executa. Quan nosaltres diem un plug-in activar, és el que s'executa. Si volem crear una taula de base d'edats, la crearem al hug de registre, o volem afegir un valor. El hug de... desactivació. El hug de desactivació. Si vol que és el que diu el desactivar, exhecut una funcionalitat. I el de desinstal·lar, quan ja seria que desinstal·len el plug-in, que la taula que han creat és l'ideal, la taula que han creat, els valors que li han ficat, desapareguem totalment i no deixi arrastre el nostre plug-in. Si voleu, com a curiositat, a l'URL està, estan tots o gairebé tots, no sé si tots, perquè n'hi ha moltíssims, tots els hugs que hi han disponibles a WordPress. Jo de quan en quan, dic, ostres, dic que no, perquè apareixen de nous quan canvien de versió. Dic, tinc 5 minuts, que és difícil tenir 5 minuts lliures. Dic, tinc 5 minuts, vaig a mirar. Ostres, hi ha vegades, veig hugs i dius, això em servís per a fer, això que este client me va demanar i vaig dir que he fet 30.000 voltes, ostres, si hagués llegit abans d'aquest hug, ho hauria pogut fer. Bueno, anem per feina. El que farem ara mateix, us encindaré com fer un plugin per afigir el codi d'analítics. Tant senzill com això. Aquí està tot el plugin. Això és un plugin que afigis el codi d'analítics. La capçalera, i veig això. Què hi ha aquí? Tenim la funció ATACTION. L'ATACTION ens demana sobre executar una acció hasta l'ATACTION i l'ATFILTER, i l'ATACTION ens demana per fer més acció. El nom, la funció callback, que és la funció que s'executarà al cridar l'ATACTION, i després la prioritat i els arguments que li podem passar a la funció. La prioritat és perquè en una mateixa acció, en un mateix hug, es poden executar moltíssimes funcions. Molts plugins pot cridar molta gent a la mateixa acció. En l'ordre de prioritat que s'executarà. Com més baix sigui, més pronta. En l'anàl·litics sempre et diuen que el codi estigui justament abans del body, o al final del head, posaríem una prioritat molt alta, un número molt alt, perquè es fiquésseg més cap a baix. Només és això. I aquí és això, i el que us dia, el vpg, que és un de los hug de WordPress, que inserta algo dins a la capçalera del WordPress, insertaríem el típic codi de Google Analytics, i això ja tenim el plugin que... Perdona. El plugin que crea el codi de... que inserta el codi de Google Analytics. Què passa? Ostres, tenim jacó de jat, l'hi de. El plugin no podem reutilitzar una triclient. L'hauríem de fer una triclient, per anar a estar triclient. Seria ràpid, sí. Però tampoc m'os interessa. Per això, podem decidir millorar-lo. Com ho millorem? Aficient una pàgina, on ens demanarà l'hi de d'analítics per a poder fer instal·lar aquest plugin a molts dels llocs, i que sigui totalment configurable per l'usuari. Què farem primer? El mateix, a l'acció del modificació del menú, tenim la seva funció de Colbert, que ens afegis una pagina d'opcions. Ja ho veiem. Jo sempre us ficaré la captura d'aquestes opcions. Aquí ho explica clar. He afegit una pagina d'opcions, on li hem de passar el títol de la pagina, què tindràs la pagina d'opcions, el nom del menú, els privilegis que ha de tindre l'usuari per accedir a aquesta menú, l'art del menú, la funció de Colbert, i la posició que podríem veure aquesta menú dins les opcions. Fixem-nos-hi bé. M'ho està de dient, que la funció igualment ha de validar que l'usuari tingui permisos. Com us diu això, el que fem és que a la funció de Colbert el primer que fem és dir-li, a preguntar-li, l'usuari pot gestionar les opcions? Sí? No. Si no les pot gestionar, ja fiquem la negació davant. Si no pot gestionar, matem el procés. El típic d'Ai de P.A.P., però aprofitant una de les funcions de Warpers, que deixa molt guap. És un DAI més guapet. Què fem aquí? Afigim un formulari. El formulari és una funció a post perquè m'estic molt bé, potser. És que ara m'ho vaig pensant. Una funció a post que sempre, sempre, sempre, si volem guardar l'informació dels formularis de Warpers, ha de cridar a options.p.a.p. L'action sempre ha de ser options.p.a.p. Aquí ho fica. I el que farem aquí, si us fixeu, no he ficat ni un camp, l'input del SatMit, però no he ficat cap input, ni cap label, i no he ficat. Això és perquè utilitzarem les funcions atives del Warpers. M'ho ajudaran moltíssims. La primera és el settings fill. L'únic que fa això és que ens afigigi els nonces. Els nonces són els verificadors que ens ajuden a verificar que l'escrit dels formularis s'han realitzat des de la pàgina i no d'una manera externa. Si el Warpers té una funció per fer aquella acció, ja ho sé que serà una faena molt gran de recerca d'aquest tipus d'informació, però utilitzem-ho. Aquí el settings fill és això. Li diem a quina opció del grup li han d'eficar. I l'altra que tenim és el two-section settings, que l'únic que fa és que ens pintarà totes les opcions, tots els camps que afigiéssim a este formulari. Això és molt bonic, però ara ve la part fosca implementar-ho. Si ens fixem, aquí tornem a tenir una refug. L'admin i nit. L'admin i nit és dels primers que s'executa al moment d'obrir el backend del Warpers, el gestor del Warpers. I aquí és on definirem tots els camps que tindrà el nostre formulari. Un. Només necessitem un. Ara que amb això els he fet d'aquest exemple, perquè en un sortíem i no calia extendre-ho més. Però si us fixeu la primera funció de colba, que té aquesta, té tres opcions. El register setting at settings section i at settings fill. Expliquem una un que fa cada un. Register setting. Aquí és on li direm a Warpers que permeti que el nostre formulari guarda els valors que li volin introduir. Si no fem el register setting, el Warpers no ens deixarà. No ens deixarà passar, perquè aquesta opció no està permesa dins de Warpers. La at settings section afegis, ja ho diu el nom, afegis una nova secció a la página d'opcions. És on definim la nostra secció. I al final tenim el at settings fill, que seria afegir camps en aquesta secció. Tenim tres funcionetes que mos fan aquestes opcions. Que si mirem la primera la primera l'únic que fem és a la secció li afegim un simple text de què volem fer. Com més fàcil ho fem per l'usuari sempre millor. Ja sabeu que l'usuari a vegades és una mica dient un fill complicat. La segona funció el que farà és que ens mostra l'input que volem que a un l'usuari ha de ficar el seu ID. Però, si mos fixem abans de mostrar l'input, el que fem és que agafem el valor que tenim a la base de dades. Pera que si ja l'hem utilitzat una vegada, si ja l'hem introduït aquest valor, ja l'hem guardat alguna vegada ja l'usuari ha tingut allà que té aquell ID ficat. Que us fa amb la funció de GetOption on li diem la opció i true or false dependent de si volem que ens mostra la rai d'opcions o un específic. En aquest cas jo no vaig ficar res per defectes tan fols i per això crido a l'Options i a l'ID, que és el nom del camp. I al final tenim la funció de validació del codi. Aquí no sé si algú de Batros ha generat alguna vegada un plugin. Ha creat alguna vegada un plugin? Sí? No veu cap problema aquí? No veu cap... Ah, ostres! Val. Us explico. En cap moment, ha invalidat la informació que l'usuari ha entrat. Per favor, no ho fèseu mai. Això és un cau de haquejos, però que en 5 minuts el Wordpress ja no funciona. Val? Us injectaran codi a la base de dades. Tot s'hauria de sanititzar. Aquí, igual que aquí, ha fet un simple trim. Això s'hauria de sanititzar. Per si un l'usuari té ganes de tocar la moral o ens intenta enjaquejar que el possible javascript que ens incertessen aquí a la base de dades o el que sigui, no es pugui executar. Val? Això s'hauria de sanititzar Val? I ara, en tot això fet, l'únic que ve el que tenim és... tenim el mateix codi on, primer, agafem l'opció, igual que abans, agafem el valor de l'opció i el pintem al seu lloc. Amb això tindríem un plugin a un l'usuari. Podria ficar el seu ID i el podria deixar funcionant. Aquí, tornem a estar al mateix. Hi ha un fallo molt gran. Un error molt gran. No ha tingut en compte d'escapar el valor de l'ECO. Val? Això són problemes de seguretat. Este ECO s'hauria d'escapar. En la funció de SKPML s'hauria d'escapar per evitar possibles malusos de este formulari. Val? Això tenim-ho sempre en compte. Los inputs s'han de sanitizar i s'han d'escapar. La informació sempre s'ha d'escapar per evitar hackeijos. Això seria el resultat final. Amb totes les funcions que han fet, tenim això. El títol de la pàgina, el text que em fica de configuració i l'input i el botó de guardar. Si us fixeu, en cap moment li he dit que si es guarda a l'utilitzar les funcions atives de WordPress el sistema el fa automàticament. Val? Per això he dit, no intenteu inventar la roda. WordPress mosifica més fàcil. Com han dit, WordPress és un framework que mos deixa tot ben preparat. No sé si ho ha estat. El de la Sulema o de l'Adrià. Però ells m'han xafat coses que tenia jo preparades. El que passa és que al final el codi queda així. Un archiu llargíssim. Justament és de no és llarg, però un archiu llargíssim que això és per a mantindre-ho i en ampliar les seves funcionalitats. És mortal. Després d'aquí uns dies jo entraré aquí. Ostres, em tastava l'input, em tastava malament. No sé si la coneixeu. Què és això? Això és simplement una plantilla de generació de plugins. Mira, ho llegiré perquè no m'equivoque. És la plantilla de generació de plugins de manera standarditzada i, sobretot, orientada a objectes. Val? Us ho aconsello. Utilizeu-la. Si heu de fer un plugin, us llevarà moltes hores de faena. ¿Vale? Aquesta plantilla ja ve estructurada igual que els plugins que en el repositari del WordPress. És a dir, si volguéssiu publicar, en això ja estaria mantenint la estructura de publicació. Com veieu, entreu en aquesta pàgina i l'únic que heu de fer és ficar el nom del plugin, l'eslag que voleu que tingui, i és la informació com la URL, el nom del desenvolupador, és molt fàcil. Feu això i ell ja us generarà tota la estructura. I quan la descarregarà ara us ensenyaré com és. Val? És això. Tinc un punt de l'ésser. Ah, sí. Ho veieu bé? Més o menys. Val. Sí? Val, va. Perfecte. Com veieu, la estructura que és, primer tenim un arxiu principal on els ensenyaré, i després tenim 3 carpetes. L'admin inclúdes... Bueno, 4. Lànguats i públic. La estructura del plugin està preparada per la internacionalització del plugin, si vulguéssim. Podríem afigir-li les traduccions que vulguéssim. És un punt important d'utilitzar això. Què són aquestes carpetes? Primer, si mirem l'índex perfecte, si hi ha el més lògic, no hi ha res. Perfecte, és perquè si algú vol accedir troba la carpeta vol accedir, no pot fer res. I aquí tenim el plugin. Primer, que hem creat totes la capçalera que tenim aquí. Perfecte. I després aquí ja comença a crear una sèrie d'includes per activar el plugin, desactivar... Ja tenim la classe d'activació on podríem posar tota la seva funcionalitat, la classe de desactivació on podríem posar la funcionalitat de desactivació, el tema de la internacionalització, no? Aquí serien les funcions d'ajuda a tot el que faria el plugin. I aquí és on hauríem de començar a treballar naltres. Sobretot aquí no caldria modificar-ho, però com veiem, tenim dos grans opcions. El define admin hooks, és a dir, tota la funcionalitat que vulguéssim afegir el backend del WordPress la aniríem afegint aquí i tota la funcionalitat que vulguéssim que tinguéssar al frontend l'afegim aquí. Ja estem separant. I cada una aniré on sigui. Per exemple, veiem que això anirà a plugin admin en aquesta classe plugin admin i les funcions del frontend aniran a l'afegim públic. Sí, ja comencem a separar aquesta informació. Si falla algo del frontend, sabem que tenen una carpeta públic i si falla algo del backend, sabem que tenen una carpeta admin. Si anem a admin aquí és entestant les funcions que havia posat jo abans són les mateixes funcions però si mos fixem és tot més curt. No hi ha tant de codi. Per què? Perquè amb els parcials és on jo l'incerto a l'acte ML. No m'esclem dins d'una classe a l'acte ML si podem fer l'includ. Són més o menys les bones pràctiques que hauríem de seguir. Tindrem l'opció de fer els includes de les plantilles com si diguéssim i no més clar-ho. I al públic és en tenim el mateix cas. L'únic que fa és que ens agafa l'opció i ens inclou el que ha de tindre. El simple ens ha fescrit. Això? Ja tindríem el mateix plugin d'una manera estructurada i fàcilment ampliable. Fàcilment puguem agafar i poden afici funcionalitats de les classes. Podrien crear més classes aquí i crear les seues carpetes. Això pot... Les possibilitats de creixement que tindria el plugin aquí serien per a nivell desenvolupador molt millors. Si us interessa utilitzeu, si voleu fer plugins perquè us millora la vida moltíssim. I aquí i us dono pas si teniu alguna pregunta. Molt bé, Jordi. Gràcies. Passem al Torre de Preguntes. Moltes gràcies per la ponència. Jo he estat tentat alguna vegada de fer algun plugin però tinc aquesta, no vull dir por, sinó respecte, perquè, per exemple, avui, aquest matí, que ha vingut el ponent al Xavier Casares d'un tema vulnerable, és a dir, que sigui vulnerable. No sé si hi ha alguna manera de, lògicament, si provés un plugin aprovaria una web de proves, però no sé si hi ha alguna manera de tastar, també, si té alguna vulnerabilitat, que no us surt la paraula. És a dir, si és vulnerable el plugin que jo heu fet o no... Això ho desconec. Però si tens en compte el que he dit sempre de sanititzar els inputs. Tot el que s'ha de posar en compte és el WordPress. Sanititzar-ho. Això ja elimina moltes opcions de jaquets. I després, els ecos que fas, el còdic que fiques, escapar-lo, les funcions que hi ha, scectemeles, JavaScript, el que sigui, hi ha unes quantes funcions d'escapar. En això ja millorarà moltíssim la seguretat del plugin. I després, amb quina mesura pots mantenir en el temps, és a dir, tu acabes de fer un plugin, aquell plugin mantindrà les regles en funció de les actualitzacions del WordPress. És a dir, el WordPress anirà actualitzant, i clar, al millor tu, aquell plugin pot ser que et quedi obsolet. Exactament. La pregunta... Això tens temps? Ja. És a dir, és anar mirant el WordPress i ja t'avisa els dèpercats, els abandonaments i els abandonaments durs. Primer, t'avisa que es va abandonant i hi ha una certa versió que abandona completament aquelles funcions. S'hauria d'anar revisant... Abans m'ho preguntava, però tu no has publicat cap plugin? No, no he publicat cap plugin, perquè no tinc temps de poder fer este manteniment. Jo faig plugins a mida per als clients de l'empresa que treballo, publicant plugins. Sí, és que a cada versió l'haurien de provar, l'haurien de mirar... Entre això, i les filles... És que... Sembla impossible. Moltes gràcies. Moltes gràcies. Hola, moltes gràcies per la xerrada. I la meva pregunta està més relacionada... Bueno, una mica relacionada amb el que ha dit el company. Vull dir a saber... Potser pot respondre a tu una persona. Com de difícil o fàcil és tastar un plugin i, bueno, si es pot resumir de manera fàcil, confereu. Testar quin sentit? La funcionalitat. Per exemple. Perquè, clar, entenc que si fa servir els hooks o el framework de WordPress, entenc que s'ha d'allar tot això o, bueno, no sé, si algú sap com es fa o si algú ho ha aprovat... Home, el que és principal és com l'utilitza l'usuari. Sí, que heu ensenyat aquesta plantilla. Aquesta plantilla, el moment de fer testos unitaris, és complicat. Sí, que hi ha... Hi ha una altra plantilla que per aquí tinc, que seria... aquesta, que ja ens inclou una sèrie... Ja podem afegir llibreries per en Composer. Ja podem fer testos unitaris. Seria millor utilitzar això, però és bastant més complicat. Si t'atrevises, només és aquí el WordPress plugin, boilerplate powered. WordPress... Mira, us explico. Està el GitHub? El WordPress plugin boilerplate powered. Seria com una evolució de l'UVPPB.mi, però... en esteroides. Ha basat en symphony? No. És una plantilla per afegir el WordPress que hi ha disposat de Composer. Per a gestionar tots els paquets que li afegim i ho pots fer via Composer per fer el manteniment, les actualitzacions del plugin. Pel symphony, no. Sí que es podria fer en un symphony, algun plugin, però... No ho deia per l'última dels testos unitaris. Sí, aquest sí que porta directament testos integrats per a què els pogués fer. Vale. ¿Pues contar algo sobre cómo se hace el acceso a base de datos? No te hace falta. Si utilices las funciones de WordPress... Si no, digo las funciones de WordPress para acceder a base de datos. ¿Funciones o utiliza un sistema de ORM como magento por ahí? Pues no sé. No, ahora... No, tienen las funciones. Sí que tiene algunas funciones de insert, de update, que lo puedes hacer manualmente, pero no te lo aconsejo. Las funciones, tú en el register field, tú ya le dices a WordPress que este campo, una vez se haga el submit, se guarda. No hace falta que tú te preocupes de cómo hacer el acceso a base de datos o de recuperar esta información. El register field le dices que se puede guardar y en el getOption recuperas este valor. És que no l'havia entendido, disculpa. No te preocupes. Quan creus que hem de fer un plugin i quan creus que podem posar un petit codi, per exemple, rotllo-mòcodes nipets, fins a quin punt hem de desenvolupar... Fer un plugin per posar el codi d'analítics és una borrada. Clar, clar, clar. I, a part, no faci-ho mai d'un plugin així, eh? Totalment incompatible en la GTPR. Aquí, en cap moment, amb validad que l'usuaria hagi acceptat les cookies, ni res, sobretot. Teniu en compte, això es publica, no utilitzeu un plugin així. Clar, crear un plugin per... 30 línies de codi, no té sentit, potser seria millor ficar-ho als funcions, en aquest cas. Però... Tampoc. Seria cap gran problema ficar, hi ha plugins que, en la funcionalitat en minuda, el rendiment del WordPress ni se n'enterarà. Clar, este plugin, tu dius, hosti, esta funcionalitat té un plugin. Sí, perquè potser tindràs un altre client que també necessitarà esta funcionalitat. No, no. Pujaràs el plugin i l'activaràs. Ja està. Disculpa, Jordi. Primer, gràcies per la ponenciada, molt interessant. Des de la meva desconeixança de no haver fet, que m'ha passat com a company, que algunes vegades vull arrancar, però per falta de temps sempre se me queden un projecte. Has dit que a l'utilitzar els hooks ell ja té crè i ja té guarde a la base dades. No. En aquest camp. Amb el register settings. La funció registers settings. Perdona, perdona. Ja s'ha guardat a la base dades. El camp aquest que havies fet tu, per l'idea del Google Analytics. I on ho guarda això? Creu una taula nova o no ho guarda això? A l'Options creu un camp nou i ho va guardar allà, tota la informació. Vale, perfecte, gràcies. Una pregunta més. Un fort aplaudiment pel Jordi, sisplau. Gràcies.