Transcript

Peter Jaap: Hey, how are you? 

Jisse : Good, so this is the day after Adobe Developer Live, but yeah, we just had to admit that we didn't spend the whole night just attending that event, so you didn't do anything at all with it, right? 

Peter Jaap: No, I had my day off yesterday, so I was focused elsewhere, I didn't watch any presentation, but I got to use it. 

Jisse: Yeah, so actually, the program started at 3:30, I think Amsterdam time, so at that time, I wrapped up a meeting I was in and then just tuned in to the opening keynote, andI had a couple I needed to drop in and out of the whole program, but I think I got a couple of good points out of it. Yeah, so don't we develop a live, the first time actually that it was no longer just a Magento event, but also an Adobe event, so to me that's kind of like the first interesting point about the whole thing that was labeled Adobe developer live and then column Magento Commerce as in maybe there's going to be a lot more other Adobe developer lives, but then focused upon other areas of Adobe. Still, this one specifically was for Magento Commerce. 

Peter Jaap: Yeah of course

Jisse:  So I think there was the usual talk about the route map not necessarily, or at least I didn't hear about Magento 2.4.1 necessarily, it was just over all what kind of developments were happening. So, I listened to a couple of them, a couple of features were added to PWA studio or are going to be added to the PWA Studio, which is kind of my thing, Product Recommendations and Internationalization GraphQL stuff. It was kind of interesting to see that it was no longer just a Magento thing but also an Adobe thing, and I've been personally intrigued about the introduction of React Spectrum, so I heard about this over a few months ago. 

React Spectrum is a react vAriation of Adobe spectrum and Adobe Aria and Adobe Stately. Adobe Aria and spectrum are basically UI component libraries that allow developers to just focus on maybe the features instead of the UI, but its kind of feels like it's all related to the Adobe experience cloud so not necessarily related with Magento but still relevant. I think to anyone who wants to combine Magento and Adobe experience Cloud more and more. So yeah, to me, it was kind of interesting to see the direction instead of the technical details reading from that.

Peter Jaap: So, this all going to be part of the PWA studio or is it separate from it? 

Jisse: Well, that's a huge question mark for me, but my feeling is that the React spectrum is separate from PWA Studio. So, it's just a separate Library also developed by a separate department.

Peter Jaap: PWA Studio was implemented. 

Jisse : Well, that's one of the bigger questions because in road map of PWA studio, I noticed that there's a checkout coming, and then within this checkout, there's an integration with PageBuilder so that people can use PageBuilder to add in specific content types within the checkout system. I'm not sure how much of that PageBuilder is going to be integrated with experience Cloud, but I was under the impression that on the long run, this integration should be happening. So, PageBuilder picking up on logic and picking up on UI possibilities basically of Adobe Experience Cloud. So, with that, theoretically, React Spectrum and Aria would be part of the possibilities as well, so I dived into the technical part of the react spectrum and react stately as well, and to my impression, it's just another UI component library, it is just another set of collection of hooks. Still, then as a reactive developer, if you're into react, the next thing, it's nice to see that there's some kind of UI components library that you could just use and likewise react stately is all about hooks. I didn't look into the practical application of this yet but the other, theoretically, it could be combined with PWA Studio. 

Peter Jaap: All right, 

Reitsman: so I was kind of eager also to join the DevExchange discussions, but I think that only kickstarted really in the middle of the night, so, I saw a couple of other community members from Europe joining, So I believe they are still sleeping in today and then there was this other tool which I didn't see myself in a talk. But I saw some tweets about it, the Safe Upgrade Tool which is supposed to kind of like inventor eyes your current Magento system when you're looking for an upgrade, but well, that sounds fantastic that maybe there's a gold scan to check for whether the goal that you're running is compatible with the next Magento person that you want to upgrade to but that's kind of like hearsay because I didn't find anything on the web yet. I didn’t find anything concrete about this, so what exactly is the study all about?

