Live data from Hacker News

Magento eCommerce PHP Remote Code Execution

ma.ttias.be

61–70 of 81 posts

Re: Magento eCommerce PHP Remote Code Execution

#61

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…

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 nee…

But you're not supposed to edit core, you extend it.

Re: Magento eCommerce PHP Remote Code Execution

#62
post #58

Earlier quoted context omitted.

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 nee…

It really isn't that difficult to avoid core updates. Sure, it isn't a perfect platform, but it gets the job done for most eCommerce companies

many things "get the job done", but it's the nature of that "job" and how much effort it takes which is in question.

Re: Magento eCommerce PHP Remote Code Execution

#63

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…

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.

Re: Magento eCommerce PHP Remote Code Execution

#64
post #61

Earlier quoted context omitted.

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 nee…

But you're not supposed to edit core, you extend it.

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.

Re: Magento eCommerce PHP Remote Code Execution

#65
post #18

Earlier quoted context omitted.

Magento code in general is of very dubious quality. I once ran a quick static analysis on it and found some ridiculous results: https://twitter.com/jlas_/status/391615992473722880

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.

Whoever wrote Magento thinks 777 permissions are ever the right thing to do.

Every book I've ever seen on Magento seems to think the same. That 777 permissions are just not a big deal.

Re: Magento eCommerce PHP Remote Code Execution

#66
post #16

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…

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 wit…

Are they still taking the "lucky sevens" approach to file permissions?

Re: Magento eCommerce PHP Remote Code Execution

#67
post #35

Earlier quoted context omitted.

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 se…

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 w…

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.

Re: Magento eCommerce PHP Remote Code Execution

#69

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 explici…

A downvote with no explanation just tells me I've got on your nerves and you aren't mature enough to discus it openly.

If you think I'm genuinely wrong please educate me rather than hitting "downvote" and running away...

Re: Magento eCommerce PHP Remote Code Execution

#70

Earlier quoted context omitted.

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.

Whoever wrote Magento thinks 777 permissions are ever the right thing to do. Every book I've ever seen on Magento seems to think the same. That 777 permissions are just not a big deal .

From http://devdocs.magento.com/guides/m1x/install/installer-priv... :

"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.

"All files have 600 permissions (-rw-------)."

Post reply on HN