-
-
Notifications
You must be signed in to change notification settings - Fork 437
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove Magento Connect, Downloader and PEAR. #952
Conversation
should this be merged to the 1.9 branch or 20.x ? |
Iam undecided. |
Im ok with removing it as i never used magento connect nor pear in my projects :) |
Never used one of them .... so i'm okay with removal, but if you want to keep PEAR for now. Is it okay to update PR? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If there would ne no concerns about PEAR i'd approve ... ;)
Afaik PeAR is not supported by PHP any more. |
Is not possible to "rewrite" Magento Download to give users the same functions but updating "parts" of the system from OpenMage? |
@simbus82 @colinmollenhour @tmotyl |
Isn't magento connect for m1 not supported any more or will vanish in the next weeks? |
Although my opinion is currently that it should be removed (perhaps waiting until Connect is actually taken offline), I feel like I'm not qualified to answer the question as I don't know how others are using this and might use it in the future. Whenever I wanted to install an extension from Connect I'd just download the zip and then manually convert it to a modman directory, so I'm not the typical user. 😁 The pros:
The cons:
So, @simbus82 can you describe how you see this code being important to keep after the EOL date? Does keeping it outweigh the pros in your view? |
No, i'm an optimization addicted, so if it were up to me i would kill so many useless parts of old Magento 😄 @colinmollenhour But i'm in the middle of development and web project management (SEO and CRO), so i try to take all "real users experience" to the "software level". Until today many merchant's "developers" updates magento with the GUI (Magento Downloader), same for packages installation, with the uploader GUI. Since 1.9.3.x it works very well, not as in the past. If tomorrow can't be used because Adobe is going to kill the server that push Magento 1.x core packages, i'm with you! Let's remove this useless code! I'm just a little concerned about the ease with which non-developers in the past could download and install a .tgz or .zip without even opening an FTP client. I like a lot Modman and Composer, but since they are managed only from the command line, they will be complicated to use for some merchants (or is it just my inexperienced impression?). I fear that a Merchant who uses OpenMage is a merchant who does not have the budget to embark on the migration in that Magento 2 tank, so it is very likely that these merchants are flanked by inexperienced developers ... or they are doing some "amateurish devops". Obviously the best solution would be to remove all this stuff from the old Magento like you say, and put a simple GUI to install the "core updates" and "extension packages" in the backed area... It is also true that soon there will be very few updated Magento plugins that we can install ... 🤔 |
As far as I know, the direct downloads for packages were still usable for the connect downloader. But I think the update functionality (automatic listing of packages needing updates) was not working anymore for over a year. |
Thanks for the insights, guys. One thought that might be a compromise between remove and keep would be to remove just the GUI and keep the CLI. The CLI code, as long as it is protected properly, is much less susceptible to attacks (you need shell and write permission to use it so you're already screwed). I understand the desire to have one-click install capability but to me the ability to download and write source code all through the web UI is too dangerous. That said, if realistically the CLI will not be used then I still say remove it all. :) Is there a project somewhere for Magento 1 which allows a user to install a Magento Connect package via "composer install"? |
This screenshot is taken few minutes ago from an abandoned Magento 1.9.2.4 😝
Yes, too dangerous, because sometimes things are breaking easily!
CLI and command line are "same thing", so it is useless to maintain a CLI 😅. Let's remove it!
Maybe this? https://github.com/AydinHassan/magento-connect-composer-plugin |
Good example, I dont know if there is a newer Release, but it is one from before they cut off the connect releases. I crawled everything which is available, and noticed there is a date, from which on no new releases did appear there anymore. |
So remove, but after how-to's are updated for the following?
|
@colinmollenhour @Flyingmana |
@daim2k5 Can you clarify what you are referring to by "i wrote the update script for the 'Firegento package repo'"? |
I vote for removing download and connect, I always manually deleted them from all the projects I've worked on and I'd never allow a backend user to update a module or anything else :-) |
will execute the removal now for current reasons, as security comes first:
we need to look into alternatives or partial reversal afterwards |
Finally! I also remove downloader in all my M1 instances. Finally, lesser inodes to use. 👍 |
.... remember #1160 ;) |
Looks like we successfully dodged a bullet... https://sansec.io/research/cardbleed |
Downloader was removed with #952 so it's useless to redirect to the downloader subdir. Also, I think the purpose of checkin if the MAGENTO_ROOT . '/app/Mage.php' is useless, one file check for every request while magento wouldn't work at all if it didn't exist, I think that check has to be removed, there's no point in executing it.
Fixes #903
Only lightly tested.