Peter Jaap: I did a quick Twitter search on it right now, and I see a tweet from Tadgh Bowe. He tweeted out this diagram for the Safe Upgrade Tool, apparently from the presentation itself from Developers Live, and it shows an upgrade from Magento 2.3.6 to 2.4.1 and then put the Self Ypgrade Tool in the middle. It will compare and validate, it will give you a list of issues and a complexity score and then a big block that says code fix. I’m hoping it will be automatic, but there's nothing and then a big checkmark with the successful upgrade. So, if we look at this diagram, it's going to be very easy. I don't think so, though. So, it says, okay, quickly by focused efforts in identifying conflicts between a new Magento version based on that description. I'd say it has a lot of similarities with the upgrade patch helper by Ampersand. I don't know how many updates we did for our clients. So, I'm assuming that the Safe Upgrade Tool will work pretty much the same as the upgrade patch helper from Ampersand. I'll explain what that one does. What you do is you upgrade the Magento core within your project, before you upgrade, you move the vendor dir to vendor_orig or whatever you want to call it. Then you run a diff on the entire vendor versus the original vendor dir, then the diff will deal with the updated Magento version. That’ll give you a giant patch file, and then you install the upgrade patch helper, which is a PHP file, and you point it towards your Magento installation and you give it the patch file you just created, and then it will spit out a list of all the plugins or themes that have changed or touches files that have changed between the two Magento versions. So, for example, it will give you a type plugin. It will say in the block on the page that PHP has a plugin that is in the …. and that touches PHP code that has been changed between the version that is currently running on and the version that you've upgraded towards. So, this might introduce conflict, and then you can walk through the diff to see whether something changed that file that is relevant to the customization being done by either your own or third party module. So, we've done this in the past. I don't know how many, let's say 50 upgrades using this system, and yeah, it pretty much catches everything if you go through the list thoroughly. You check the code of the extension; you might need to install a newer version of the extension if it's outdated, or you might want to fix it yourself. So, once you've reviewed all the items that are in the patch file, then you are good to go. So, we haven't had any big problems with stuff that we missed or something using this approach, so I'm guessing to say it’s going to be the same. So, you'll just generate a patch file, a diff file between your old version, a new version, and then it says ok: these are the files you should check. 

Jisse: On top of it, of course, like after such a report has been generated, the nice thing is that you're still being guided on making the real modification. So, theoretically, if you make a certain preference or a plugin Interceptor that needs to be changed, we still could have software that is reporting, which specific line is depending upon a certain class that is spaced out or a certain interface that is no longer there or deprecated code. So theoretically, this software also make reports.

Peter Jaap: You think it will be instead of just saying, hey, look at these files. There's a change in this file. It will go into the file and use tokenization or something to see which method has changed.

Jisse: Well, theoretically, I don't know. Still, it's just that it is kind of interesting that if you zoom into why a certain Magento upgrade would be difficult, step one, let’s say -p2, if it drives your own goals, your codebase, your modules to see like where the pinpoints might be, and that's basically where this composer patch helper might comment that the … sent the link that you mentioned. Still, then on top of it, more things could go wrong. So reporting on semantic versioning, reporting on deprecated code so that I guess them that in the last half-year, we hear or so more of those tools came to light that is simply aiding developers to do their task for operating, theoretically this substitute was trying to combine maybe as many as possible instead of just one. Yeah, I don't know if it's real.

Peter Jaap: Let's see what they come up with.

Jisse: So, we're still to playing judge guys that might be intrigued by news. But well, it's hearsay until now. We simply want to do with wait and see the stuff for real before we can judge upon it. 

Peter Jaap: Yeah, Jamie Huskisson from JH tweeted today. They've advised on creating this Safe Upgrade Tool. So, Jamie can give us some more information about it.

