Dieses Blog durchsuchen

Sonntag, 17. Januar 2016

why magento composer realy realy is a bad idea and why it sucks

Does anyone who worked with magento and comes from the php-world know a wired thing named "Magento Composer" and thought WTF is this for a piece of crap?

And why are there hundreds of people running arround an say "The only way magento is professional handled with composer" ? Do they really work with magento in daily business? Really?

Here are some facts why you please never ever use this shit in your enviroment.

- composer itself does not work with magento because composer needs a "vendor" directory on wich it puts the downloaded sources in it. Thats PSR-0 -4.
Magento has a completly onther directorystructure. There are definitly no possibility to handle packages with composer itself.

- If you want to use composer as a package manager you have to use a second packagemanager named "magento composer". Now you got a wired stucture by using a packagemanager to use a packagemanager. If you have a Jenkins buildsystem based on ant and ivy you even have a packagemanager that uses a packagemanager that uses magento composer as a packagemanager. Who wants to spend hours and hours by configuring this shit.

 
But why is everyone a stupid idiot and a beginner if he doesn't want to use this crap?


Because I fellt like. "Oh I come to developer hell if I do not use composer in my magento-projects. And the "Angels of Death" of PHP-FIG, will put me into completly darkness." I gave it a try.

Installation
At first you have to enable phar in PHP. Thats the first problem. Everyone knows the projects on which the customers have an own hosting and you can't install what you want. php5-phar has to be installed to run composer. For some admins this can be an overkill. Please beleave me.

I have seen that ever and ever again.
At the moment there are servers down, because an admin have to install or recompile php with phar to run composer. That really sucks.
 
The contra, that phar isn't a standard php included library can be a desitionpoint to look for another packagemanager which doesn't have this impact in your stage / productionenviroment.

After you told the admins of your customer that they have to install lamp for magento, you know the problems with this kind of people if they have to install php extensions. But after some weeks and thousends of emails all extensions are installed. Hu. Never install more extensions as needed on your customers servers, if you can't controll the server by your own. Every single extension can costs a lot of time if the admins got no glue of php.

If you now hammerd the admins to open the firewall, enable curl and let you talk with the internet you can install composer with.
In most cases the admin say something like "Oh I cant grant you access to the whole internet outgoing from this server. I can only give you access to the downloadurl". Fine. Some hours later, you have access to conposer.org. Sure you can upload the phar manualy. 

But that only works, if you can access /usr/local/bin. In most of high security installation you can't and so you have to ask the serveradmins again.

At next you have to create a composer.json file. The minimum configuration to get magento-composer installed is the following.

After that you can change to your magento-dir. But stop, running composer in the root dir of your magentoshop is a bad idea, because it creates a "vendor" folder directly into magento. That sucks. So you have to create the composer.json one level higher.

If you have installed your shop directly in /var/www and you do not have the rights to create folders in /www because only the www-data can or the admin, you have to ask the customers admin again to create the folder and move all shopfiles again. But that's not enough. Now you have to change the rootdirectory of your apache config. And guess what? You have to ask the kindly customer's amin again to change the path to your root.

Okay.  10 Tickets and 3 telcos later, you have some more grey hairs but you have  restructured your filesystem an now your composer.js is stored one level above magentos root directory.

- composer.json
  -htdocs
    - app
    - js
    - lib

 and so on...

Now you can open up a console an install magento-composer. That really was a kind of a hell.

But what the hell is going on now? When I look on my console I was shocked. I only wanted magento-composer as an extension of composer. But what is all raining down now.

Here is my console output, that displays the dependecies of magento-composer

The packages which come with composer install where never configured by me in the config.json. And I never was asked, if I want to install this additional packages.

I got all now on my disk without any prompt or check.  Not even the simplest security warning. That's really great.


Now I have to deside whether to put this additional libraries in my versioncontroll and have to talk to other developer. This is the last thing I want now. A librarydiscussion to add the magento-composer dependency to the core repository. Thatś allways a thing which can take a lot of time to be accepted. What if some of the libs already exist as artifacts in the projects?

"Wait a moment. We have Symphony already as a dependency in this backendcomponent. You have to use that instead of your own"

Or "You can simply open a share to this component. There we have one".

Or "No, we got a codesniffer with own rules. You have to ask the repo admin to setup an exception to push your dependencies."

Or "No, the libraries aren't unittested. Without tests the build will fail"

Now 3 other organisationunits come into the game and a wild shitstorm about the new dependencies will raise up.

Okay. Imagine you have solved all this kind of bullshit and now you have "magento-composer" running on you system. At that point you haven't installed even one of your own extensions. Now the best thing will hit you directly in the face.

As I read this sentence , I wanted to rampage something.

The one drawback of composer for Magento (so far) is that it doesn’t handle commercial extensions very gracefully. It would be possible to add a private repository and install from there, but that’s not a real solution. But at least the community modules and other external libraries are taken care of nicely!
 Source: http://magebase.com/magento-tutorials/composer-with-magento/

WTF is going on ? I can't use private repositories?

After googling arround I found the same articles again and again. It seems to be there thousands of copy of this article. Only changed in some words. Everyone talkes this bullshit.

