By Bruno Skvorc

13 Steps to Get eZ Publish 5.x to Work on Homestead

By Bruno Skvorc

I have since taken another look at eZ Publish (now eZ Platform) and things have improved significantly. Details here.

This article was initially going to be a quick tip on how to install eZ Publish on Homestead in just a few steps. However, after I saw how much effort it took to get it up and working from scratch on a Vagrant box hosted on Windows, I decided to make it into a full article. I suffered, so you don’t have to :)

I’m hoping the eZ team will address the issues I state below, and as they do (if they do) I will alter this post accordingly. Granted, my environment is very specific: Vagrant on Windows. However, this shouldn’t matter. Every CMS, app, and framework I’ve tried to boot up in the same way was runnable in a matter of minutes. There is no reason in today’s modern web world for this not to work the same way on everything.

Vagrant-friendly apps

Let’s define the purpose of Vagrant. The purpose of Vagrant is team unity, and production / development parity regardless of host operating system. In other words, the purpose of Vagrant is twofold:

  1. Being able to provide each team member with the identical development environment to avoid “it works on my machine” excuses
  2. Being able to replicate the production environment as closely as possible without disrupting either the host machine, or the environments dedicated to other clients on the same machine

Therefore, we use Vagrant to have identical copies of VMs dedicated to a single project, which can be easily destroyed and rebuilt without repercussions for easier, faster and more scalable development, experimentation and deployment.

Through experimentation with the installation procedures below, I’ve found that eZ Publish does not make this easy. In 2014, most professional developers with multiple clients and/or projects use Vagrant even while soloing – having dedicated, separate, destructible and rebuildable environments for each project is priceless when considering the plethora of hosting options, tools, and versions of those tools at our disposal.

I’m disappointed to not see more apps adopt a Vagrant-first approach these days. Just like we need to think mobile first when developing front ends, we should think VM-first when developing back end libraries, frameworks and apps – otherwise the whole Docker / Vagrant compartmentalization story the world is focusing on is moot, and the apps that fail to adapt will be left behind as the world moves to Heroku, GAE, Amazon and others.

Let’s start the installation procedure now.

Important Note: If you’re not on Windows, Step 5 probably won’t happen to you. If you are on Windows, you can avoid Step 5 by running the entire procedure in an “elevated” Gitbash / command prompt (by running either as Administrator). Admin users are the only ones who have permission to create symlinks on Windows 8. There were rumors of this being fixable, but none of them reliably work. Running your dev environment as Admin opens a whole new can of worms, so do that at your own risk. If anyone successfully gives a regular Windows 8 user permission to create symlinks through Gitbash, please let me know.

Step 1: Homestead Improved

Have a Laravel Homestead Improved box prepared and working. If you did vagrant up to see if it works, do vagrant destroy so we can configure it.

Step 2: Add Site

Open the Homestead.yaml file, and add a new site:

    - map:
      to: /home/vagrant/Code/ezpub/web

Add to your host machine’s hosts file, as described in the Laravel Homestead Improved quick tip. Basically, make sure your hosts file contains Naturally, also map the shared folder.

Boot the VM with vagrant up and enter the VM with vagrant ssh.

Step 3: Install Prerequisites

The project needs PHP to have the php-intl and php-xsl extensions installed. It will also ask you for sendmail throughout the setup wizard. In Homestead, you can install all of these with:

sudo apt-get update
sudo apt-get install php5-intl php5-xsl sendmail

Step 4: Get Code

cd Code
composer create-project ezsystems/ezpublish-community ezpub

The above will create an eZ project for use, not for development. To get the development version, refer to their Github page.

Note that eZ Publish is ridiculously large, and will take a while to do this. It is almost guaranteed you’ll be hitting the “60 requests per hour” unauthenticated GitHub API rate limit, so you might have to input your username and password during the installation process to get through that barrier.

The process might fail a couple of times due to timeouts and the enormous amount of data that needs downloading. If that happens, just remove the entire ezpub folder with rm -rf ezpub and re-run the above create-project command – it will be faster every time, because each time a package is downloaded, it is served from local cache on subsequent requests, rather than being re-downloaded.

The installer will ask you for some data near the end (secret, fallback locale, etc). Fill it out or just hit enter on each to use defaults.

