Unless it got significantly better/redesigned in the last couple of years, Magento is a piece of junk.
Arguably it's been years since I worked with it, but installation was weird, developing is slow a cumbersome, documentation was lacking, search was pretty much broken and it was slow. I can't image running it on a shared host, performance must be terrible.
On the positive side Magento does have an impressive amount of features.
Its performance is so scant one must cache it to oblivion. This is especially true when you hit a certain high SKU threshold. Not to mention the horrible modules that are out there in the market.
Plug: Had to write a full page caching mechanism that's powered by Varnish (dubbed Magento Warp - http://www.unixy.net/varnish/ ).
I did the ops-side of a large Magento site. It was a fucking nightmare... and I handled .NET and Java once too.
We had 3 cache servers with 128GB of ram EACH just to cache the complete shit out of Magento pages. Each user had their own keyspace in the cache. _that's_ how bad Magento is.
When cache would go down because of a network partition or something, Magento would fallback to rendering and our application web servers would melt.
Each user... So one for "not logged in" and one for each known id? That's the laziest possible implementation that can provide any variety of benefit. Caching on a per-actual-visitor basis is just a waste of ram.
Fwiw we partial view cache on our platform and achieve a 90%+ hit rate on most sites. Some run many user-variable-specific (referrer,cookie,stored data) site versions which drops the cache hit rate, but is worth the extra cpu and cost for the conversions. Little performance hit as the object data to render is already in memcached usually, pre-warmed by queued parallel processes.
Of course, we evolved this in response to "oh crap the web tier is burning", but I just can't comprehend how magento haven't come up with something better than what you describe. Perhaps they haven't experienced the pain of clients bearing down hard on you while Rome burns first hand, and don't understand the importance.
Their answer was "oh shit, EAV is cool until it sucks, lets make flat tables".
Those flat tables really don't help much... (just profile the a request made to them and you still see the insanity that kcachegrind can generate).
They also didn't think about stores that have a lot of attributes. We had over 650. That means we had MySQL tables with 650+ columns.
Then there are SKUs. We had hundreds of thousands. Now there are HUGE tables with LOTS of columns that needs to be indexed on a regular basis because products and more attributes are being added. Reindexing takes hours.
Magento is a mess and that's all I have to say about it.
The sad thing is that they learned nothing from oscommerce. Yes, it's not a procedural pile, but it suffers from the same "can't implement sensibly. Fuck it, edit core. Patch?! Shit. Upgrade path broken" phenomenon in heaps.
If I got paid every time someone ditched magento because it doesn't perform, is hard and costly to host/maintain, gets blind alley'd by "someone else's problem" developers, can't do what they need, I'd be a rich man.
There are a large number of jobs for Magento developers in my area right now, some of them are really interesting companies. Sadly I won't be applying because I can't see myself doing Magento again. Maybe I should apply and talk them out of Magento, so I too can become a rich man :-)
And that's the gap between "supposed to" and "need to". So instead we cobble a pile of handcrufted PHP to work around its gross defects, given that maintaining our own patchset is making an even bigger rod for our own backs than running Magento itself is.
The team has been working on a rewrite "Magento 2" that should alleviate most of the complaints of the original Magento and adopts PHP development best practices (composer, etc).
I also asked them to clarify the versioning scheme[1] specifically related to patches, etc. It sounds like it should be better, but it's hard to tell at this early stage.
They've also taken a radically different approach to documentation with Magento 2. [2]
While it could be better written, that's just their installer, it doesn't run in production by its very nature so might be a low priority for coding standards.
If you wanted to call them out, at least call them out for something which actually runs during normal operation.
"All directories have 700 permissions (drwx------).
700 permissions give full control (that is, read/write/execute) to the owner and no permissions to anyone else.
Okay, let's me phrase it this way then. It's a big piece of weird code that isn't intuitive at first but become relatively easy to work with once you understand what's happening (give up on the why, half the stuff makes no sense). The current version is going to crumble, but hopefully Magento 2 will be built to last.
Not really accurate to say that Magento is "built on top of... Zend." We don't use much of it.
Regarding the crumbling comment... well, Magento is seven years old. There's a reason we're releasing Magento 2. Code's on GitHub, PRs welcome: http://github.com/magento/magento2/
Commerce is hard. Making an extensible commerce platform for all/most merchants is even harder. These two reasons are why there aren't a lot of options in the open source PHP-based eCommerce application space.
Redesign (Magento 2) will be released in Q4 of this year (2015). Beta code is available on GitHub and we are accepting PRs: https://github.com/magento/magento2/
> installation was weird
How was installation "weird" when you were using it?
> developing is slow a cumbersome
Speed of development depends on knowledge of architectural conventions, not unlike getting started with Symfony, Zend, Laravel, etc.
> documentation was lacking
I started building Magento projects in 2008. Documentation was non-existent for a long time (unfortunate given the esotericism of the app). We're solving this for Magento 2 by having tech writers on staff and by soliciting community help (docs are also on GitHub, PRs accepted): https://github.com/magento/devdocs
> search was pretty much broken and it was slow
Search and newsletters are insufficient for anything but the most basic needs. That's why there are so many SaaS search vendors filling this space quite well via free extensions.
> on a shared host, performance must be terrible
Shared hosts are never appropriate for commerce sites due to security reasons. There are a number of specialized small business hosts which run < $50 / month. For shops lacking that budget, well, there will be challenges in general.
Considering their apparently sorcerous power to get the money people to sign cheques, I really wonder what the hell they do in the sales presentation for this pile of rancid garbage.
Admin and developer of two Magento based sites here.
Magento has just started posting notifications of these vulnerabilities in their notification center. They sent two messages. One on April 16 and another on April 19. See images of message here http://imgur.com/a/edVGy they did inform us that a press release with the vulnerability was coming.
That said I am annoyed that the patch was from February 2015 and October 2014. If you do not go to this page https://www.magentocommerce.com/products/downloads/magento/
on a regular basis there is no way that I know of to get same day notification of new patches.
One extra note for those who may run their Magento install on a shared host.
You will likely not be able to use the patch as is. It is distributed as .sh file that requires SSH and permissions that are not available on most shared hosts.
This is a serious shortfall of this patching method. You should create a trouble ticket with support and they should be able to run the patch scripts for you.
I agree for the most part here. But it's not totally insurmountable. Patch against your local development and/or staging copy then upload the changed files to your shared host.
Dutch's largest Magento hosting company Byte released a online testing tool: shoplift.byte.nl
Btw, see the comments section in Mattias' blog post, you will see that Magento themselves admitted that they have "no automated tests" whatsoever. And 2+ months out, they haven't bother to updated the latest code release with the new patch in.
Do you still trust Magento stores on the Internet? I don't.
We run some shops at Byte and were able to quickly apply the patches back in February. This week we got an e-mail from a worried customer who got a message in the back-end (from Magento) that his site might be vulnerable: 2 month's later..
Personally I've never liked Magento much; it needs expensive hosting even for modest shops and seems to be bloated with functionality you never use. And in the end you always end up with writing a bunch of custom modules because the Magento way is never your way.
"Dutch's"? I assume you mean the Netherlands since Dutch is the language, not a country or anything. This would be the same as saying "English's largest Magento ...". Alternatively you could say "The largest Dutch Magento ..."
> It boggles my mind why Magento would willingly distribute unsafe code this way, assuming users would just find out to download the patches separately.
Because Magento are OBSERVABLY INSANE.
This is from the Magento Enterprise tarball. I can't say how much we're paying, but I can say it's public knowledge that it's at least $13,000 a year:
The first two are a third party module. If 0777 is objectionable then I'm surprised you are using the module or haven't at least patched it - not trying to snark, just wondering if there's some additional context.
There don't seem to be any specific vulnerabilities related to these permissions, though I'd like to see them go away. It's my understanding that 777 will not exist in Magento 2.
As I said: Magento Enterprise tar ball, supplied at considerable expense straight from Magento. Magento bears full responsibility for the contents.
You really seriously just don't have any excuse for this sort of thing.
> There don't seem to be any specific vulnerabilities related to these permissions, though I'd like to see them go away.
Only someone working for Magento could claim 777 is ever not a hideously terrible idea to have in the webroot of a PHP application. This is frankly insane behaviour. It's like running applications as root in the general case and saying "well, we haven't found a vulnerability yet." YOU REALISE PEOPLE PUT REAL MONEY THROUGH THIS THING.
> It's my understanding that 777 will not exist in Magento 2.
> As I said: Magento Enterprise tar ball, supplied at considerable expense straight from Magento.
Is this a download from the partner portal? I've asked support to check, but you can probably point out the source much more quickly than I can track it down.
> Only someone working for Magento could claim 777 is ever not a hideously terrible idea to have in the webroot of a PHP application
I did not make this claim. I stated that I wish it were not there. It's not necessary, as the kinds of environments in which 777 are necessary are a problem unto themselves. These instances are borne of legacy concerns which pre-date my arrival to Magento by 6 or 7 years. Pity they were not patched before now
Have you ever filed a bug report for this issue? I can imagine you might say, "I shouldn't have to," (and I agree), but it's remarkable what even a single ticket can do.
In general, it's unfortunate that Magento 1.x development and bug tracking are so... internal. In contrast to the visibility and interaction present at https://github.com/magento/magento2/issues it's clear that everyone is better off. Of course, we have to consider how to have the same kind of open dialogue for Enterprise Edition, and we're working out how to do that. Would you care to participate in a private GitHub repo, or can you suggest some other medium? Really, neither you nor I should have to spend time writing about the 777 issue - an open dialogue would likely have led this to be fixed years ago, so we could spend time bemoaning & fixing other issues!
Regardless the way Magento releases the patches, the most annoying thing is hiding them behind the login form, making it impossible to apply from the console. You can install Magento via SSH, but you cannot apply security patches the same way - I am not able to understand this. I know, there's a business behind this, but open source in Magento meaning is somehow strange.
There's been 10 patches (2 with remote code execution exploits) and no version bump. Are they trying to make it seem like their product is more secure or stable by not incrementing the version?
Where can one find analysis of this vulnerability? There are no details in checkpost blogpost revealing vulnerability. I assume its serious and real if magento releases patches but would be cool to be able to judge myself.
This is hardly unique to Magento. Lots of applications do this. It's not ideal, but it's not SO bad if the application nags you to patch on start up. I don't use Magento, so I'm not sure if it does.
What's bad is that it's so easy to fix. It's the distribution platform for software. Shouldn't there be lots of interested people that could take 20 minutes and write some software to fix this problem?
Joking aside, they are going to release 1.9.2 soon. For Magento 1 they're still doing feature releases, and they do patches for everything else because store owners do not like going through the upgrade process.
The only problem arises when people download fresh versions.
It's the wordpress problem; Magento has made e-commerce accessible to anyone with a shared webspace and the minimum of knowledge (speaking as someone who's company integrates with small businesses who use Magento). So it's very easy for things to get out of date.
(or even worse; one-click installers on some shared web host... so they can't update it even if they wish!)
That alert is shown because Magento issued a notification message, not because the system detected some security patches. Those two security patches were published on 2015 February 09 and 2014 October 03.
In fact, Magento issued two notification messages, on Friday and on Monday, so even if you applied the patch after seeing the first message, you still saw the second message and experienced that brief moment of panic.
Would anyone be interested if I were to host a maintained fork of the Magento community edition on github with up-to-date security patches so you can just `git pull` and be done with it?
The only problem with that is you have to fork off that for your own Magento site and it basically doesn't help anyone that doesn't already know what they're doing and patch right away already. :\
They vary; generally, their maintainers mean well but that doesn't necessarily translate to secure code.
Cake lacks security expertise in their core team, unfortunately.
CodeIgniter is a bit conservative. (We must support PHP 5.2!) But then again, so is WordPress. They do listen to researchers.
Laravel is okay, but their lead dev is a bit of an egotistical and hypocritical ass. Recently, found and privately reported a PHP Object Injection vuln to Laravel; he said he didn't consider it a security issue, then when I disclosed publicly flipped his shit on me.
Symfony is great. Fabien has a cool head and responds well to security researchers.
Yii 2 is promising. I'll have to take another look before I call it bulletproof though.
My only experience with Zend has been interacting with their core devs on other media (Twitter, IRC); I haven't found any bugs in its core.
I'm out of PHP, but I'll second Symfony - Fabien and the Sensio people are the best folks I know in the PHP universe and they're careful and sober in their thinking.
Yes, but I originally emailed that address so I don't think it was a reaction to me (or even a passive aggressive gesture). Taylor had a week's heads up and chose to dismiss my report.
I don't see the big fuss here if people are warned, either as the main package is downloaded or in the post-install configurations screens or in the admin screens, or ...
It comes down to how much time they can afford to spend on release testing for the OSS edition. They have tested the main release extensively, and have tested the patches too, but haven't had/made time to roll together a new full release and explicitly test that so continue to go with "install X, apply patches Y, Z, ..." as the process for new instances because that has been tested.
Full release regression testing can be a long-winded (and therefore potentially time expensive) process. Maybe people who have a problem with the current install process could club together and donate enough to make that worth while doing before the next planned full release...
(of course that is moot if people aren't warned adequately)
Arguably it's been years since I worked with it, but installation was weird, developing is slow a cumbersome, documentation was lacking, search was pretty much broken and it was slow. I can't image running it on a shared host, performance must be terrible.
On the positive side Magento does have an impressive amount of features.