Förbättrade skriptmeddelanden i OpenCart 2.2.x.x

Idag ska vi diskutera en av de coolaste funktionerna i OpenCart-script-meddelanden. Även om de har varit tillgängliga sedan versionen av OpenCart 2.x-versionen har de blivit förbättrade i den senaste versionen av OpenCart 2.2.x.x. Under hela handledningen diskuterar vi konceptet och demonstrerar det genom att skapa en arbetsmodul.

Introduktion

Som utvecklare behöver du ofta ändra flödet av kärnans rambeteende, oavsett om det är att lägga till en ny funktion i ramen eller för att förbättra det befintliga arbetsflödet. I båda fallen måste du ha kontroll över arbetsflödet så att du kan ansluta till funktionaliteten och uppnå önskat beteende.

Låt oss försöka förstå det med ett enkelt exempel. Om du kör en populär onlinebutik är chansen att de populäraste produkterna i din butik snart kommer att säljas ut. I det här fallet skulle det vara trevligt att få en anmälan om det och vidta lämpliga åtgärder i enlighet med detta.

Så vad du kan göra i det ovan nämnda exemplet är att leta efter den metod som kallas när ordern placeras. Därefter kan du koppla i orderflödet så att du kan styra när beställningen är placerad. Det gör att du kan exekvera ett slumpmässigt kodstycke i samband med den uppringda händelsen. Det är där händelseanmälningar kommer in i bilden, så att vi kan köra godtycklig kod och ändra det resulterande resultatet.

Vad är skriptmeddelanden?

Enligt den officiella OpenCart-dokumentationen:

I 2.2+ har vi lagt till ett nytt händelsessystem, det här är krokar som kan ringas före och efter händelser som ett kontrolsamtal, modellmetodsamtal eller mallar som laddas. De ger möjlighet att manipulera parametrarna för inmatningsmetoden och returnera utgången.

Det är väldigt kraftfullt, som du kan bokstavligen koppla till något metodsamtal och ändra utmatningen som returneras av den metoden. Men du bör vara försiktig under genomförandet av krokar, om du tar ansvaret för att ändra den resulterande utmatningen av samtalet. Det beror på att om ditt genomförande returnerar något värde, kommer det att stoppa alla andra händelseåtgärder som är inställda att kallas.

Vad tar det för att implementera skriptmeddelanden? Här är nödvändiga steg:

Registrera din händelse

När du registrerar din händelse med OpenCart, berättar du OpenCart som du vill övervaka xyz åtgärd, och om det händer exekvera du foo-åtgärden i barens kontrollfil. Medan du har det, har du två alternativ att välja mellan - före och efter.

Om du väljer alternativet före, kommer OpenCart att köra foo-åtgärden innan den åtgärd som övervakas, och när det gäller alternativet efter det kommer det att utföras foo efter åtgärden. När det gäller alternativet före är det viktigt att notera att om foo-metoden returnerar något, kommer OpenCart inte att exekvera den ursprungliga metodkoden som övervakas alls.

Senare i den här artikeln får vi se hur man registrerar en händelse under anpassad modulimplementering.

Genomföra målåtgärden

Därefter måste du implementera kontrollenheten och motsvarande åtgärdsmetod som har associerats med en händelse i det första steget. Det är den plats där din anpassade kod ska gå in. OpenCart skickar kontextspecifika argument till din foo-metod, så att du kan använda den om det behövs.

Så det är bara en glimt av vad skriptanmälan kan klara av.

Behöver vi fortfarande OCMOD?

Om du är bekant med antingen vQmod eller OCMOD är chansen att du rullar upp ärmarna mot händelseanmälningsfunktionen. När allt kommer omkring kan du uppnå allt genom de ovan nämnda godisarna som du skulle ha gjort med händelseanmälningar.

För dem som inte är bekanta med antingen vQmod eller OCMOD, listade nedan är trevliga inledande artiklar som förklarar det.

  • Det nya modifieringssystemet i OpenCart 2
  • Ändra kärnan i OpenCart Använda vQmod

Så, frågan är, om du skulle kunna använda antingen vQmod eller OCMOD för att ändra kärnfilerna, varför skulle du använda scriptanmälan? Det beror på det faktum att det kan finnas flera OCMOD-plugins som försöker ändra samma kod, vilket kan leda till konflikter. Vid händelser finns det ingen risk för konflikt eftersom varje händelse exekveras i en viss ordning.

Så slutsatsen är att om det är möjligt att använda händelser, gå för det. Å andra sidan, om du känner att det inte finns något evenemang tillgängligt för ditt användningsfall, är det helt bra att gå med OCMOD.

Skapa en back-end-modul