The reason why we’re not using a prepared tar archive downloaded from eZ Publish’s website is because the prepared archive is packed with symlinks – and those don’t work if your VM is hosted on a Windows machine. In an effort to keep things multi-platform friendly, I’ve opted for the composer create-project approach.

Step 5: Handle Installer Bugs [Windows hosts only]

As it stands, eZ Publish isn’t really fine tuned for VMs or edge cases and there’s a lot the team didn’t consider – for example, running it in a VM on a Windows box. With all the dependencies, it’s guaranteed to break somewhere during installation. For me, and probably for you too, this will be the post install scripts that install Assets. Install assets is actually part of Symfony which, in the class which does it, does actually warn against Windows and symlinks, but doesn’t take it into consideration if the parent project forces symlinks, like eZ Publish does.

If this happens (you’ll get an error about symlinks and some such), open composer.json and delete the line:

"symfony-assets-install": "relative",

This will force the installer to copy the design assets rather than symlink them.

Then, re-run the post-install scripts by executing:

composer run-script post-install-cmd

You might still get an error about the legacy eZ version and a comments bundle of some sort, but I’m not sure how to fix that yet, or whether or not it matters.

Step 6: Create a Database

Create a database we’ll feed to eZ later on. Log into your MySQL instance in the VM with mysql -u homestead -psecret. Then, run:


Step 7: Set Up Folder Permissions

This step can be skipped on Homestead, because the server already runs under the “vagrant” user, which owns all the subfolders in the ezpub folders.

Step 8: Run the Setup Wizard

Edit: see Jerome’s comment below for an approach that handles a part of Step 8 and Step 9 automatically.

Visit and see the following screen.

This is where it gets super weird. For no reason, this happens. Yes, it’s a problem that has remained unfixed for two years now – seriously, it’s a two year old unresolved bug in a PHP project. Fixing it in the core would take seven seconds of work, including commit and push (see 8.2). There are two ways to get around it in our case. None is pleasant, so it’s up to you to pick one.

Step 8.1: Hilarity Ensues

In order to get around it, and I’m dead serious, this is not a joke – you need to open up dev tools, and put ezsetup at the end of the form’s action attribute, because by default it only says index.php. It’s baffling how such an issue can still exist in 2014, but here we are:

Pick this approach if you don’t like altering a framework’s source files.

Step 8.2: Hacking the Guts

The second, perhaps slightly simpler approach is modifying the form of the wizard itself, and altering its action attribute.

Go into ezpub\ezpublish_legacy\kernel\setup\ezsetup.php, and find the line:

$tpl->setVariable( 'script', $script );

Above it, put this:

$script = ($script == '/index.php') ? '/index.php/ezsetup' : $script;

After this, the action attribute will be fixed.

I do not recommend you try to manually set up eZ Publish by skipping the wizard because you will go insane. Objectively, their installation procedure and their documentation are some of the worst I’ve ever seen. You will lose all desire to even try it out if you attempt to follow their instructions. I hope the eZ team will soon completely remove all dependencies and references to their legacy system, leaving in place only the new core – I also hope they’ll soon update their documentation to something more readable and more 2014-like: people develop on dedicated VMs more and more now, and a short installation procedure along with ease of entry are the most crucial attributes of any CMS that wants to stand out.

Step 9: Ignore Wizard Errors

The eZ Publish setup is out of date enough to know only of one server (Apache) and as such thinks it isn’t running in Vhost mode:

Ignore this warning. Continue on to the next screen (if you used 8.1., don’t forget to alter the form action again, else you’ll start over).

At the end of the setup wizard, you’ll get an Nginx timeout error. This is because eZ Publish is notoriously slow due to it having to process both the awful legacy version and the new version, and due to running on a VM, so when that happens, just remove anything to do with ezsetup from the URL and refresh. You will then be greeted by this beauty:

Step 10: Disable Cache

The error in the above screen happens while eZ is trying to create caches of PHP files, like this one: /home/vagrant/Code/ezpub/ezpublish/cache/prod/stash/0fea6a13c52b4d47/25368f24b045ca84/a1e4f174919d040af6d06113d677c9e0/4a1c6be177996f9e/03934ae1c1c02ffc/9a0364b9e99bb480/dd25e1f0284c8555/caf9b6b99962bf5c/2264824231d7a40c/d3d9446802a44259/755d38e6d163e820.php (ugh, don’t ask…).

This cache engine isn’t clever enough to disable itself in case it fails, so we have to do it manually.