Jisse: I just wondered whether we should discuss the upgrades towards Magento 2.4.0 or actually that a lot of agencies out there do not upgrade to 2.4.0 but actually wait for 2.4.1 to be released. Agencies like yours; we discussed not to have that discussion. Well, maybe we shouldn't have the discussion. Still, it's kind of interesting to see that maybe this Safe Upgrade Tool hooks exactly into that pain point that a lot of agencies are scared to upgrade, instead of upgrading to a more stable version, a lot of times the opposite is true. Hopefully, this release of software will be well one of the many steps to come to make it easier to operate or have you given up? 

Peter Jaap: We haven't given up. I'm just skeptical that you know, the reason why we skip a dot over it and is because we feared introduces a lot of new bugs, and so there's a regression there, and I don't think the safer bread tool or will address those regression issues. Yeah, it will probably identify any compatibility issues between any plugin preferences, overrides Etc, and not per se yeah bugs introduced in a new data version because there's a lot of new functionality. So, I don't feel like a Safe Upgrade Tool or upgrade patch helper makes it more comfortable for us to upgrade to a dot 0 version. Yeah, simply because it doesn't scope out the bugs. 

Jisse: So, the thing that is for me a little bit worried about that approach. I wrote a blog post about this and then last time during episode one. We also discussed a couple of the features that were introduced in 2.4.0, but 2.4.1 is coming out actually with a lot more features, and it seemed to us the last time that most of the effort that was put into 2.4.0. The current release was actually to remove my SQL as a search engine and introduced therefore as well as the only option elastic search that was kind of like the breaking change and the worrying thing for me is that the 2.4.1. is going to introduce more features instead of just the introducing bug fixes. Then actually 2.4.1 might be your 2.4.0. so that you need to postpone upgrading to 2.4.2. and where does it end, I was wondering?

Peter Jaap: Because at this point, we can just install 2.3.5-P2, but if 2.4.1. comes out, we won't have a 2.3.5-P3 obviously, we will only have a 2.4.0-P1.

Jisse: Do you know that for sure there is no patch three coming?

Peter Jaap: Probably no, Magento has never communicated any such strategy, they'll update the security-only release for the previous version and not for another version back.

Jisse: Yeah, sure, except for maybe theoretically, if there's a security update or some giants coming but yeah, we don't know or you’ll say out loud that as soon as 2.4.1 is coming out 2.3.5 will be simply just skipped drop Barrel. 

Peter Jaap: Maybe they'll create 2.3.6 then just to keep the 2.3-branch alive, I guess they'll do that. So maybe we can upgrade the 2.3.6 at that point if 2.4.1. proves to be another giant update even though it is a patch version of grade. Magento is of course, known to still introduce functionality that will look like a patch upgrade.

Jisse: Yeah, that's basically also my point that many the agencies out there are making that decision upon to 2.4.0 is a major release. Still, then major is meant as in maybe this Semantic versioning kind of major, but it could very well be that with 2.4.1, which is just another marketing release, many other features are introduced. So, with actually new major versions, I think like the difficulty with Magento currently is that we're still kind of like dealing with these major upgrades. So, 2.3, 2.4, 2.5 

Peter Jaap: Other major upgrades from 2.3, 2.4 shouldn't be major in terms of the amount of code that's been updated. It could be one tiny change That's not compatible there, for you have a major release necessary to put that out. So a 2.4.1 release could be in terms of code affected a hundred times bigger than the 2.4.0. release versus the latest 2.3 release, so it Just says okay from now on, we're not backward compatible anymore. so you're right 2.4.1. could be potentially a lot more dangerous to upgrade to in terms of regression bugs than 2.4.0 was. 

Jisse: You don't know beforehand. So actually, this comes back to the original point this substitute might be really interesting and could have a little indication.

Peter Jaap: You could check the GitHub to see 2.4.1 release line or what is stacked with that, but it doesn't give a good overview of what will be in there. 

