Technology scout

Sometimes I need to make a small change to a composer package, often in a Symfony project. It is a really bad idea to just go into the vendor directory of the package and change some code. It’s much better to fork the corresponding repository, apply your change and build a new release. Then you can use that in a composer.json file.

Fork the repository

For the purpoe of demonstration I will create a customized version of Javier Eguiluz’s EasyAdmin bundle for Symfony. So go to the github page of the EasyAdmin bundle and click on the “Fork” button in the top right corner. Github will create a fork for you under your own user account. Clone that repository and make your changes. For this is one line in the file src/Form/Util/LegacyFormHelper.php as I mentioned in the last posting.

Build a new release

Now we’re ready to build a new release. Go to the “releases” tab in your forked repository and click on “Draft a new release”. Define a new tag version (unimportant how you call it, I normally just count up the original release version). I normally enter something like “for private use only” into the “Release title” field but you just can leave that empty. Once you’re done you can submit via “Publish release”. You will be brought back to the release list and see your new release tagged with a green label saying “Latest release”. You just built your first release \o/

Use the release in a composer.json file

You now can change your composer.json file. First you need to add the repository. By default composer will look up the packagist repository. If you define a different one in the json file this local one will be searched first before falling back to the public repo. So we need to create a repository section and list the github repository. Mine looks like this:

"repositories": [
    { "type": "vcs", "url": "git@github.com:vmgforks/EasyAdminBundle.git" }
],

The type is “vcs” (version control system) and the URL is your forked repository. I like to keep forks in a organization of its own called “vmgforks”. Now we can require the package by using its original name and the required version just is “*”:

"javiereguiluz/easyadmin-bundle": "*",

Now update the composer.lock and download and install the package by:

composer update

Now you can check if the change made it to the vendor directory.

Developing with Symfony 4 can sometimes be a bit challenging as some of the most widely used bundles are not yet ported to Symfony 4 or never will be (like FOSUserBundle). And sometimes a bundle works pretty well but one of its third party plugins/bundles doesn’t. This is the case with the brilliant EasyAdmin bundle. Sometimes you might want to offer a WYSIWYG editor to a backend user. For this case there is a bundle called IvoryCKEditorBundle that integrates the famous CKEditor into the form component. But the Ivory bundle not (yet) supports Symfony 4 so a helpful soul created a fork and called the package hillrange/ckeditor so you can use CKEditors in nearly any form.

Nearly any but not EasyAdmin. We come to that later. First let’s see how it would work if it worked (that is a sentence, isn’t it?). In Symfony 4 the EasyAdmin config can be found in config/packages/easy_admin.yaml. For a simple entity that only contains a text attribute (of type “text” who would have guessed?) that we would like to WYSIWYG edit it would look something like this:

easy_admin:
  entities:
    entry:
      class: App\Entity\Entry
      form:
        fields:
          - { property: 'text', type: 'ckeditor', type_options: { trim: true } }

The field type is called “ckeditor”. For this to work EasyAdmin has an array of supported field types and this out of the box also contains an entry for the ckeditor type. It can be found in vendor/javiereguiluz/easyadmin-bundle/src/Form/Util/LegacyFormHelper.php and is called $supportedTypes. And this is why the Hillrange package doesn’t play well with EasyAdmin. The form class just has another name. The original line reads

'ckeditor' => 'Ivory\\CKEditorBundle\\Form\\Type\\CKEditorType',

and can be changed into

'ckeditor' => 'Hillrange\\CKEditor\\Form\\CKEditorType',

Doing so in the original EasyAdmin bundle in the vendor directory is a bad idea. My approach is a bit overkill but offers a clean and regular approach:

1. Fork the EasyAdmin bundle on github
2. Change the incriminating line as proposed
3. Build a release of “your own EasyAdmin”
4. Include that with the composer.json file to be pulled directly from github

How the latter works will be subject to the next posting. So stay tuned ;)

PS: At some point in the future the IvoryCKEditorBundle will be Symfony 4 ready (at least I hope so) and you will be able to turn back the composer.json entry to the original package.