Magento 1. Add custom Textfield with dynamic content in system.xml

If you want to add a custom textfield with dynamic content instead of static content from config.xml you can simply add your own data form element like this

place following class under
app\code\local\Varien\Data\Form\Element\YourCustomTextElement.php



At next you can use your custom form element in system.xml of your module like this. Place your new configvariable in your target field group

Setup Magento with Vagrant and Puppet as a local enviroment

You will say. Not yet another Vagrant Puppet Magento tutorial.
But I want to share my experience in that context with you.

After 3 Weeks playing arround with Vagrant and Puppet and hours of horrible config-hells in puppet I got my lokal dev enviroment smootly running.

Here is the result:
Lets bring it up running.

At first you need Virtualbox and Vagrant + Hostmanagerplugin

VirtualBox
https://www.virtualbox.org/

Vagrant
https://www.vagrantup.com/downloads.html
  
Vagrant Hostmanager Plugin
https://github.com/smdahlen/vagrant-hostmanager

I don't explain this 3 components here, that is a little bit off topic.


Lets start

1) Checkout the project:

$ git clone https://github.com/pboethig/vagrant_puppet_magento

$ cd vagrant_puppet_magento

$ vagrant up

After that the shop is running

surf to magento.dev

Thats it

Look into the console or read the readme for logindata

add a phpscript to .bashrc as an alias reboot save

Sometimes you want to add a phpscript to your linux enviroment, so that you can do something fancy on your shell console or even in a shell / bash script like:
ini-config -p all -a fancyparameter 

 The most common way to call a php script on the console is

/usr/bin/php /ugly/long/path/to/your/script.php -p all -a fancyparameter 

Noone wants to rember this path all the time.

The community tells me to put an alias in the ./bashrc. But that wont work, if you want to use your php script as a cmdtool in a shellscript without putting the path to the script in an echo like that:

echo "php /path/to/your/long/ugly/network/php/script.php -a all -p parameter"

You have to do some more.

The shellscripts become ugly and unmaintainable.
To get your phpscripts running as an alias cmdtool  you can just add an exportfunction to your ~/.bash_profile or ~/.bashrc and export this function instead of defining an alias, wich is deprecated, as I know.


now you can simlpy enter

fancyscript -p parametername

on your console.

The function in the ./bashrc is rebootsave, so, that you can use it after rebooting the whole wide world.

Vagrant 1.8.0 and 1.8.1 throws error on rsync folders

In version 1.8.0, 1.8.1 a rsync error occures.

There was an error when attempting to rsync a synced folder. Please inspect the error message below for more info. Host path: /cygdrive/c/ibrams/webroot/merck.magento.current/magento/html/ Guest path: /home/vagrant/www Command: rsync -avzO --delete --chmod=Dug=rwx,o=rx,Fug=rw,o=r --no-owner --no-group --rsync-path sudo rsync -e ssh -p 2222 -o ControlMaster=auto -o ControlPath=C:/cygwin/tmp/ssh.348 -o ControlPersist=10m -o StrictHostKeyChecking=no -o IdentitiesOnly=true -o UserKnownHostsFile=/dev/null -i 'C:/ibrams/webroot/merck.magento.current/magento/.vagrant/machines/default/virtualbox/private_key' --exclude .vagrant/ --exclude .git/ --exclude /media/ --exclude /var/ --exclude app/etc/local.xml /cygdrive/c/ibrams/webroot/merck.magento.current/magento/html/ vagrant@127.0.0.1:/home/vagrant/www Error: Warning: Permanently added '[127.0.0.1]:2222' (ECDSA) to the list of known hosts. mm_receive_fd: no message header process_mux_new_session: failed to receive fd 0 from slave mux_client_request_session: read from master failed: Connection reset by peer Failed to connect to new control master rsync: connection unexpectedly closed (0 bytes received so far) [sender] rsync error: error in rsync protocol data stream (code 12) at io.c(226) [sender=3.1.2]

To fix that you have to patch your vagrant installation manualy.

This fix is for vagrant 1.8.0 and 1.8.1

vagrant -version shows you version

This is the fix:

https://github.com/mitchellh/vagrant/issues/6702

Edit $VAGRANT_HOME\embedded\gems\gems\vagrant-1.8.0\plugins\synced_folders\rsync\helper.rb Remove the following codes (line 77~79): "-o ControlMaster=auto " + "-o ControlPath=#{controlpath} " + "-o ControlPersist=10m " +

at next you can run "vagrant reload" and the error is solved

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