Jisse: No, I've tried this actually with 2.4.0 coming out and back then also 2.3.0 coming out, and it's just a nightmare to go through all of those catalogs. So hopefully, this is also still something that's going to be improved within the Magento distribution mechanism. Let's put it that we also still looking into that is my little experiment of last week. I worked for about a couple of hours to try basically to remove ElasticSearch from Magento 2.4. To me, it’s kind of like a funny like everybody at Magento was working hard to make sure my SQL full-text search is removed at 2.4 and then the ElasticSearch is the only alternative. Still, I put together this little open-source module simply labeled also remove search because it's not only removing ElasticSearch, but my SQL search as well. It was kind of like a silly experiment, but I'm running a shop myself that doesn't need a search. It doesn't deserve Magento either, but it's just for history's sake that I'm running that shop on Magento but then I felt okay. I just need to remove the search all together instead of just adding the ElasticSearch for a shop with about 50 products. So it made more sense to remove stuff, for me, It was kind of like educational research as well to simply see also how many bindings there are between core classes and the search mechanism, which shows like the stuff that still need to be cleaned up to allow for ElasticSearch to be replaced with yet another search engine 

Peter Jaap: But isn't layered navigation also tied to a search implementation?

Jisse: Yeah, in some way. So, what I did in my module was also instead of just going from ElasticSearch to obtaining a collection of products. I simply used the product repository to fetch such a collection, and that's kind of like The same logic that layer navigation would do and I tried to do the same thing for GraphQL as well because underneath the GraphQL product search is also based upon that same mechanism but haven't tested it out there yet but it simply shows that a simple search within Magento is hooking into we left the search at this moment far too often so that it's kind of like really hard to replace ElasticSearch with solar or Sphinx or anything , we're just kind of like a cool little experiment to see how far I could get some. Well, it's a success because I was able to remove the ElasticSearch together.

Peter Jaap: But isn't that layered navigation also tied to a search implementation?

Jisse: Yeah, in some way. So, what I did in my module was also instead of just going from ElasticSearch to obtaining a collection of products. I simply used the product repository to fetch such a collection, and that's kind of like the same logic that layer navigation would do and I tried to do the same thing for GraphQL as well because underneath the GraphQL product search is also based upon that same mechanism but haven't tested it out there yet but it simply shows that a simple search within Magento is hooking into we left the search at this moment far too often, so that it's kind of like really hard to replace ElasticSearch with solar or Sphinx or anything , we're just kind of like a cool little experiment to see how far I could get some. Well, it's a success because I was able to remove the ElasticSearch together. 

Peter Jaap: All right, cool. So, the next one on the list. Many people use composer patches, of course, to fix stuff in an older Magento version of which there's a PR and get up. You want to patch it up. So, historically there's a cweagans, composer patches plugin that is used a lot in the Magento world, but it's a platform-agnostic composer plug-in. Basically, what it does is after you install a certain package, it will then run a patch file, which you have placed on wearing your git repository, and the patch file will update the file in your package with the diff in the patch. So, we recently ran into an alternative for the cweagans composer patches plugin, the Vaimo composer patches of Vaimo, a large Scandinavia based Magento agency. They created a composer patches plugin. Well, I think you can use it also platform agnostic, but it's very useful with Magento. It offers a few extra options on top of the cweagans. For example, it will search patches there, so you don't have to place your well explicitly list your patches in the composer.patches.jsonor in the composer.json itself. You just put it in a folder, and it will recursively search through four patches in that, you can also add links to GitHub issues Etc. You can define versions, so only apply this patch when this package has a certain version or is the version is older than a certain version Etc. So, it has a lot of cool advanced use cases. We completely switched to the Vaimo one. It also has some commands to run the patches separately from the composer install command. Also put it on certain platform requirements only apply this when the shop is run on PHP 7.3 or whatever.

Jisse: So you can install all the patches in a certain directory because this is the same issue that I'm bumping into with cweagans, but we are good here.

