Unable to initialize a new Webspace

[juagarc4]

Problem description

After creating a new webspace in the configuration, that is, the corresponding xml file in the directory webspaces, I have to run the command php bin/adminconsole sulu:document:initialize

It is fine if you can access to the server an execute the command. It is even possible if you control the deployment process and know when exactly the site is available, but what about the case in which you don't have any access to the server or to the deployment process? How can I execute the command to enable the new webspace?

Thanks in advance
Regards

[alexander-schranz]

@juagarc4 There is currently no way todo this. Sulu is build for enterprise websites which we expect have access to the servers, currently there is no way to use Sulu without having possibility to add CLI commands to your deploy process.

Already Sulu requires to run bin/console sulu:build ... to setup Sulu once on the server. So SSH Connection and access to run php commands is a minimum requirement for running Sulu. We are also not focused on changing this currently, as Sulu is heavily build on top of Symfony which already requires to rebuild the container cache via its bin/console cache:clear command on every deploy.

Even if you don't have direct SSH connection to the server, your deployement process should have possiblity to run additional commands as already the bin/console cache:clear. We normally recommand for basic project to use deployer, which is really easy to setup and provides a save green/blue deployment process.

[juagarc4]

HI @alexander-schranz ,

Thanks for the answer. However as far as I know, the bin/console cache:clear command does not involve the database while the php bin/adminconsole sulu:document:initialize command does. So it's not the same, because you have the files available as soon as the container starts, but it doesn't mean that the database is available at the same time. How am I supposed to run a command if I don't know exactly when the necessary resources are available?
In this case 'deployer' doesn't solve the problem either.

IMHO, Sulu should have an option in the admin area to initialise Webspaces, as the command does.

[alexander-schranz]

@juagarc4

the bin/console cache:clear command does not involve the database while the php bin/adminconsole sulu:document:initialize command does

Yes but it also a required command which need to be run on deployment. Also doctrine or phpcr migration also two commands which you need to run in deployment. So I think SSH access or the possibility to run CLI commands is a requirement for hosting for a Sulu without any problems. Do rm var/cache is never recommended to update your Symfony cache as race conditions of request can fail to create the Symfony cache. A green blue deployment is recommended for all kind of Symfony Application to avoid this kind of errors and so a SSH / CLI access is require dfor hosting this kind of application.

Sulu should have an option in the admin area to initialise Webspaces

Sulu focus is not to be a one click installation CMS. All kind of developer operations are done over the CLI. So the Admin UI is just for the content manager, so Sulu will not provide currently a way to init a webspace from the UI as it is a developer Jobs to create the webspace config xml configure it, init it, create VHost for it and so on, nothing which should the Admin UI bloated with.

Still if you want to keep your hosting and want to run Sulu on that kind of hosting. You would need to create that kind of UI yourself, but it just something we can not recommend and so will not be part of the Core. If you have multiple projects you could still could create a bundle out of it to run Symfony Console via a Web UI.

Also CLI access are not only requirement for deployments also for some bundles like the SuluAutomationBundle where it requires to have cronjobs running. I recommend here to go to a hosting providers which allows you run specific commands on deployment.

[juagarc4]

Also doctrine or phpcr migration also two commands which you need to run in deployment.

Indeed, and there is still huge problem to deploy symfony Application which uses different containers both the code and for the database. Anyway this is not a reason for not offering useful options, that are not exclusively a developer job.

Do rm var/cache is never recommended to update your Symfony cache as race conditions of request can fail to create the Symfony cache.

I never said that I execute this command to clear cache. In fact the command to clear the cache is easy to integrate in the pipeline only because it doesn't require a functional database.

Sulu focus is not to be a one click installation CMS.

I didn't suggest it. However the UX can be improved adding only somme useful options that don't really need the intervention of a developer.

it is a developer Jobs to create the webspace.

One maybe can consider the creation an configuration of a webspace as a developer job (I really don't think so) but the
activation of a webspace is not a developer job. It's possible that a webspace need to be created today but not enabled until some time later.
What about publication of articles? Is it a developer job too?
I think it's the same. In this case the users can publish and unpublish articles without requiring a developer. Why the activation and maybe deactivation of a webspace should be different?.
Moreover, Sulu offers already in the Admin UI an option to clear the cache manually and I think it's a great option.

Still if you want to keep your hosting and want to run Sulu on that kind of hosting...

It is not a hosting issue. In fact, in the SaaS era most hosting services tend to restrict SSH access as much as possible because it is dangerous and requires more effort to set up access and apply security measures. All console tasks are being automated or can even be managed through web interfaces, so that console access is only required for some specific tasks.

Also CLI access are not only requirement for deployments also for some bundles like the SuluAutomationBundle where it requires to have cronjobs running.

The problem isn't not to be able to run commands on deployment. I can execute commands on deployment.
I think it's important to be independent of the console as much as possible because you don't know in which environment your application is going to be installed.
Obviously if I contract a service, let's say in AWS, I can access to the servers over SSH, but if I'm only a developer in a company and don't have any right to access over SSH to the server, which ist mostly the situations in middle/huge companies, I'm not able to do simple tasks without involving an external team, department or those that manages the servers. Let's say infrastructures department. In the best cases if I have access over SSH it will be a really restricted access, where maybe this commands are not allowed to be executed. Even in this situation it would be possible to request access and permission to execute this commands.

But, anyway, the problem isn't not to be able to run commands on deployment. The problem arises in the situation in which you deploy different containers for the database and for the code, which is the most frequent situation nowadays. In this situation you can't execute a command while deploying because the container of the code doesn't know if the container of the database is already up and your command and the deployment itself will obviously fail.

I'm not saying that all console options have to be accessible in the admin UI, but some of there which provide simple tasks like clear cache or enable/disable webspaces doesn't have to require the action of a developer to execute a simple command.
Commands like migrations can be really dangerous and destructtive if you don't know what you're doing an therefore should be executed by developers.