Monday 23 May 2016 3:20:07 pm - 16 replies
Background: Vagrant environment, Windows
I have installed a fresh copy of ezpublish 5.4 and went through the /ezsetup process in my local dev environment. I exported the database and committed everything to git using the default .gitignore.
When I try to use this same git repo on another machine or delete the existing one from my machine, I get redirected to the /ezsetup. This happens consistently and I'm out of ideas why.
If I go through ezsetup again and export the database and vagrant down my machine and then back then the site works. However shouldn't re-importing the database just work?
Modified on Monday 23 May 2016 3:20:32 pm by Travis Raup
Monday 23 May 2016 3:30:52 pm
No if you don't commit to your repo your legacy settings file.
When you go to something in legacy it tries to find something in the settings/override/site.ini.append.php. If it's not present, then ezsetup start.
This is one of the things that i'm trying to avoid with my approach to ezplatform-legacy together
The idea is whenever you do a composer install, another command will try to create those legacy files for you without the need of going to ezsetup again.
Modified on Monday 23 May 2016 5:07:15 pm by Carlos Revillo
Monday 23 May 2016 4:11:52 pm
Thanks for your prompt response. I'm in a multi-developer team and I want to pass the gitlab link to everyone to pull the repo but then they would have to go through the ezsetup setup process. I will commit the /settings/override/site.ini.append.php however the repo doesn't contain the ezpublish-legacy folder or anything in /vendor. So would the best place to keep it is the root of the project with a readme to instruct the developers what to do with it? This is just getting more complicated than I imagined it would.
Monday 23 May 2016 5:01:39 pm
Maybe (and i mean maybe) will be enough if you just commit that settings/override/site.ini.append.php. if i'm not wrong , when your teammates will do the composer install part, that file will remain there. and so probably the ezsetup won't prompt part again
But be aware that you probably need some other settings to make the legacy admin work as expected. in my experience, to feet my need, i needed to add a toolbar.ini.append.php and least the language configuration part in the site.ini.append.php
i also added something to have the dynamic tree enabled by default, but that's just a personal choice.
Modified on Monday 23 May 2016 5:06:54 pm by Carlos Revillo
Monday 23 May 2016 8:21:31 pm
Thanks for the extra suggestions. I need to get to that point first and avoid this ezsetup for each team member.
Forgive me as I'm not fluent with git yet but in my .gitignore in the root of ezpublish 5 I added the following.
This didn't work and if I'm not mistaken I need to add more gitignore lines to exclude each sub directory of /ezpublish_legacy. I tried creating a .gitignore in the override folder and did the !/site.ini.append.php but no dice.
Monday 23 May 2016 8:51:52 pm
Man this is a lot of configuration to include one file.
Wednesday 25 May 2016 10:13:39 pm
Just an update on this thread. I wasn't able to get this to work with only including the site.ini.append.php file. I tried committing everything within /settings/override and /settings/siteaccess but I get ezmodule cannot be found warnings.
I created a test environment and removed the ezpublish_legacy folder from the gitignore and can see after the /ezsetup process is complete there are 50+ files modified within ezpublish_legacy folder.
At this point trying to create a project that is ready to go in a team environment has been extremely difficult. I'm ready to just commit the entire ezpublish_legacy folder into git and just be done with it honestly.
Wednesday 25 May 2016 11:10:58 pm
if you want to keep your setup that you had done in your dev env you will have to keep everything in overrride and siteaccess.
You will also have to add any legacy modules that you used in your composer such as ezsystems/ezdemo-ls-extension ezsystems/ezfind-ls ezsystems/ezscriptmonitor-lsezsystems/ezwebin-ls-extension depending on what you used during installation. I'm guessing one of those may be your module not found. You also may want to add generating the legacy autoloads to your provisioning script in case they are not regenerated by composer. I forget off hand if they are or aren't.
Thursday 26 May 2016 4:50:24 am
Just tried to duplicate this setup.
I can confirm after you run composer you also need to generate the auto loads in legacy 'cd ezpublish_legacy/ && php bin/php/ezpgenerateautoloads.php' along with including the admin site access.
It then worked without issue.
Here is a git branch with my example. Note it is against ezplatform and I am using a ezpublish legacy branch that has an update to deal with a bc break in the db and how usernames are handled.
Good luck to you.
Modified on Thursday 26 May 2016 4:57:43 am by Douglas Hammond
Thursday 26 May 2016 5:57:37 am
Sorry last time I hope to bug you. I just looked and legacy bridge does have a composer script handler to generate the autoloads. I have added them and now after a db restore, a git clone, a copy parameters.yml in place, and a compser install I'm all good to go
Thursday 26 May 2016 8:14:55 pm
Trying to process all this. I didn't add any custom extensions/modules, just downloaded a clean copy of ezpublish 5.4 and trying to get this project initialized for the rest of the team to start using.
The autoloads generation wouldn't work in the provisioning file for the first time anyone gets the repo as the composer update/install command didn't execute yet. My work around is adding a readme.md file with instructions for installation on the first go including the autoloads generation.
I guess it's over kill but perhaps just committing the entire ezpublish_legacy folder would be the way to go with what I'm trying to do. Our environments are windows based and I'm messing around with trying to get the vendor/cache/logs folders to work with vagrant-cachier and moving those directories to within the vm only. I guess this means if the vendors dir lives only within the guest vm I would have to run composer each time I start up the environment.
Thursday 26 May 2016 9:22:05 pm
Of course, tried committing the ezpublish_lagacy folder and still getting 500 Internal Server Error - ezpModuleNotFound error after composer update and php bin/php/ezpgenerateautoloads.php
I think I'm going to forget vagrant and just create vmware machines and pass them out to each team member. Removes the windows character count limit and the symlink issues.
Thursday 26 May 2016 9:46:13 pm
Any chance you can share your provisioning script? I would think composer should be part of it Composer should not have to run every time you run your vm unless you destroy them after every use. I would think your provisioning would be pretty simple such as configure your db, import the initial db, setup php and apache then clone your repo and run composer on it finally expose it to apache. On windows I don't use shared folders as I use vbox and they are too slow. I just use the vm's file system and share using samaba.
Maybe I am misunderstanding your goal. Is it to just have a clean install with the setup process already completed?
Tuesday 31 May 2016 4:10:51 pm
Yeah I can send you what I have for provisioning. Essentially it does what you describe except for the git clone of the repo and running composer. I'm using windows as well and using the vagrant plugin winnfsd for sharing the folders. I am running into windows 260 character limitations with the cache and vendor folders and the symlinks not working. Perhaps I need to look into how you are running your environming by keeping everything in the VM file system and then using samba to hook up to IDE editor to modify files.
Goal: multi team environment to get ezpublish 5.4 up and running without going through the ezsetup during the first time you boot it up.
You must be logged in to post messages in this topic!