Peter Jaap: So, with a copy, if we have a patch that is applied to multiple shops we can just copy the file in, and that's it. We don't have to open up the JSON anymore. You'll just use annotations like at level, at the label, at the link. On the top of your patch file, the vaimo composer patch will automatically bring the metadata, and then apply the patch to the package or installed. That's pretty cool. I also created a small it was a grease monkey temple monkey script, and Lewis Voncken, from Experius created a Chrome extension for it. So, you can find the Magento 2 composer patches helper Chrome extension. What it does - if you open a PR in the Magento repository, you'll see a little button next to the edit button that says View patch JSON, you can just copy-paste the created JSON into your composer.patches.json file and if there is none you can take the patch file from the raw patch file from the GitHub repository, you won't need to have the patch file in your repository. You can just point it to the source, to the Raw patch Source on GitHub and then it will pull it in whenever you do a composer install, or a composer patch apply. So, in that case, you edit your JSON file, but you don't have to add the patch file because you will download it from GitHub. So that's you can just copy-paste the JSON. You only have to replace which package it is because we can infer that from the pull request. Sometimes it's a unified diff. So, it touches more packages so then you'll have to edit some stuff, but it will tell you in the JSON, it generates comments itself. So that's a nice little helper that uses the addition of a package from a Magento PR into your installation. 

Jisse: Yeah, maybe to explicitly mention on top of what you just mentioned. It's also meant to create exactly those patches used for Vaimo, the composer patches plug-in of vaimo. So it's kind of funny for me to see always that all of these tools are built on top of each other, but we started all story by mentioning that we don't want to upgrade to the latest release; instead of it might be better to implement certain composers patches and then you need a tool for that learning. You need to improve the tool on top of it. 

Peter Jaap:  So, a little gotcha when you move from the cweagans composer patches to the Vaimo composer patches: the Vaimo composer patches is less forgiving when it comes to extra data in the patch file. So, I usually create a patch with git format-patch and then now you have to add –no-prefix --no-signature to the format patch command because otherwise, we will add this little signature at the end of the patch file and Vaimo composer patches doesn't like that. So, when migrating, clean up the garbage at the end of the patch file to make it work with the Vaimo one. Also, cweagans composer patches tries to apply patch level 1 first, followed by Patch level 0 and then Patch level 2, 3, 4, etc. Vaimo doesn't do this. It will only try that's level one by default, so if it's Patch level 0, you have to define it yourself with that level. 

Jisse: So that's again. That's a task that you would typically include in the past file now. 

Peter Jaap: Yeah, so beware of the patch level especially when you get the dev contains the a / b / prefix when like GitHub does that,

Jisse : I would say that there's any way for better soon as you download better-created patch level yourself. You always need to be aware of the best level itself. 

Peter Jaap: Yeah, if you get the PR from the Magento repository, you'll always need level 5 because it has the app code etc prefix in there.

Jisse: Exactly, that's again something that is Chrome plug-in is automating, right? 

Peter Jaap: Yeah, automatically will add the at level 5 in there. 

Jisse: That's cool, I also came up with this other tool, the Szeidler composer cli, but you have just looked into the cweagans story again. So well, the vaimo solution allows you to have a compulsion patch folder the cweagan approach requires you to add each individual patch to the composer.json file, and that's actually where this tool also comes in the Szeidler. I think I'm pronouncing its name right as Szeidler simply allows you to do that more easily. Still, if I've now heard about this vaimo approach, I've heard about it before, but I've never implement that myself. It sounds like we just a lot easier than the other

Peter Jaap:  So much easier. It's a great tool especially if you work on multiple projects, you can just copy-paste, either the patch file or the JSON patch, which will download it from GitHub automatically, and then it just works, and it's great.

Jisse:  Yeah, so anything else you would like to add? 

