Watch Part 1 of our Summer Webinar Series on Magento 2 Extension Development presented by internationally recognized Magento U Trainer, Ryan Street. Attendees learned about the steps necessary to start Magento 2 extension development including: assessing your extension goals, requirements for your environment, submission to the Marketplace, software and tools for development as well as some tips for success.
Don’t miss the rest of our Summer Webinar Series!
Watch Part 2: Development here!
Watch Part 3: Troubleshooting here!
Transcription:
Amanda: Welcome, and thanks for joining us for part one of our summer webinar series, Magento 2 Extension Development: Set Up. We will have a Q&A session at the end, so please submit your questions at any time in the question ping [phonetic] on the right side of your screen. You can follow us today on Twitter, @InteractOne, and you can Tweet with us using #M2Dev.
And I’m going to go ahead and turn it over to Ryan.
Ryan: All right, thank you very much, Amanda. So this is part one of a three-part summer series that we’re doing here at InteractOne that talks all about the whole process of extension development for Magento 2.
So we have three different parts where — we have part one, which is setup, which is what we’ll be going over today, and we’ll get into all the details of that. Part two will be a really interesting one, because we’re going to be going over a live coding exercise where we’ll be doing real development work, actually taking and creating an extension right over the webinar, which will be a really fun exercise to do so you guys can see a lot of the different aspects of development for M2. And then third is the Marketplace submission. So the Magento Marketplace is a new place that’s separate from the Connect store that has some new kind of rules and requirement for high-quality and relevant extensions.
So what we’re going to be talking about today is the setup, so this is everything to get you ready for that part two and part three of submitting an extension to the extension store, so we’re going to be talking about assessing your extension goals, requirements for your environment, getting all that stuff set up, the submission to the Marketplace or the requirements for that, software and tools for development, as well as some tips and tricks to help you along the way to kind of help with any shortcuts or any gotchas that might happen.
So let’s dive right in. So let’s talk about assessing your extension goals. So there are a couple of different things that you want to look at before you really dive into the code and you start coding away at an M2 extension, and what you want to look at is a number of different factors — first of all, where are you starting from; another thing is what about — what’s its business value, which is a new part in the Marketplace for submitting an extension; and whether or not you have to do things like support multiple ones or keep legacy support for an old M1 extension.
So diving right in, let’s talk about business value. Now, there’s a thing in the Magento Marketplace now called the business value review. It’s something that you need to think about ahead of time. A business value review for the Magento Marketplace is where Magento will actually look at your extension — not the technical part, not the code, not the nuances, does it perform, does it pass code inspection. We’re talking about is your code appropriate for the Magento Marketplace, is your code or your extension, more specifically, something that belongs on the Magento Marketplace, and they do that through a business value review.
And so the business value review basically ascertains whether or not it passes a certain set of criteria, and there’s a lot of information on this through the Magento Marketplace Q&A as well as submission guidelines, but some of the high points that you really want to think about are things that you’re thinking about before you even start writing that extension. So one of the things is does your extension solve a problem, are you actually creating value for the merchant, are you actually creating, extending or enhancing functionality for a merchant that wants to purchase your extension on the Marketplace, okay?
So if you’re not doing that, then it’s not going to really be overly relevant, and in order to avoid any clutter in the Marketplace, Magento is going to be a little bit more stringent about what they accept into that Marketplace. Is it relevant? Are you adding good value to the merchants? Are you able to give appropriate properties and extensions and — what’s the best word — value to the end user, okay, things like pricing — is your pricing appropriate?
You know, if you just put simple social share buttons onto an extension and decide to package it up there for thousands of dollars, Magento isn’t going to necessarily be okay with that. Now, granted, they’re not going to take over in a very dictator type role that states, “This is the only price you can say,” but the pricing does need to be appropriate for what you’re providing.
Does it have appeal, meaning are you appealing to a broad audience, which is an audience that would be most likely to look on the Marketplace, or are you appealing to a very narrow audience? If that’s the case, if your audience is very narrow, let’s say a very, very specific set of B2B or something to that effect, maybe the Marketplace isn’t the best place for your extension to be hosted. Maybe just your own store would be okay for that.
So these are some of the things that Magento looks at. An important thing to note is that if you do not pass this business value review, your extension will not get accepted. You can pass your technical reviews, you can pass all your code audits, you can do all that, but if they find that you have just submitted an extension that dozens of other extensions already exist on the Marketplace for that, they’re not just going to let another one in. They’re going to say you either need to provide better value or be a differentiator somehow, and so that’s very important to think about when you’re thinking about your M2 extension.
The last one on here is thinking about promotion, and while you can do multiple things about promotion and Magento and Magento Marketplace will help you with promotion, the Magento Marketplace guideline states that you do need to, in fact, be your own cheerleader, as you will. You have to be the one to be at the forefront of your promotion, because a very important factor also in the business value review is even if you pass every other review process and your extension does get accepted to the store, if it does not have any interest — meaning that no one really cares about this extension — they can actually remove it.
So even if you pass the initial business review and you’ve passed every other review, and your extension is just not getting any traction, in order to avoid clutter on the Marketplace, they will actually remove those low performers or those non-performers off of there.
So let’s go through the different types of avenues that you might take when developing extensions for M2. First of all, do you have just a brand new M2 extension idea and you’re just ready to start going, you don’t have anything else to compare it to? Well, congratulations. You can technically start coding. You can — there’s no real additional thought process or additional setup steps beyond just your standard business steps that you might have, so that’s nice to not have to kind of go through any extra avenues there.
What about an M1 migration? So you have a Magento 1 module, and now, with the Magento 2 platform being out, it’s time to put it into the Magento 2 Marketplace. Now is a really good time to look at your M1 module and do a full audit of your code. This is a time to spruce up any areas where there might be performance issues or some bad code that you were going to get to but never really got around to or areas that may not apply anymore. Maybe you have an M1 extension that is now covered by the core features of M2, things like product videos, ex-remaining inventory levels, things like that, that are now part of M2 that weren’t always necessarily part of M1 and the core.
And then from there, you can begin to plan out your extension process, and what I mean by that is the platforms are different. These aren’t just direct ports over with a modern platform stack. These are different approaches, so you need to think about how you want to extend this functionality that your M1 module solved into M2.
A quick example would be something like you wanted to append some sort of functionality and you had to perform things like class rewrites in M1. Well, now in M2, they give you the ability to use plug-ins instead of class rewrites whenever possible, so you need to think about the best way that you want to accomplish those goals from M1 into M2.
And the last one is leveraging the extension migration tool, which is a tool provided by the Magento core team that allows you to port M1 code over to M2, and we’re going to get into that into more detail a little bit later on in the presentation.
Now, what about supporting multiple platforms? So let’s say that you have an M1 extension, but it’s still alive, it’s still kicking, you still need to support it because maybe it references a third-party API, maybe there’s something else that you need to make sure that it’s still being leveraged and supported, but you also need to build that into the extension. Do you want to go necessarily through the idea of always having to maintain these two extensions across these multiple platforms, which can get a bit cumbersome at times, because how one approach will go for an M1 extension is not how the other approach will go for the M2 extension, so on and so forth?
One of the best approaches you can take is using what’s called a library approach, basically an intermediary library which can be leveraged by an M1 or an M2 extension, or other platform extensions as well, in order to maintain a central code base and have that code base be used from the other modules.
And essentially what would happen at that point is your M1 module and your M2 module would be wrappers for your library, and you can distribute your library with both your M1 and your M2 module, and the library can evolve over time. This allows you to create support, fix bugs, patch up security holes without having to worry about those nuances too deeply of the M1 and the M2 module. There’s a great article on that that covers that with really, really good — really good aspects and good detail as to the approach to take with that, listed at the link here. This slide deck will also be available to download after the presentation.
All right, so let’s dig in a little bit into your requirements for development. Now, Magento has system requirements available to you from the dev docs that they have hosted, and those are all fine to use, but the requirements for development, while similar on a platform structure, there are certain settings and things like that that need to be a little bit different to adhere to more of a development environment.
So first of all, you have your standard Composer, your PHP, your Apache and whatnot. Now, PHP 7, 5.6 and 5.5 are supported, so long as 5.5.X and the X is 22 or later. So 5.5.22 or later, 5.6.X or PHP 7 are all supported, and whichever one you want to support is good to support, just so long as it is one of those. You need to make sure that your extension meets those coding standards as well.
Composer, Apache 2.2 or 2.4 and NGINX are all officially supported through Magento, MySQL 5.6. Either the Oracle build or the Percona build are both fine to use. For more specific development environment aspects, XDebug 2.2 or later I highly recommend using. It’s a very useful tool for active debugging in development, as well as PHPUnit 4.1 or later for all PHP unit tests that you’re going to be running, which I definitely recommend that you do run during active development, and the PHP Code Sniffer. It’s basically a tool that allows you to run your code — it’s a static code analysis testing tool that allows you to run your code against a set of standards that have been defined to make sure that your code meets certain code quality standards.
So a couple of little bit more specific settings — the later versions of Magento have the always_populate_raw_post_data = -1 because of the deprecation of the superglobal, so make sure that you have that updated, and this is pretty much universal now. The PHP memory limit — now, the production value they say is okay to set to around 768, I do believe, megabytes, but for testing purposes and specifically with unit testing [unintelligible 11:57] PHPUnit, they recommend that you set your memory limit to two gigabytes. There is a lot of overhead involved with running the unit tests and whatnot, so it’s good to have enough memory to be able to handle that.
XDebug — there is a max nesting level, which is defaulted to 100, which has allowed — which is basically the amount of times it will nest before basically XDebug will kind of throw an error and say, “We’ve reached our max.” There are plenty of times in Magento where that could actually hit, so basically all you really want to do is set your max nesting level to a value above 100 — 200, 500, whatever that might be, especially depending on what you’re going to be running into.
Also good is to enable the MySQL slow query log. There are some people that recommend this on production as well, but I always recommend this for development environments so you know where your bottlenecks might be forming, especially if your pending queries are creating your own queries. You don’t want to necessarily have something that’s slow performing that you want to push out to the marketplace, so make sure that things are performing, and you can kind of find those as a low-hanging fruit through that slow query log.
And then, finally, you want to enable Magento developer mode. Magento 2 comes out of the box with three separate modes. There’s production mode, which is optimized for production, so it’s optimized for performance. There is developer mode, which is optimized for development, meaning that security — I’m sorry, not security, but debuggers will show on the screen and the auto-generation will be on the fly with things like your interceptors and your factory methods. All those types of things are going to be generated automatically at run time versus ahead of time, so it’s a lot less performance, but it does enable your extension to evolve as you’re running through it.
As well as the third mode, which is default mode, which is kind of a hybrid between the two. Things will still run and be generated on the fly, but things like debuggers will not show on the screen because it could be potential security risks. So you want to make sure that you’re enabling yours in developer mode, and that’s a simple command line command that you would run, and that is listed right here: bin/magento deploy:mode:set developer, and it’ll enable developer mode for your platform.
So when developing your extension, the Magento core team followed a set of standards, and they also recommend that you follow those same sets of standards for your extensions. The PSR1 and the PSR2 coding style standards are the ones that they used for Magento 2, and there’s also another coding standard called the ECG Code Sniffer standards, okay?
There is — this is available right now on GitHub. You can use it in your PHP Code Sniffer tool, and it’ll allow you to evaluate any sort of errors that are potentially caught by the ECG, or the Expert Consulting Group, for Magento. They will help you evaluate whenever there’s potential security risks, performance problems, bad practices, so on and so forth, and you can use that for your coding standards inside of your M2 extension.
All right. Now, software recommendations — now, first and foremost, I want to point out that the title says, “Recommendations.” These are not hard-and-fast rules that you absolutely have to adhere to in order to develop an M2 extension. However, in my experience and as well as the experience of a lot of my peers that I’ve talked to, these were some really good tools that helped expediate their development process.
One of the first ones is an IDE. Now, I say PHPStorm, et cetera, on here because you want to use the IDE that you’re most familiar with and that gets you there the fastest. I personally use Storm; other people use Netbeans, Eclipse with a PHP plug-in, so on and so forth. If you are a Vim or Emacs user or just a general Notepad user, that’s fine too, but I’ve found that IDEs can really help you with a lot of those other tools that can expediate your development process.
Code Sniffer standards, unit testing, things on the fly, making sure your code quality is there, making sure there are no syntax errors or just generic errors that pertain to your specific version of PHP. If you’re running against a certain PHP version that’s become deprecated, you’ll know that you don’t want to use that anymore.
Next one is a command line utility. With M2 specifically, right out of the box they have command line tools built in, and there’s a lot of developer-oriented command lines — or commands available on the command line, so it’s good to have a command line utility, and whatever command line utility that is, it’s good to have up and running right away because you’re going to find yourself running those all the time — flushing the cache quickly from the command line, rerunning compilations, things like that, static content deployment as you’re doing front-end work.
All those types of things are really a lot faster from the command line utility versus maybe in the admin panel, where you’re going through and flushing the cache, waiting for everything to reload again. You can circumvent a lot of that unnecessary overhead by just using command line.
And then last but not least is the virtual environment. Now, some people argue against virtual environments, some people argue for them, and your mileage will, honestly, vary. I’ve found, though, if you’re looking to support extensions across multiple versions of things like PHP, maybe NGINX and Apache, those types of things, virtual environments will get you there the fastest. You can spin up your environment according to that particular stack, test your software or development your software and then be able to spin up other environments against other stacks to make sure that everything is still working as it should.
A quick example of that is in some of the earlier versions of Magento 2.0, you would run the test suite inside of PHP 5.6 and everything would run just fine. You’d switch it over to PHP 7, and suddenly you’d have errors without changing any code whatsoever. So it’s always good to have — to test against those multiple versions, especially since these versions are officially supported by Magento, so you want to make sure that yours are at least passing in those types of environments as well.
So, now, let’s dig a little bit into some of the tools that are available to you that you can use for your M2 extensions, okay? So first we have the code migration tool, which we had mentioned a little bit earlier during the M1 to M2 migration. So what the code migration tool is a tool provided by the Magento team that will actually — no joke — take your M1 module and convert it over to an M2 module. It’s a really interesting tool, and I highly recommend that you use it.
It’s available right now, and it’s for free to use on GitHub, and basically what it covers is your directory structure — so it’ll take your M1 directory structure of your module and port it over to an M2 directory structure, it’ll take your Layout XML and look at all the handles in it and then take those and convert those to their separate files, it’ll take Config XML as well as PHP files and turn those into their M2 equivalents, okay? Now, granted, this does do a lot of stuff, but it does require some manual review and cleanup.
The code migration tool is a string parsing tool at its core, and I know that some of you might be throwing your hands up right now and saying, “No, no, that’s not what it is. It does so much more than that.” I understand that, and you’re absolutely right, but it’s important to think of this tool as a string parsing tool at its core. The reason being is that this tool is not going to make complex decisions for you, okay, so it’s not going to know that you did a rewrite in M1 and converted that into a plug-in in M2, at least currently not at this stage in its lifecycle.
So there — you need to be aware that it is just simply taking an M1 equivalent and doing a string parsing to make it an M2. It will do things like dependency injection and do those types of conversions, but it’s not going to make very complex decisions like that, and you need to be aware of that when you’re making — when you’re converting this over.
It doesn’t take platform differences into account, such as the rewrite versus plug-in example I just gave. It’s not going to know which methods to create a plug-in for, especially since if you’re using a rewrite, you’re overwriting a protected method — a plug-in can’t be used for that. But if you are overwriting a public and a protected method, what route is it going to take? It’s not going to make those decisions, okay? You should always check your code.
However, I still recommend that you use this tool, because this can get you anywhere between 20 and 75 percent of the way there, depending on the complexity of your module. And even if it only gets you 20 percent of the way there, that’s still 20 percent more than from when you started from scratch, so it’s a really advantageous tool to use, and it’s also being actively developed against, which means that it will get better over time.
Certain things, it’s not going to cover. The admin HTML has been reworked in Magento 2, so the M1 equivalents of creating admin menus — I’m sorry, not admin menus, but admin grids and forms and all those different types of things aren’t going to translate one-for-one over to M2. Maybe in a later iteration it will, but as it currently stands, it’s not going to — and other things like that, so always make sure you’re checking your code and cleaning it up as necessary. Sometimes it’ll make silly little mistakes, and that’s okay because at least it got you 20 percent of the way there — at least, if not even more. Great tool to use, highly recommend using it, especially if you’re doing an M1 to M2 migration.
Now, the package validation tool — so what’s good about this tool is it’s also free and available on GitHub, and basically what it does is it validates the package that you have assembled before you submit it to the Marketplace. Right now, the Marketplace queue is a little bit long, and so you don’t want to run into a silly little mistake and have to re-go through that queue a second time or a third time just because you made a little error in packaging up your extension.
What the package validation tool does is it basically validates your package, the code itself, before it submits to the Marketplace — are the directories there, is the appropriate code there like Composer — I’m sorry, the appropriate files there like composer.json, module.xml, those little things like that, is certain things valid within those.
Now, it is important to note, however, that this does not perform all of your Marketplace tests, because the Marketplace tests include things like testing code validation as well as manual intervention — like we talked earlier, the business value review and those types of things. So it’s not going to be able to evaluate all of those, but at least it’ll help you from small slip-ups, especially when you’re first starting to submit your first extensions to the Marketplace. So I would definitely recommend using this after you’ve packaged up but before you submit it to the Marketplace — very useful to use, and I highly recommend it.
All right, so a couple of tips here as we’re kind of coming through this route. First of all, leverage your IDE. If you do in fact use an IDE, use it to its fullest potential. I’ve seen people who have downloaded an IDE or, even more so, paid for an IDE and just basically used it as a glorified syntax checker. Your IDE can always do so much more than that.
For example, a lot of IDEs will allow you to plug in static code analysis tools, a simple one being PHP Code Sniffer. You can do your code checking on the fly as you’re writing out your extension with your IDE, so you don’t need to write, stop, run tool, come back, write again, stop, run tool again. You don’t need to do that, because if you integrate it with your IDE, you can do it on the fly as you write and you can spot your error right as you’re done writing it. You can say, “Oh, it looks like we have a complexity error,” or, “It looks like we have a level 10 severity error. It looks like I need to fix those right now,” instead of stopping what you’re doing, going back and running the tool over and over again.
And your IDE can do so many more things than that. There are things like built-in command line utilities, built-in virtual environment handlers, RDBMS handlers. All those types of things you can use right from your IDE so you’re not jumping from tool to tool and interrupting your flow, and there are so many things it can help you with code completion and code assistance. I highly recommend you leverage your IDE, because it’ll greatly speed up your development time.
Leveraging your virtual environments — so if you do in fact decide to use virtual environments, I recommend that you use them to their fullest potential. You’re — if you’re going to spin up a virtual environment, you know, you — do it against the standards that you’ve been given. Do it against all the standards you’ve been given, since they’re so cheap to spin up and down again and they’re so simple to spin up and down.
So I would definitely recommend doing that, because that way, you’re going to avoid any sort of errors. When you’re just running on a host machine, your nuances are a little bit different because you’ve set them active to development or something like that, but then it doesn’t pass some review later or maybe you found there’s a performance problem or maybe it doesn’t pass another sort of test that it might be running. So those types of things can be remediated and fixed just by leveraging virtual environments.
Run tests as you go. A hard thing is — a lot of times with developers is that we tend to defer the testing until after we’re done developing. It’s so much more advantageous to run your tests as you’re going, write your tests, run your tests, or even if you’re not into writing tests, if you’re appending or extending functionality from the M2 core, run the tests against those pieces of functionality.
Maybe if you’re making a change to the catalog in the blocks or the models, run your tests against those blocks and models to make sure you didn’t change anything, because it’s very frustrating to put in eight to ten hours of development and then run your tests at the end of the day only to find out that there’s some sort of error and then it’s a very cryptic error that’s nested deep within your code that you’re going to have to spend a bunch of time trying to figure out, and you might have to even do a lot of rework because you went in the wrong direction.
Running your tests as you go will really help keep that sort of effect to a minimum. You can catch your errors earlier, and you can fix them a lot earlier too. If you know that you went down one path two steps in, it’s a lot easier to back up than if you went down a path 20 steps in, so always try and run your tests as you go.
Another one is what I like to call getting to green. Some of my students in my classes and stuff like that, I always put — you know, always repeated that over and over again, getting to green, and basically what that is is that all of your code quality analysis tests are passing and all your other tests are passing. Basically, you always want to get to the green checkmark whenever you’re developing.
As you’re developing out a method inside of a class, all of a sudden cyclomatic complexity errors start to throw and then you have a yellow warning error. Try and get that back to green before you start to develop new features. Or maybe as you’re building out your initial class from an M1 to M2 extension, before you even start to put those different platform approaches into your new M2 extension from the tool, get everything to green. Make sure everything is proper. Make sure it’s proper according to the PHP standards, according to the general coding standards of PSR1 and 2, the ECG Code Sniffer standards, all of those different standards.
Make sure everything is green before you start to go too far in one direction, because the age old adage is later never comes. “I’ll get to it later. I’ll fix it later. I just need to get this out the door. I’ll fix that part later” — later will never come. The standard garbage in, garbage out philosophy will still apply, so always make sure you’re always trying to get to green whenever possible, as frequently as you can.
And the last one that I always recommend is leverage the framework, and when I say the framework, I am not even talking about Magento here. Always leverage the framework that you have available to you. In Magento 2 instances — in the Magento 2 instance, it is it the Magento framework. The Magento framework is actually a really amazing framework when you start to dig down deep into it. There are a lot of really great features that are already built into it, as well as all the other Composer dependencies that were required for the M2 platform. You can use all those as well.
The need of writing low-level functionality in PHP, especially in M2, has really gone to the wayside because it has already been written and encapsulated into the framework. The Magento framework has a lot of really great features in it, and I encourage you to just take even a little bit of time and really explore that.
If you’re porting over an M1 extension, or even if you’re starting fresh and you have something that you need to do, figure out if the framework already does it first. You could save yourself hours of coding time by just doing that. So you don’t necessarily reinvent the wheel when it’s, literally, sitting right next to you. Instead, just use what’s already there, and that way you can greatly expediate your development time.
All right, so let’s go up with a — let’s start to summarize here and talk about everything that’s involved with this setup. Now, remember, this is only the first part of our series. We’re going to have a part two, where we actually take all the stuff that we talked about and start to apply those to real development, and then going through and actually submitting to the Marketplace, finding out what common errors are, seeing what that turnaround is, looking at those manual interventions and really getting that type of feedback in part three.
But as a summary for today, what we want to say is basically you need to make sure your extension has value. There’s no sense in spending anywhere between 10 and 160 to 200 hours developing an extension just to find out that two dozen of them already exist and there’s no need for it and then Magento just rejects it, okay, so make sure your extension is actually providing something and it has real value, that there is a need for it on the Marketplace. Go through that Marketplace, look through it, find out if your extension does belong there.
Prep your environment for development, don’t just set up a generic environment and start running with it. Expediate and lessen the amount of headaches that you’ll have by prepping your environment for development. Don’t make it so it runs really slow. Don’t make it so that it’s you’re not knowing exactly what errors are being thrown. Get your environment ready for development, and make sure you’re using the right versions that are going to be used against the Magento 2 platform.
Leverage tools for faster development. Leverage those tools that are already available to you so you can cut your development time down. There’s no need in starting from absolute zero whenever you’re developing an extension. Leverage the tools that are already available to you. Make your development time faster — iterate, turn over quickly, make sure that you have something that’s high quality, that you can work with in a shorter period of time than if you were just starting from zero.
And of course, obviously, if you’re having any trouble, InteractOne is always here to help. I always like to throw that in there as well. But if you do — in all seriousness, if you do have any questions or you are having any trouble or just some general recommendations about a specific tool or setup or route, don’t be afraid to reach out to us.
Okay, so that is all that we have right now for the setup portion, and we wanted to save time here to really answer any questions that you have about the setup process as well as anything else that you might have in regards to setup or extension development. And with that, I will turn it over to Amanda.
Question & Answer Session
Amanda: Awesome. Thanks, Ryan. All right, our first question here is what are your recommendations for how to promote my extension?
Ryan: Well, you are our marketing lady, so you might be better able to answer that than I actually can, so —
Amanda: Sure.
Ryan: I have some, but you can answer it if you want.
Amanda: Yeah, I mean, we recommend blogging. Blogging is always great for SEO and getting your name out there. Obviously, using Twitter, reaching out to the Magento community. The Magento community also has their community page that Sherrie Rohde runs, and she’s great about getting things out. And reaching out to your existing network is also really great. Okay, our next question — is it more difficult to create extensions for Magento 2? If so, how much more difficult?
Ryan: That’s actually a really good question, because one of the things that was mentioned at the 2015 Imagine was the amount of time it was going to take to develop an M2 extension versus an M1 extension. So when they first talked about making an M2 extension, the very first time you’re going to do it, it would be around the equivalent of an M1 extension plus an additional 50 percent, because you need to learn about the nuances of the platform and kind of make those mistakes and go over those stumbling blocks and really get intimately familiar with it.
And then they said your second extension would be around an M1 extension plus 25 percent. You’re getting a little bit more familiar with the framework, you’re getting a better idea of what things are, but it’s also — it’s a lot better for — you’re getting a much, much better handle on the M2 framework.
Now, the third extension that you’re going to be making will be less than an M1 extension. The framework and the M2 platform is actually really, really good to develop against. It’s very fast to create your extensions and customizations and your enhancements. So I would, honestly, probably stick pretty close to that. I’ve always found that to be kind of true. My first one was the same thing, M1 probably plus 50. It took a lot of time to really get everything running the way it should. The second one, I was a little bit more familiar. The third, I was very familiar with it, and your M2 extensions do come out a lot faster.
So I would say, no, the — it is not — it’s not as much difficult, so long as you get to know the framework. After you get over the framework nuances and those initial humps, it’s actually pretty easy.
Amanda: All right. Our next one is how long does it take to migrate an M1 extension to M2 compared to initial development of the M1 extension?
Ryan: So I pretty much answered that in the last question, so I’ll basically reiterate it. I would say that it’s basically an M1 — when you’re doing your first M2 extension, it’s an M1 plus 50, second one is M1 plus 25, and then your third one is going to take less time than an average M1 extension. So you’re looking at basically you need to put a little bit upfront time in ahead of time to do the first two, and then after that, it gets pretty streamlined and you can kind of churn out those extensions with relative speed.
Amanda: Okay. We have how long does it take — how long does it currently take to get a new extension approved for the Marketplace?
Ryan: Well, that’s interesting, because right now, since the Marketplace is new, the queue is kind of long. The last that I heard — and granted, this was a couple of weeks that I heard this — is that it’s currently taking around three to four weeks to get an extension approved, but that’s because a lot of extensions are now coming into the Marketplace and they’re kind of getting bombarded at this point, and so because of that, it’s — the queue time has got a long turnover.
Now, Magento is working on that, and they are, obviously, trying to get that extension approval time down, but since it’s so new, you just — you’re, unfortunately, just going to have to bear with them and try and lessen that time just — like I said, just got to kind of bear with them until that time starts to come down a little, wait until some of those — that bottleneck kind of gets out the door.
Amanda: Okay. Well, I think that wraps up our questions. All right, so don’t forget to sign up for part two and part three of our summer webinar series. Part two is June 8th, at 2:00 p.m. Eastern, and part three is July 13th, 2:00 p.m. Eastern. You can go to interactone.com/webinars, and you can sign up for both of those there. And thank you so much, Ryan, for joining us today. If you have any other questions, email us at support@interactone, visit our website, Tweet with us, anything you want. And we thank you so much for joining us today, and we hope you have a good rest of your day.
Ryan: Thank you very much.