"Hey, you know about composer? Composer is the new standard php packagemager, but wait. There is pear. isn't it? Yes. But pear is the devil, the packages are global"

All my businessextensions are stored in private repositories. How can they define a packagemanager standard only for communityusers and tell the whole wide world, thats now the industrystandard without think about commercial usages?

If you want to use Composer the concepted easy way you have to store your extensions on packagist.org. WTF is packagist.org? They really think i will store my businesscode on packagist.org and the next day I get fired because I publishes companycode in the whole wide world? But I can say. "The community sais so. Thatś new standard. I will never get a new job."

It's even getting better.

We have to use Magento-composer to composer running right? Composer needs the package stored in packagist.org. Magento-composer is from firegento.com. All Magento-Extensions have to be uploaded on packagist.firegento.org. Otherwhise it's not working, and so you have to setup workarrounds to use your own repositories.

WTF is firegento?

This is firegento.
https://firegento.com/

Some kind of wired to me.

But wait. That's not really the problem. I can setup a public repo in my save company gitlab which isn't accessable from outside. Good Idea! So I do not need to hardcode username and password in the composer.json. Noone wants that.

But after that I got Emails from the Repo Admins "You cant make that project public. Use internal projects with LDAP access or add your SSH-key to the project"

AAAARRRRRRRRGGGGGGGGGGG

Now you have to solve the authenticationproblem. So you have to create SSH keys and add it to your projectsources. And the cicle comes complete.

Talk to the other Devs, talk to the admins and ask for it. You can try to simply checkin the keys.... Have fun....

Otherwhise you can add all LDAP users to the project and send an email, that they have to type in username and password each time you want to update / install dependencies. What a piece of crap.

Okay. What about to store the dependencies not in gitlab? Why not put the packages in an artifact manager like Sonar Nexus. Great idea. Lets do it !.

But wait a minute. After googling arround I see. There is no possibility to use an Artifaktmanager. What kind of a packagemanager should that be? Not even a artifactmanager connector?

Common man, you can't be serios.

But the best comes at last.

After I got all runing after fellt like years, I run the command "composer install" and what do I found on my console:

- "/var/www/html/magento1.9.2.2/app/Mage.php was already patched"

What the holy fuck is that. Magento composer patches my Magento Core on my machine? It opens Mage.php and add this code

/** AUTOLOADER PATCH **/
if (file_exists($autoloaderPath = BP . DS . '../vendor/autoload.php') ||
    file_exists($autoloaderPath = BP . DS . 'vendor/autoload.php')
) {
    require $autoloaderPath;
}
/** AUTOLOADER PATCH **/


Have I give them my "Okay" to do so? Was I asked for it? Now your checksums will fail on the core files in your buildsystem. I don't think that varien are very amused about modifiing the core application of the product.

We tooked years to teach everyone "Do not ever make any change in the coreapplication of a third party lib. This will break up any updateprocess". And now, the funny people from firegento, who are teaching the same are modding the magentocore to setup a totaly useless pseudo composer extension?

OMFG.

Whats wrong in my little world. Everything i was beleaving is comming down......

So. Please do not use such kind of bullshit. This is the worst thing you can do.

But what about alternatives.

At the moment I play arround with ant and ivy. Sure it's from the java world. But that is PHP Storm too.

Ant needs java on the system. That can be a problem too. But it has not that ugly limitations like composer does.

Ant can solve dependencies on artifact managers like sonar nexus.  Which is the main-thing in handling dependencies on closed infrastructures.

Ant implements filesystemoperations out of the box. So you are flexible in handling your folderstructure. There are no PSR limitations or vendor folders.

Ant can run your tests.

Ant can publish your packages back to artifact manager.

Ant is easy to be integrated in Buildsystems like jenkins.


ANT is dead. Long live ANT.















































Freitag, 15. Januar 2016

Mage2 a clone of Petashop?

On my daily reserach for articles, that tell me, that magento realy sucks (from time to time I try not to loose my head and search for some jokes of frustrated devs like me and thousand others) I found a path to prestashop.

Read this for further alternatives
http://andrewbleakley.com/alternatives-to-magento/

On this article a link to prestashop was posted with a screenshot of presta.

At first overview I realy was crying loud. "Presta has stolen the new Mage2 Design" and I had to install it local to check, if they had "stolen" only the design.

After download and installation on PHP 7 without any problems or issues (presta is php7 ready) I could have a look on the code with my PHPStorm.

Presta is definitly much older than Mage2. Presta comes with smarty as templateengine. That was arround 2006.

After I logged into the adminpanel i fellt like home on Mage2

This is Mage2 Adminpanel





And this pesta

Nice isnt it. With some data in Mage 2 the Graph looks similar.


Not enough?

Here are the productlists
Mage2 productlists


And Here Pesta




And so on....

I must say, that I was really not impressed by the "new" admin backend layout.
The usability / navigation is much more complicated that in Mage1. I now need more time to open up popups and wait for Javascriptlayer, what was pretty good solved in Mage1.

And even if I now can edit rows inline, I do not want to miss a good managementarea in a shop like Mage1 was.

At the end I Think its allways a good idea to envolve Software to the next state of the art. And sometimes things get worst before they come good. 

But what was never a good idea  ist simply addapt a concept and think "It works".

Copycats are tricky.