Peter Jaap: Yeah, so I have another extension I ran into, which proved useful in a couple of client projects. So, it's called the Baldwin URL Data Integrity Checker, especially when you migrate from a Magento 1 to Magento2, the URL keys and URL paths, could prove problematic when you know garbage in, garbage out. So, with this extension does the work. Once you install it and has a few commands on the command line. Few commands catalog category Integrity check and catalog product Integrity check, and it will check for duplicate URL keys or URL paths that are out of sync with your URL keys. So empty URL key values all kinds of checks. So, it's a CLI command, you kick it off, it will populate some JSON files, and then you can view it from the back end. You can also configure it or to run it periodically. So, you can just install it and have your clients. Check it once in a while whether your real data is still okay. if it isn't, then sometimes you might have problems with safe and products because to duplicate your URL keys, they can't fix their shit themselves. 

Jisse: So, to my understanding there's this kind of Loco hooks into something else you've created earlier. The elgentos regenerate getting more equal. Yeah. Well, right. 

Peter Jaap: Yeah. So, they regenerate catalog URL, one is actually, forgot the name. It was forged from ESL, ISL, so it will add a command console that will regenerate your product URLs, and you can give up product IDs and scopes / stores, and it will regenerate these URLs. So, we usually install the Baldwin agency URL data Integrity Checker extension along with our regenerate catalog URL extension along with the FisheyeHQ URL rewrites Optimizer. So those three. We put in pretty much every install, and that will allow us to check for URL data inconsistencies and regenerate them as necessary.

Jisse: Yeah, So in Magento, one of the most horrible things that kind of like often happened was that product URLs and category URL were just regenerated again, and again, and again when dealing with product categories being imported from external resources. In Magento 2.0, I had that issue myself as well 2.1, as well 2.2, but then in 2.2 kinds of like halfway, it disappeared. It was for sure that I had not worked on myself that much, but it was kind of like that. I heard complaints about it. is that still an issue that you bump into or not necessarily?

Peter Jaap:  we haven't run into that issue that I can remember with Magento 2. Yeah, I thought it just disappeared. Yeah, since we migrate everything to Magento 2,

Jisse : yeah, it is still possible but then only if there's a kind of like a bar being clumsy import mechanism as well.

Peter Jaap:  We sometimes run into it with Magento 2 shops. We haven't migrated, but every single time it was because they migrated the URL rewrites from Magento 1 to Magento 2. So yet again, garbage in, garbage out. 

Jisse: Yeah, So cool. it's already kind of like a long list of different ideas, different extensions, different tools to help developers. Do you have anything else you want to mention?

Peter Jaap:  Yeah, I wanted to. I ran into the Magento / Community features repository on GitHub. So, github.com/magento/community–features and that's very interesting repositories just issues with faults for features by the community.

Jisse : In our discussions, it's just perfect for reading through it and get kind of like a glimpse of what the core developers are up to..

Peter Jaap:  So one of the oldest issues there with the most comments is one again by Tadgh Bowe.

Jisse:  I'm just getting destroyed by this guy if we keep mispronouncing his name. It's “Tyke”.

Peter Jaap: Tadgh, so Tadgh has an opened like the new configurable product. You create a configurable product in the backend, and you want to create variations and but your simple product your children already exists. There's no way to hook them to the configurable product. You have to generate them first by choosing the attributes on which you want to create symbols for and then basically generate them and before you save them, you can manually add the existing ones and then remove the ones that were about to be saved. So, it's a cumbersome, not very logical workflow to attach existing simple products to a new configurable product. So, he opened this issue in November 2015. So almost five years ago. It still hasn't been resolved but and this is the interesting part, somebody named Pisces ThankIT created an extension of his name, I don't think he's called Pisces. But there's an extension called ThankIT configurable Wizard, and this adds once you move through the Wizards to select attribute and then give it attribute values. It will add a step to manually add the products yourself so you don’t have run through the entire process and remove the other one. So, this is again small little extension that adds that option show to make that workflow Bliss a little less awkward. They might fix it in future versions, but for now, this extension does exactly what you expect to happen when you go into this workflow

