You’re looking at this correctly. This is a big issue with all package managers, node and others suffer from the same kinds of issues. GitHub has dependabot that will routinely scan for vulnerable packages, and you can do similar things on your own to try and mitigate the risk. There was a suggestion about using something like Symphony where it doesn’t draw from as many dependencies. This seems like good advice, but it might be going too far as I work with projects with much higher package counts and they are considered secure. Still, it’s worth thinking about and especially when picking frameworks and libraries it’s important to think about where you’ll be down the line when you circle back around and need to upgrade it all. It’s not necessarily about the number of packages, it’s more about if those packages are well maintained and have continuity through an upgrade path as they release new versions.
Doug Hatcher
Enterprise architecture and tech junkie
Conceptually it’s the same thing - there was even an Admin interface for installing extensions at one point. Packages can be installed either via composer or through a “manual installation” which is just like extracting a zip in the right directory. The considerations are similar to Wordpress too, which is to say that if you install an extension but modified the themes then it’s possible the extension won’t present correctly and will need to be fixed.
That’s what the developer is likely accounting for… you install the module, test it… realize one of your changes has surpassed something or there’s a latent incompatibility and you have to address it first. In a Magento world, we typically do things locally, then to a series of integration and staging environments before finally deploying to production whereas with Wordpress folks often make their changes on the live instance.
The Magento-focused hosting providers are worth their weight in gold if you don’t have real server experience. Magento can be hosted on any cloud, but as others have said there’s a lot of esoterics and if you don’t know them well you’ll surely regret it
It’s hard to articulate just exactly why people should avoid Amasty but DRM is a pretty hard line you should never cross in a PHP project. It’s just not necessary, and it speaks volumes to their intent as Adobe and the broader community would come to their defense if their good work was actually stolen by other vendors.
I’m partial to devcontainers, personally.