In ezpub\ezpublish\config\ezpublish.yml change the stash block to this:

                - BlackHole
            inMemory: true
            registerDoctrineAdapter: false

“In memory” means the memory will be used for stash cache, instead of the File System. Clear the cache with rm -rf ezpublish/cache/* and refresh. If need be, replace the cache engine with something more decent than FileSystem cache later on. I have no idea how else to alleviate the protocol error for mkdir – I know it’s VM-related, but not much more. Any advice is much appreciated.

You will now likely be greeted by yet another flurry of warnings and a 503 error at the end:

But at least we got the title to render!

Step 11: Bootstrap.php.cache and Response Limits

The file causing all these warnings is, in fact, a compilation of all the required PHP files for eZ to load up. They’ve been merged into one (!!!) and put into the ezpublish folder, from whence it is served. The file is a mess of code and not easy to debug because, apart from not having the php extension and lacking IDE highlights, it also doesn’t respect any kind of coding standard (hence, dozens of classes in one file, no indentation and with that, no readability), it being “just a cache file”, after all. But when your entire application depends on a cache file, it would be nice to be able to debug it easily.

Horrible caching practices aside, we can disable this entire mess and just load up eZ Publish in debug mode by changing the ENVIRONMENT environment variable. You can change this in Homestead.yaml so it gets autoconfigured during boot by adding it to the “variables” block:

    - key: ENVIRONMENT
      value: dev

Or, you can just edit the index.php file under ezpub/web and put $environment = 'dev'; under $environment = getenv( "ENVIRONMENT" ); on line 8.

At this point, the second approach is easier if you’ve followed along, because otherwise you’ll have to start over with the entire setup process if you destroy and up again.

Finishing this, you should be able to get this to render:

Due to eZ Publish request responses being so absurdly large, we need to up Nginx’s limits:

sudo vim /etc/nginx/sites-available/

Under the root directive, paste the following:

fastcgi_connect_timeout 60;
fastcgi_send_timeout 180;
fastcgi_read_timeout 180;
fastcgi_buffer_size 128k;
fastcgi_buffers 4 256k;
fastcgi_busy_buffers_size 256k;
fastcgi_temp_file_write_size 256k;

Save, exit, restart Nginx with sudo service nginx restart.

Some pages will work (blog, discover), others, well, not so much. Debugging their Demo bundle, however, is outside the scope of this already too long article.

Step 12: Remove index.php from the URL

By default, all Symfony apps have “app.php” or in eZ Publish’s case “index.php” in their URL for some reason. I guess someone has to support those hosting providers and developers from 2001. Let’s bring both projects into the 21st century by removing it.

sudo vim /etc/nginx/sites-available/

As per instructions here, above the “location” block, add:

rewrite ^/index\.php/?(.*)$ /$1 permanent;

Save, exit, and restart nginx with sudo service nginx restart.

Step 13: Rejoice

After an arduous process, we’re finally done. What took me more than a day, hopefully took you less than 10 minutes (excluding download times). Now you too can try this powerful, albeit overbloated, overcomplicated and outdated CMS on your own Homestead instance. Let me know how it works out!


Any CMS that requires this much work to get up and running on a Vagrant box is, in my mind, not a CMS worth paying attention to. Sure, you can probably easily install it onto a host machine and run it that way, but that’s not a professional approach – development environments need to be encapsulated and isolated, and developers need to be able to destroy and rebuild an instance on a whim. A CMS should have scripts that auto-execute, detect all possible problems (like Symlinks not being available and switching to hard-copy mode automatically) and set everything up (from the database to the folder permissions, if necessary), only asking for sudo along the way.

This process has installed eZ Publish, but was it worth it? That’s up to you to decide. While eZ definitely is a powerful CMS, the difficulties of getting into it are detrimental at best. You now have a common starting point to test it out on, and I’ll be sure to find out more about these issues from the eZ people at PHP Summer Camp and elsewhere. Until then, let’s get some eZ tutorials going on this box, shall we?

Put your feedback in the comments below, I’m eager to hear different approaches, especially if you’ve tried to do this on a non-Windows host and made the demo bundle work!

Edit: This Github repo has been brought to my attention. It is a prepared vagrant configuration of eZ Publish that works. There are two caveats, though:

  1. The point of the step-by-step here was to show you how simple it was to have an identical eZ instance up and running on any machine for development purposes (the fact that it turned out not to be simple is another story entirely). This is important because, for example, not everyone uses the same OS – the repo linked above is on CentOS, while Homestead is Ubuntu. The installation procedure should be equally simple on any OS.
  2. The eZ Publish files inside this VM are literally inside it – there is no sharing of folders to the outside world (host machine), ergo no chance of symlink issues, but also no chance of opening the app’s files in an IDE installed on the host machine in order to hack on them. This prevents an effective development workflow.
  • I absolutely agree with your conclusion: eZ Publish currently is not easy to install and I haven’t found a completely automated way of doing so except using a set of puppet scripts with predefined configuration files and script executions.

    Still, there is a way to make the installation experience a bit better, and this is by making use of the kickstart.ini(.dist) file in the ezpublish_legacy directory, which you can find fully documented in the official documentation.

    In short; you can skip the steps 8 and 9 for the most part by putting a configured kickstart.ini in your ezpublish_legacy with this content, to skip the wizard until the very last step (if I do recall it correctly, the last form submit still has to be done):







    Title=eZ Demo




    I haven’t tested it, so there might be errors, but it should give you an idea and at least provide a workaround around some of the issues. And you still will have to hack the submit form in the browser console.

    • That does alleviate *some* of the issues, I’ll make a note in the post, but it’s far from how things should be. Thanks for the input!

  • André R.

    As mentioned in update, for those that want to simply install eZ Publish, rather use:
    With it you can also install with your own dowload like so:

    diff --git a/Vagrantfile b/Vagrantfile
    index ba44883..179ff75 100644
    --- a/Vagrantfile
    +++ b/Vagrantfile
    @@ -54,10 +54,10 @@ Vagrant.configure("2") do |config|
    puppet.module_path = "modules"
    puppet.facter = {
    "www" => "/var/www/html", # Default apache folder
    - "ezpublish_src" => "",
    + "ezpublish_src" => "ezpublish5-5.3.0-ee-ttl-full.tar.gz",
    "ezpublish_folder" => "ezpublish5", # Folder where eZ Publish will be installed
    "ezpublish" => "ezpublish.tar.gz",
    - "type" => "tar", # This can be tar, local (tar) or git if you're using dev environment
    + "type" => "local", # This can be tar, local (tar) or git if you're using dev environment
    "database_name" => "ezp", # You can define the database name
    "database_user" => "ezp", # You can define the database username
    "database_password" => "ezp", # You can define the database password

    Using the above you’ll avoid getting into the myriad of issues you can step into, and more or less all are mentioned in this post, by the different libraries we use:
    – Stash, a cache library, not great for windows or when directory permission are setup wrong
    – Assetic: Forces you to re dump assets for the symfony prod environment, we tried to make things simpler by using symlinks which is an option
    – boostrap.php.cache, a convention we inherited from symfony-standard

    Other then that make sure to follow the online doc rather than this post on details like your httpd config, cause that will save you from the setup wizard, response size and other issues, see

    But yes, we are working on making eZ Publish simpler, we are in transition phase between eZ Publish 4.x (legacy) and 6.x which will be called “eZ Platform”, be pure Symfony based and out in alphas later this year. And one of the steps we’ll do before that is to replace our setup wizard and the improving the toolings around it.

    • Thanks for your input. I looked very carefully at the docs, but could find nothing usable regarding any of the issues encountered. For example, the only written word I encountered regarding the ezsetup loop was, in fact, that linked forum post. Could you point me to the exact locations where the solutions to my issues are mentioned so I can update the post accordingly?

      Looking forward to the alphas of 6!

      • André R.

        For your symlink issues, did you for instance try the comment about “elevated prompt” on Windows installation:

        As for permission issues this is because the permissions are skipped in your step 7 instead of setting them:

        But beside those two things I can confirm that both Symfony and inherently eZ Publish has lots of issues when you attempt to install it using shared folder on vagrant, that and the bad file system performance you get is why people tend to use nfs shared from guest, or trying out the relatively new rsync option with Vagrant. So I would not recommend using the “Homestead Improved” with anything Symfony related, it is made for Laravel, and I assume it uses shared folder (but impossible to know by just looking at the Vagrant file since it abstracts it).

        • I will definitely give elevated prompt a try and report back.

          I don’t see how folder permissions are required, since the vagrant user (under which Nginx runs) already owns the entire folder, and the app does actually create cache – only the stash cache fails, the one defined in the config and changed with BlackHole. I’m confused on this cache issues, especially since it seems to be happening from ten directions.

          You are correct in that assuming it uses shared folder – you can see this by going into scripts/homestead.rb. I’ll give the other sharing options a try.

          • André R.

            Well first of that is not a very secure setup, but leaving that aside the file permission commands also tries to make sure both command line user and server user has access to the files they should be allowed to write to. For instance if you executed anything using sudo it will suddenly be owned by root which is a problem that can be fixed by executing the permission commands again. But as I also said shared folder just don’t work with Symfony, so that might be the reason as well on the permission issue.

            Bon weekend

          • Just tested elevated prompt, can confirm it works, have updated post with a warning for Windows users. Is a decent workaround for the symlink issue, cheers.

  • Ivo Lukač

    HI Bruno,

    First of all, thanks for testing the install. It might be painful, but should also bring some problems to eZ team attention. I see Andre already made few valuable comments.

    I could give some context to this story but that would require a longer post :)

    What I will however point out is that eZ Publish is in 99.9% time deployed in *nix operating systems. I know only about one windows production installation and heard it was a pain. So if you are using Vagrant or Docker or whatever other “development container” make sure it really does simulate the production environment. That includes symlinks. Its a normal server feature that is used for decades. I would never, ever consider to work with PHP on something that doesn’t support symlinks :) But thats just me.

    Of course the vendor should provide as much as possible options for newcomers to use the software so there should be a cookbook in the documentation for sure. I am quite sure that eZ/Symfony community are able to prepare this if there is a need.

    • You’re quite right – not having symlinks supported by the host is the host software’s problem, not the problem of the software I’m trying to install. If it isn’t meant to be installed on something that doesn’t support symlinks, it shouldn’t be. However, there should be an explicit note regarding that incompatibility in the client software’s docs (I didn’t find one).

      I am now looking into elevated prompt mode, and will report my findings.

      The problem with this installation procedure, however, lies much deeper than symlinks. The symlink trouble can be avoided by doing a hard copy and then it’s fine, but it’s the wizard and the legacy system that shouldn’t exist. Do you know what the exact purpose of the legacy system is? Besides the setup wizard. I’m curious about what other functions it performs in the environment of the new system, so I can have a bit more detailed look at things.

      • Ivo Lukač

        The legacy system is based on a code started to live in 2002 or something like that (ez publish version 3). In 2012 eZ started to reimplement the core (public api, rest api, persistence api, …) with a new architecture in mind. Soon they decided to not reinvent the wheel and embraced Symfony as a base framework. After 2 years of coding on new stuff and only maintaining the legacy (they have 1000+ clients with LTS contracts) its still not covering all the features that the legacy introduced in its 10 years of active development.

        What eZ managed to do is a very rare thing. The new code which is being developed can be used side by side with the legacy to ease the transition time. This is very important thing if you want to be Enterprise software. You don’t leave you clients out there pissing in the wind.

        As Andre already mentioned, alphas of “only new” ez is coming this year. We might have stable versions next year for deployment with a clear upgrade path from the legacy.

        Currently you need the legacy because of the administration interface + some features that are not yet implemented in the new stack. The list is shorter and shorter with every new release but its still there.


        • I see, thanks. Didn’t think such a big part of it still depended on legacy.

          • Ivo Lukač

            Yeah, well, ez is not a small script that you can rewrite in one afternoon :)

          • crevillo

            Yep. As said in twitter, “problem” with eZ Publish is that it really had a lot of funcionalities to manage content by default. While other CMS tend to provide and small core and let the user add his module, eZ Publish provides those modules by default. Thinking here in some datatypes, versioning system, ways of clean caches for those contents, ways to define rules to convert your images to the sizes you want… etc.

            Further more, customers had also developed their own extensions based on the eZ (legacy) framework. They will simply won’t upgrade to eZ 5 if they know that the work they did in those extensions is totally useless

            It hadn’t make any sense to have lost any of those functionalities with the symfony move, and so i think eZ made the right decission here.

            Maybe you are wondering what will happen with all the funcionalities developed with legacy code when they unplug legacy from the ez system. Well, as far i know, this is something eZ Crew is taking care and still this won’t imply any backward compatibily issue.

          • I don’t know, I’m completely against such approaches. There is no reason to maintain legacy code for that long. Sure, if you have an LTS contract, you should *support* the system for as long as the contract says with bugfixes, but not upgrade it in any way. As far as I’m concerned, 99% of the effort should be going towards a full rewrite, aiming for a full BC break with versions <6. But that's my 2 cents…

            There is no module in the world complex enough not to be rewritable into 5.x or even 6+ within a week. If the logic is there, it's easy for any professional dev to rewrite it, period. If the logic makes no sense, then what are you doing maintaining a broken product anyway?

          • crevillo

            well, i’m fully agree with this approach. To me backward compatibility makes totally change. Even symfony thinks so. And as they say “Ensuring smooth upgrades of your projects is our first priority”

            What we would think if we were a php dev developing libraries for 5.5 and those libraries won’t work at all for 5.6 or PHP 6? Or if any version of Windows will imply you wait for Adope to rewrite their Photoshop suite to try the new windows? To me is the same.

            And yes, modules can be rewritten by devs. But eZ Systems have contracts with companies that probably have no devs at all. I’m not an eZ employee, but i can understand that eZ Systems, as company, can’t go to their customers saying “you need to hire some devs because we’re going to do this and what you have won’t work any more”.

            Finally, what you mean by maintaining a broken product?

      • crevillo

        what do you mean here: “I’m curious about what other functions it performs in the environment of the new system”? what other functions are you thinking of?

        • I was wondering why it’s even there, seeing as the new core is that huge, and the legacy system is that huge, and I don’t see that much functionality in the CMS to justify that filesize.

          • crevillo

            well, that’s opinable. all depends on what you think it isn’t much functionality. Imho compared to others it has. Everything could be improved for sure.
            on the other side, this approach and how ez is done implies also a thing -> your database structure won’t need to change to add more functionalities. by default you have all those tables but two years later you will have the same number of tables.

            i prefer this approach than starting with 50 tables and see how i reach 500 tables in less than a month…

          • Right, but if you have something as that might need 500 tables after a while, you’re better off building a custom CMS anyway, no?

          • crevillo

            Definitely. And that’s what i don’t want when choosing a CMS :).

  • Broken product = ez legacy (see the setup procedure above).

    If those companies get all their development from eZ themselves, then there’s even less reason to maintain BC with prior versions – that means eZ is literally in charge of everything, and they can dictate the upgrade speed of their clients, which makes things even easier. I’m probably misunderstanding something, but it all seems very straightforward to me.

    Back at my old job, we had an ancient system on Zend 1. The system was slowly but surely falling apart, but worked. This system handled millions of views every month, had 100k registered active users and over 100 employees all over the world using its back end, all custom built. When I saw it was going to blow up in a few months, I took that time to myself, built a new one alone from scratch, and that one is used even to this day, more than a year and a half after I quit.

    If you’re fully in charge of software for your clients, like you say eZ is above, then you’re literally the only person who can update it as soon as a new version comes out – the client never has to know. Even better/easier if that new version is a version of your own software.

    • crevillo

      Reason to maintain bc is to not lost all funcionalities legacy had and that hasn’t been ported yet to new stack.

      I can talk about my experience. normally, a customer hires us (we are ez partners) for built the site. this site normally requires to add some specific funciontalities for that concrete customer. As probably almost every site in the world nees some specific funcionaliy. Thinking here in a specific import process from an external source, a custom login system to a custom external webservice, a custom pay/shipping method for the shop functionalities… whatever.

      We do them and after that, our customer has what they want. a fully cms that they can manage without the need of our techincal person.

      Obviously our customer knows upgrades happens. There are security advises sometimes. But they also know he can go for an enterprise solution and ez can take care of all the changes in the core and in the extensions maintained by them.

      Obviously eZ Systems won’t maintain the extensions we could have developed. So, the customer ask eZ Systems: “well, if there’s an upgrade will the custom code developed for the shop, the login system, etc, will that code still work? Or do we need to pay our provider again to port all that to the new stack? If so, we’re not interested in this anymore.”. I can asure you that we have customers like this.

      Further more, please note this is not change in the name of some functions or the params they could use. This is the move from a framework (the ez one) to another framework. In other words, is like Magento switched from Zend to Symfony or Cake.

      Could you imagine all that shops in the world being forced to re-develop all the custom modules to that new framework before upgrading? I can’t…

      About broken product = legacy. I think your install problems are not related to legacy. I do ez install almost every week and works without any problem in my laptop i admit this process should be improved, And let me add something else about this:
      what ez is saying is that we should expect a fully symfony eZ Platform in the next months where legacy code won’t be provided. But this doesn’t mean that this will make all the legacy code fails. Probably there will be something to respect that compatibility issues, maybe as another bundle…

      But, as you see some problems with legacy, eZ crew saw other problems with legacy code and because of that, they thought it could be good to move to symfony. I invite you to have a look at the reactions on when they announced that. Even eZ Crew was saying that there won’t be any BC problems many people panic, really panic about. Could you images what they could thought if eZ Crew had announced a totally break with that? :)

      So, to finish, to me this is a balance question. There is a need to improve the whole thing, and there is where symfony stack enteres, and there is the need of maintain all the functionalities legacy offered.

      • To clarify, I am all for *support*, but not for upgrades. So, I support LTS in the form of bux fixes, but I don’t support LTS in the form of adding new features to an old stack, and that’s what seems to be happening here.

        I understand completely what you mean, yes, but you should tell those customers that yes, new versions happen, and no, they won’t have access to new features unless they pay again, because they didn’t pay to have the new features, they paid to have those they ordered last time – but you will guarantee that their software will continue to work on the old version until the end of the LTS contract (this is where bug fix support comes in).

        On a side note, when you do a new install, do you have the installer bug? (step 8)
        If not, how come? Didn’t we download the same source? Did you ever install it on Nginx? If you do get the bug, how do you get around it?

        • crevillo

          no, i havent that bug. I’ve installed it again this afternoon and i have it working with nginx. But maybe i have this bug because i follow the doc saying to setup the virtual host before starting the install process. in other words, when composer finish its job, and i go to http://[host]/ i’m redirected to http://[host]/ezsetup
          Never tried without the vhost setup.

          about adding features to the old stack, i don’t get you. The setup process is coming from the legacy stack and, well, if there are errors, those errors are tried to be fixed but as André says, there will be a new install process and, (really can’t say) i guss it will be written in symfony and not with legacy code.

          • Could you point me to the part of the docs where a 100% working and well written nginx configuration is shown? I would have used it had I been able to find it.

        • gggeek

          Well, the setup wizard is legacy by definition, so by your own logic it should not be improved, right? we are in dog-eat-tail mode here ;-)

          Apart from that, as someone else probably already answered: why use containers and windows? To me it makes no sense at all…

          I have personally been running eZ on windows every day for the last 7 years, and am fully aware that you need to run an elevated prompt for symlinks. I could even entertain you on how to make virtualbox not-puke on linux symlinks exposed to windows via the vfs (short story: it can be done but its not funny).
          But I run on windows because I can fully manage the os and its warts.
          When I run vms and container apps, it is because I want to run prod-like environments.
          And eZ5 is not yet certified to run on windows in prod.

          • “why use containers and windows? To me it makes no sense at all” not sure what you mean by that, could you clarify?

            In the text above, I’m not trying to make eZ run on Windows. The bug above in step 8 is aimed more at Symfony and Vagrant on Windows, and a lack of a fallback mechanism.

            As stated in the edits, the symlinks do actually work when using elevated prompt, so no big deal there – the problem is the rest of the legacy system. I don’t see it as “improvement” if you fix an installer bug – that’s a bugfix – just like adding a reference to Nginx instead of only supporting Apache. Both those items are three second fixes that could and should be done immediately.

    • gggeek

      You are probably thinking in an employee-managing-one-inhouse-project mindset here, not in a software-house-with-a-product-and-many-customers one.

      eZSystems, the company behind the CMS, is not delivering projects to end customers. It works with a network of partners, who implement the customized versions by integrating the CMS, open-source extensions from the community and their own code.
      There are thousand of community extensions available.

      So it is just impossible for eZ to go to each and every customer and offer to upgrade their installation: there’s not enough developers in house.
      But even if, for each project the original developer (or an alternative developer equally competent) was available to take on the task, I highly doubt that the customer would be happy to pay for that work.

      Unlike with some other open-source CMS, backwards-compatibility guarantee has always been a hallmark feature. Is is part of the reason why enterprise customers are in fact happy to pay for support. You can today download a community extension developed for eZP 3.6 and have it generally working on 5.3 with a couple of line of sources changed, no more.

Get the latest in PHP, once a week, for free.