Jisse : There is all kind of interesting to know of right that this repository addition community features repositories full of ideas. So, it's not necessarily features that are going to be implemented in Magento in the next version, it's more that they're sort of specific place for the community to collaborate, elaborate, discuss what kind of potential features there are because yeah, that's another one that you put on the discussion list number 126 disabled modules per environments, and it fell to me kind of like an old story as in well, of course, it's a needed feature. Still, going through that's, I just scan through the whole issue itself. The discussion date back to 2017 and 2018. So, what is your take their own? It's all about how to disable modules for a specific environment. So, development environment, production environment and of course, all of those changes are normally written into the config.php file. There's more to it. 

Peter Jaap: Well, right now, if you enable or disable module or an extension, it will be saved in the app ads config.php file, and so it's either disabled or enabled, but for certain extensions, you only want to have it. So, there's a let's say there's a Magento extension that's in your composer require dev, so your composer require dev like the example in the Fred is the HO template hints extension. So, you're needed as then you enable it, so then it will be enabled in your app ads config.php file. So, you commit that to get, and then you deploy your web shop. So, on the production server, the HO template hints extension will be enabled or disabled, but we'll have an entry in the app ads config.php even though on the production server, there won't be any code for that extension present because it's the dev extension. So the proposal in this fret was to have or to move or have the option to move or override the enabling or disabling of certain extension in enthalpy HP, so for example, put app ads config.php that will have a chart template since disabled and then in the efforts and the PHP on your local machine that you will have it enabled.

Jisse: Yeah, maybe you could comment on that as well because there used to be a time that if there would be a module in config.php that was enabled but that module was actually not found by the system. It will generate an exception but that time has long been there. 

Peter Jaap: They remove that exception exactly because of this problem.

Jisse: Yeah, exactly. 

Peter Jaap: Yeah right now it's not a big problem that is mentioned in in config.php, but it feels dirty .Right now, let's say I enable it locally but we have it in git as disabled. So, then I enable it locally, so every time I have to enable it locally and then run the shadow upgrade maybe again so that there's a the workflow isn't perfect for local development. 

Jisse: Yeah, and the annoying thing is in it, like every time that you run the commands within Magento module enable module disable. It will modify the config.php file. So, it will redo or undo the change that you've carefully just crafted together and they are just annoying. Yeah, so that definitely could good discussion, but you simply wanted to mention it because it's be a good discussion as well even though there's no logical outcome

Peter Jaap: I want it and it's been opened in 2017 and mainly because back then it would have thrown an error and not anymore. It feels like such a logical implementation, like a lot of other Frameworks support disabling modules per environment, but Jesse doesn't

Jisse: I don't see a pull request on your behalf. 

Peter Jaap: It's not that big of a problem yet, I might as basically become annoyed by it and then spend my Sunday afternoon to do this, but I'm happy to give it an up for grabs level and let somebody else do it.

Jisse: Yeah, then the next be there's another really interesting one, the PHP 7.4 preloader support, so once I started to read about PHP 7.4 I became right away as I think about the preload feature. So, it's something if I say correctly that hooks into the opcache for the next details just to make sure that when the application is being loaded you can just come up with your own preloads file that you need to put together so that all of the relevant files all of the relevant PHP classes for instance for code Snippets that are guaranteed to be call upon are loaded into the opcache. So, once PHP 7.4 came out. I was also one of the few people that then trying to play around with this, Magento 2.4, 2.3 didn't support PHP 7.4 yet. So, it was kind of like working with a half broken installation as well but yet the issue that you basically refer to was also links to I think actually the work of a guy called Kehil who's actually kind of important and I know that he played around with it and also classifying it as a simple but back then actually PHP 7.4 were still not supported yet. So, for me Magento 2.4 would be ideal to play around with this again. 

Peter Jaap: They did already implement in 2.4. 

Jisse: Yes so they implemented the opcache preloader or because still, you need to configure this preloader in your own PHP configuration to make use of it. 