I det här avsnittet kommer vi att bygga en modul som visar hur man använder händelseanmälningar i OpenCart. Jag antar att du är medveten om grundläggande modulutvecklingsprocessen i OpenCart, eftersom vi kommer att glida igenom grunderna. Om du inte är medveten om det, här är en bra artikel som du kan gå igenom snabbt.

Låt oss förstå användningsfallet innan vi går vidare och implementerar det. Antag att du har en butik som hämtar kataloginformationen från tredjeparts API-back-end. Du har ställt in en cron som regelbundet hämtar informationen och lägger in den i OpenCart-databasen, så att den kan visas i fronten. Även om du har skapat en cron som uppdaterar informationen med jämna mellanrum, vill du vara säker på att informationen som visas i fronten måste vara i realtid.

I fronten kallar OpenCart getProduct funktionen när den visar produktdetaljsidan. Så det är den perfekta kandidaten för att du ska ansluta till och uppdatera databasen om API-informationen har ändrats.

Så låt oss börja skapa back-end-filer först.

Gå vidare och skapa admin / styrenheten / modul / demoevent.php fil med följande innehåll.

last> modellen ( 'förlängning / händelse'); $ this-> model_extension_event-> addEvent ('event_product_info', 'katalog / modell / katalog / produkt / getProduct / before', 'custom / product / info');  avinstallation av offentlig funktion () $ this-> load-> model ('extension / event'); $ This-> model_extension_event-> deleteEvent (event_product_info '); 

Som vi diskuterade tidigare är det första som du vill göra, att registrera händelsen. Det är den installationskrok som vi ska använda för att göra det, eftersom det kommer att utföras när modulen är installerad.

Vi har använt addEvent Metod för händelsemodellen under förlängning katalog, och den metoden har tre argument.

Det första argumentet, event_product_info, är namnet på händelsen. Du kan namnge det, men se till att det är unikt.

Det andra argumentet är mycket viktigt, och det pekar på den metod som du skulle vilja koppla in i. I vårt fall måste vi välja getProduct metod för Produkt Modell under Katalog katalogen. Så hierarkin är modell / katalog / produkt / getProduct. Förutom det bör det vara prefixat av antingen katalog eller administration, vilket står för ansökan. I vårt fall är det katalog som vi hakar i front-end-metoden. Slutligen kommer det att bli eftermonterat av antingen före eller efter, vilket berättar att OpenCart kan köra vår kod i enlighet med detta.

Det tredje argumentet pekar på verkan av din controller som kommer att utlösas när händelsen avfyras. Det är inställt på anpassade / produkt / info, så du måste skapa en Produkt styrenhet med info metod under beställnings- katalog, som vi gör på ett ögonblick.

Slutligen används avinstallationsmetoden för att ta bort händelsen under avinstallationen av modulen.

Låt oss sedan skapa en språkfil för vår anpassade modul på admin / språk / en-gb / modul / demoevent.php med följande innehåll.

Vi har slutat med back-end-filinställningen. Nu borde du kunna se vår modul listad under Extensions> Moduler i back-end av OpenCart. Fortsätt och installera det. Nu ska vi fortsätta och skapa filerna i fronten.

Skapa en modellfil Katalog / modell / anpassade / product.php med följande innehåll. Det är en typisk modellfil enligt OpenCart-strukturen.

db-> fråga ("SELECT date_modified FROM". DB_PREFIX. "produkt WHERE product_id = '". (int) $ product_id. "'"); returnera $ query-> row;  funktionsuppdateringProductInfo ($ product_id, $ data) include_once __DIR __. '... / ... / ... /admin/model/catalog/product.php'; $ modelCatalogProduct = new ModelCatalogProduct (); $ modelCatalogProduct-> editProduct ($ product_id, $ data); 

Det implementerar två viktiga metoder. De getProductLastModifiedInfo Metoden används för att hämta produktets senast ändrade datum och updateProductInfo Metoden används för att uppdatera produktinformationen i databasen. I ett ögonblick ser vi hur dessa metoder kommer att användas.

Slutligen, låt oss skapa en av de viktigaste filerna i den här artikeln, katalog / styrenheten / anpassade / product.php, med följande innehåll. Det är en kontrollerfil som implementerar info åtgärdsmetod som ska anropas när getProduct metod för Produktmodell kallas.

last> modell ( 'anpassade / produkten); $ product_modified_date = $ this-> model_custom_product-> getProductLastModifiedInfo ($ product_id); om $ product_modified_date ['date_modified']! = $ product_api_info ['date_modified']) // api info har ändrats så först låt oss uppdatera db // Obs! Du vill förmodligen formatera $ product_api_info enligt det format som krävs av editProduct method $ this-> model_custom_product-> updateProductInfo ($ product_id, $ product_api_info); // returnera senaste / realtid produktinformation returrätt ('product_id' => $ product_api_info ['product_id'], 'name' => $ product_api_info ['name'], 'description' => $ product_api_info ['description' ] 'meta_title' => $ product_api_info ['meta_title'], 'meta_description' => $ product_api_info ['meta_description'], 'meta_keyword' => $ product_api_info ['meta_keyword'], 'tag' => $ product_api_info [' tag '],' model '=> $ product_api_info [' model '],' sku '=> $ product_api_info [' sku '],' upc '=> $ product_api_info [' upc '],' ean '=> $ product_api_info ['ean'], 'jan' => $ product_api_info ['jan'], 'isbn' => $ product_api_info ['isbn'], 'mpn' => $ product_api_info ['mpn'], 'location' => $ product_api_info ['location'], 'quantity' => $ product_api_info ['kvantitet'], 'stock_status' => $ product_api_info ['stock_status'], 'image' => $ product_api_info ['image'], 'manufacturer_id' => $ product_api_info ['manufacturer_id'], 'manufacturer' => $ product_api_info ['tillverkare'], 'pris' => ($ product_api_info ['rabatt']? $ product_api_in fo ['rabatt']: $ product_api_info ['pris']), 'special' => $ product_api_info ['special'], 'belöning' => $ product_api_info ['belöning'], 'points' => $ product_api_info [ "poäng"], "tax_class_id '=> $ product_api_info [' tax_class_id '],' date_available '=> $ product_api_info [' date_available '],' weight '=> $ product_api_info [' vikt '],' weight_class_id '=> $ product_api_info ['weight_class_id'], 'length' => $ product_api_info ['längd'], 'bredd' => $ product_api_info ['width'], 'height' => $ product_api_info ['height'], 'length_class_id' > $ product_api_info ['length_class_id'], 'subtract' => $ product_api_info ['subtrahera'], 'rating' => round ($ product_api_info ['rating']), 'recensioner' => $ product_api_info ['recensioner'] ? $ product_api_info ['reviews']: 0, 'minimum' => $ product_api_info ['minimum'], 'sort_order' => $ product_api_info ['sort_order'], 'status' => $ product_api_info ['status'], date_added '=> $ product_api_info [' date_added '],' date_modified '=> $ product_api_info [' date_modified '],' viewed '=> $ product_api_info [' viewed ']); 

Det viktiga att notera här är att OpenCart ger kontextspecifika argument till din metod. Den första $ väg argumentet berättar vilken rutt som är associerad med händelsen som har utlösts. I vårt fall borde det vara katalog / produkt / getProduct. Det andra argumentet är produkt-id eftersom det är ett obligatoriskt argument av själva getProduct metod.

Logiken är något som här: vi jämför produktens modifierade datum i OpenCart-databasen med informationen som returneras av API-återuppringningen.

Så det första steget är att ladda upp produktinformationen i realtid från API: n. Observera att api_call_to_fetch_product_info Metoden är bara en dummy-metod som du vill ersätta med ditt aktuella API-samtal.

Därefter använder vi getProductLastModifiedInfo metod, som skapades i det tidigare avsnittet, för att hämta produktets modifierade datum från OpenCart-databasen.

Slutligen gör vi jämförelsen, och om datumet skiljer sig, uppdaterar det OpenCart-databasen med den senaste produktinformationen med hjälp av updateProductInfo metod i vår modellklass.

Vi har också returnerat produktinformationen i arrayformat på samma sätt som den faktiska getProduct skulle ha återvänt. Det är viktigt att notera att när vi har angivit returvärdet i vår krok, kommer det inte att ringa några ytterligare händelseanrop inklusive samtalet till originalet getProduct metod också.

Så, på så sätt kan du påverka genomförandet flödet i OpenCart. Det är ett riktigt kraftfullt sätt att ändra kärnfunktionaliteten. Du bör dock vara försiktig när du närmar dig den här lösningen eftersom det ger dig total kontroll för att ändra den resulterande effekten av vilken metod som helst.

Slutsats

Idag har vi diskuterat en av de spännande funktionerna i OpenCart-skriptanmälan. Vi började med en introduktion till ämnet, och det var den senare halvan av artikeln som visade hur man använder dem genom att bygga en anpassad händelsemodul.

Som alltid, om du letar efter ytterligare OpenCart-verktyg, verktyg, tillägg och så vidare som du kan utnyttja i dina egna projekt eller för din egen utbildning, glöm inte att se vad vi har tillgängliga på marknaden.

Frågor och kommentarer är alltid välkomna!