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.

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.




 

Magento 1.9.x with php 7

Now its definitly time to get in touch with Magento 1.9 and PHP 7 to the promissed performance enhancements.

After installation of PHP 7 and Inchoos` compatibilitymodule I was definitly impressed of the PHP 7 performance.

All the benchmarks from earlier days I read are direktly visible on pagerendering.

Lets install PHP 7 and play arraound with Magento 1.9.x


Download and Install Magento 1.9.2.2

The process may take up to 10 minutes for creating database tables.
Take a cup of coffee. 

Download Inchoos' Compatible Module fom
https://github.com/Inchoo/Inchoo_PHP7

- extract Package
- move app folder to your installation
- clear cache

Have fun surfing superfast Magento 1.9.x without extra caching.

Funtastic

Setup gitlab on ubuntu in 5 minutes with docker un ubuntu 15.04

Yesterday my virtualbox image on my external usb harddisk crashed and I quickly needed a new gitlab VM. I remembered my installation process last week, which tooked nearly an hour for a simple baseinstallation.

I didn't want to wait for a 2 h Vagrant imagedownload, so i decided to give docker a chance.

Docker on ubuntu 15.04 was installed in minutes.

1) Update ubuntu repos

Commandline:
sudo apt-key adv --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv-keys 58118E89F3A912897C070ADBF76221572C52609D

Open and add: 
sudo nano /etc/apt/sources.list.d/docker.list

Add
deb https://apt.dockerproject.org/repo ubuntu-vivid main

Save the file

Update your ubuntu
apt-get update



Install Docker
sudo apt-get install docker-engine

Start Docker

sudo service docker start

Pull gitlab on docker from docker hub

docker pull sameersbn/gitlab:8.2.0 

Download docker composer
wget https://raw.githubusercontent.com/sameersbn/docker-gitlab/master/docker-compose.yml

Generate gitlab secretkey 

apt-get install pwd

genpwdgen Bsv1 64 
 

copy generated string an open downloaded docker-compose 

nano docker-compose.yml

search GITLAB_SECRETS_DB_KEY_BASE and set the generated secret

Install docker-composer

apt-get install docker-composer 

start gitlab composing

docker-compose up

Point your browser to http://localhost:10080 and login using the default username and password:

• username: root
• password: 5iveL!fe

 
 

Composer: checkout gitlab repo

I took a while to findout how to clone a external gitlabrepository via composer in a project

if your repository is available via git + ssh you have to create a  ssh key 

follow this link to do so
https://help.github.com/articles/generating-ssh-keys/

at next you have to add your ssh key to ssh-agent
exec ssh-agent bash
ssh-add ~/.ssh/id_rsa


 
composer.json in the root of your project

{
"repositories": [
    {
        "type":"vcs",
        "url":"git@gitlab:root/testproject2.git"
    }
],
 "require": {
        "peter1/peter2": "dev-master"
    },
"target-dir":"test"
}


peter1/peter2 = name of the repository in composer.json of repo you want to clone
target-dir = name of the directory in local folder "vendor"


the project you want to clone via composer needs a composer.json too.

{
    "name": "peter1/peter2",
    "description": "My New Project",
    "authors": [
        {
            "name": "Peter Böthig",
            "email": "mail@mymail.com"
        }
    ]
}

Magento2 constructors are not realy fair

This is the constructor of
Magento\Customer\Model\Address 
I know there are some disadvantages in usage of DI-Container. But a good architecture allows contextbased DI-Container, to prevent this kind of constructor mess. It could sound oldschool, but more then 3 parameter in a constructor is smelly.

This constrcutor contains 18 Parameters.

7 of the parameter are factories. I think its a good idea, to group the factories in a dedicated factory-di-container.
2 of are configobjects
2 are registries
1 Service

and so on.

Thats realy hard to learn and to refactore, if you have to change somethig in there.

What is best practice to prevent that?

Magento 2 generate new module the rapid way. Part I

Yesterday i was looking for the fastest way, to generate a module with an own entity, admingrid, editforms for the adminbackend etc.

In the past I have used UMC Module Creator for fast prototyping to bringup services rapidly. And I realy liked it on Magento 1.9  On Magento2 the UMC project ist still under heavy development, but the first results are very respactable. Some things are not available at the moment, but the mainfeatures of generating Models, Grids, Adminhtml are.

With this modulegenerator you are able to generate your Entitymodule in 20 minutes.

Lets start:

If you dont have a valid magento2 installation you can use my last install tutorial:
http://magento2-tuts.blogspot.de/2015/11/first-steps.html

At first I had to create a codefolder inside your magentoroot/app folder

 mkdir -p /var/www/html/magento2/app/code/Umc/Base  
 cd /var/www/html/magento2/app/code/Umc/Base  
 git clone https://github.com/UltimateModuleCreator/Umc_Base.git  
copy -fr Umc_Base/* /var/www/html/magento2/app/code/Umc/Base  

 This creates a folder Umc_Base with all the "good stuff" in it. You dont have to take care of registering the namespace, directory and all kind of that configuring stuff. Its all predefined. At the moment its not possible to store your module in the vendor folder. The magento devs will bringup this option later, as I can read in protokoll of a websession with devs and architects earlier this year.

After that you have to enable your extension on the new n98magerun based cli-tool

 cd /var/www/htm/magento2/bin  
 php magento module:enable Umc_Base  
 php magento setup:upgrade  
 php magento setup:di:compile   

the first cli-command enables the module.
the second one is neccessary to upgrade your database structure
the last command compiles the codebase and generates the output.

After that you will get a coreexception of a missing token. This seems to be a bug in Magento Core. You can ignore it for this time

After compiling you have to set your filesystem accessrights new, because the compiling process overrides it.
chmod -R 755 will do the trick (Do not use 755 in production)

 php magento cache:clear  

will clear the cache.

Now you can login in adminarea under
http://magento2.local/admin

A new mainnavigationpoint will come up "UMC" at the bottom of the navigation

After that the usage is almost selfdescribing.
Use the "new module" Button to get in the configscreen.
The formular helps you to get on it.

You can setup your namespace, version, companyname etc. On every field there is a helpfunction to get missing information.

After you have setup your entity, attributes etc you can save the module for downloading it.

Download your zippackage and unpack it. Copy the modulefolder unter
/var/www/html/magento/app/code

At last repeat the step to activate the module, like I descriped some minutes ago.

If everything worked fine, you should now have a new menupoint in the mainnavigation where you have defined your navigationlink.

If you open it you can directly see your new entity with all the known function
- editing
- inlineediting of a row (cool new stuff)
- exporting rows
- massactions
- deletes
- a searchfield with lucence support (new)

My module is named Workflowtask_Task. With that I can an any external workflowengine  to handle usertasks.

But lets see, what code was generated.

Here is my structure of the new module:

I do not want to explain much about the known structures. Most of the things seems to be similar to Magento1 with "little" architectural changes.
Even if these little changes are breaking all backward compatibility for all Modules you have used in the past, which is realy realy annoying and painfull to rewrite. Lets give Magento2 a chance here to have a deeper sight.

Controllers

As you can see all controllers now have only 1 action.  But for the moment I couldnt care less. As a magento2 developer you now have to setup a complete controller for each action.

Alan Storm says

In Magento 2, each controller has one, and only one, entry point. That’s the execute method. This is a step Magento 2’s architects took to help avoid conflicts with a large development teams all editing the same controller file for different features. 

That might be a good reason for that.
http://alanstorm.com/magento_2_mvvm_mvc

A very good deep view of controllers can be found on inchoo
http://inchoo.net/magento-2/magento-2-controllers/


In Part II we will show, how models, routing, di and template definitions are structured.

Thanks for now