Peter Jaap: Yeah, so it'll probably need some console, command or whatever to generate the file that you need to preload it so that the Kirill has comparison where PHP 7.4 with preloading is 11 percent faster than PHP 7.3 without preloading, of course and then somebody refers to an issue and a pull request that says we've implemented it here and just looking at this giant pull requests and it's giant and I can't find anything that actually generates the preload file for PHP. So, I'm not sure whether it's actually it supports it that's what it says. We supported it in PHP 7.4 we can really see whether the preload file also being generated by now

Jisse: Yes, that is like an interesting thing to take a look at and I think the discussion is anyway interesting to see like what kind of pros and cons are there to consider these features but yeah, so I personally think that the PHP 7.4 preloader is not the serving something that you can just define for all of the Magento installations out there. It seems almost like it's it needs to be custom created but theoretically it could be generated as you see a like usual simple console or command.

Peter Jaap: Yeah, I think you can definitely create something that will do it on a pre installation basis and will generate a file, but I also think that that you can create a default file for the Magento core so it won't necessarily preload everything from the third party extensions for your own custom extensions, but it will definitely then do Magento. So as far as I can see there's now only support for it. So, they updated the classes for PHP 7.4 to make Magento to work with PHP 7.4 and for the preloading part, I think you can generate or create some kind of tool that generates the preload file and then walks through the code in the current installation and generates file specifically for that installation. 

Jisse: Yeah, maybe to comments all my own experiments showing in the past what I tried to do was simply just in Instantiate or not instantiate, load all the classes that were to be found in the Magento, so that's kind of like a lot of different classes and all just to generate also those classes as know opcache entry automatically, but that's actually a performance optimization for the worse because then you're just adding classes to the opcache, that actually not going to be called upon and that's kind of like the interesting parts and that it's only really an improvement of the situation if you can say actually that all of those classes are actually going to be called upon in runtime, in real life, on your frontend or develop your backend and that by moving them into the opcache and the memory grows but the speed goes up. 

Peter Jaap: Yeah. So, for example if you use the composer dump autoload and then use the class map of furtive argument then used the autoload Class map PHP file as an input for preloader for the preload of the PHP file. 

Jisse: So, it’s not optimized

Reitsma: No, better optimizing would be just to create a tempest file system and just prove very true that they move everything into around

Peter Jaap: Well, there's also an approach for it, maybe you could run like a new relic or a Blackfire for a while, let's say for a day or two on your production web shop and then it will generate a list of all the PHP files that have been touched and then create a file based on that?

Jisse: Something similar. Also, just a partial listing of all of the modules that are enabled and then actually try to determine which kind of classes are actually also call upon all the frontends. So that might be and then theoretically just spidering across all the dependencies that are loaded with it, but they have it so it's not that straightforward. So, coming on with the coral listing maybe just loading, preloading most of the classes in the framework because every time when you load something in the BOOTSTRAP, that’s adding up, there's a requirement for those classes but theoretically, another approach is of course just look at the output, create a simple block class, declared classes and just do rundown of all the classes that are called upon by using a certain frontend block, but it's a little bit more cumbersome. It's a little bit more taking effort than just adding something bluntly to it, but then still like it. It's all about performance. So, the kind of thing that could really cool feature to discuss and to see it and look forward to within a Magento to work. 

Peter Jaap: Yeah, definitely.

Jisse: Alright long listing. 

Peter Jaap: Let's wrap up. 

Jisse: Hmm. Yeah, I have fun. 

Peter Jaap: Definitely me too. I have a bunch of things to talk about in the next episode 

Jisse: I hope everybody listening is also eager to hear another episode 3. We need to come up with a good listing of what to discuss and what not. The current podcast were kind of like deployments composer patches and everything that’s flow flew from us but yet we will focus upon the specific topic, specific area of backend developments in the next episode. 

Peter Jaap: We could, if any listeners have any suggestions on which topic but I'm just as happy to talk about whatever comes up. 

Jisse: Yes. 

Peter Jaap: Thank you, sir. Thanks everybody for listening. 

Jisse: See you next time.