I am needing some help setting up a Yii2 Advanced Application on Heroku. I have already installed Yii locally using Composer, following their guide exactly: http://www.yiiframework.com/doc-2.0/guide-tutorial-advanced-app.html
My website works as it should locally, with frontend and backend:
http://localhost/yii2app/frontend/web/
http://localhost/yii2app/backend/web/
When I push it and run it on Heroku, I get errors complaining that some files are not found. What is weird, is with a bash terminal to my Heroku app, I can verify that the file is in fact there! Is Heroku not liking the '../../' to change directory?
PHP Fatal error: require(): Failed opening required '/app/frontend/web/../../common/config/main-local.php'
include_path='.:/app/.heroku/php/lib/php') in /app/frontend/web/index.php on line 12
In 'frontend/web/index.php' is Yii's stock code (line 12 is main-local.php):
$config = yii\helpers\ArrayHelper::merge(
require(__DIR__ . '/../../common/config/main.php'),
require(__DIR__ . '/../../common/config/main-local.php'),
require(__DIR__ . '/../config/main.php'),
require(__DIR__ . '/../config/main-local.php')
);
If it had to do with the '../../' to change directory, then I would think the first require would have an error (for the main.php entry).
What am I missing to get Yii2 advanced running on Heroku?
UPDATE - I created a new Yii2 basic app. Should work and be simple, so I thought. Apparently even the basic app does not run on Heroku. There MUST be something left out from the docs, somewhere... Used composer to install Yii2 basic, put it under git, pushed it to a new heroku stack. Went to check out my app on heroku, adding /web/index.php to the end of the url.
ReflectionException
Class yii\debug\Module does not exist
I then put index.php in the root directory containing phpinfo(). I can confirm I get a phpinfo report. So php is running, it reports PHP 5.6.5.
Seems like Yii2 and Heroku do not play well without some magical (and un-documented) tricks. I have searched, and searched, and searched, and I can't find anything about this. I can't possibly be the only one trying to get a Yii app onto Heroku.
So I tried CloudControl. I deployed my stock Yii2 basic app to cloudcontrol, again I get a phpinfo report on the root index.php. Navigate to /web/index.php and get errors:
Invalid Parameter – yii\base\InvalidParamException
The file or directory to be published does not exist: /srv/www/code/vendor/bower/jquery/dist
What gives! I can run this locally just fine. When I push it to a cloud based host (Heroku or CloudControl) it fails! I figured the yiibasic app would be better to at least get it running for PoC, but Yii out of the box, will not run on either of those services. There is something not mentioned that I am missing.
Finally after hours and hours of messing around, I figured it out. Well, I still have one question left that I need to test (and try again). However, I managed to get both the yii basic and yii advanced apps running on Heroku. Still got errors on CloundControl though, but that's for another day.
I was missing 2 entries in my composer.json file. I dunno why these are not included in the Yii documentation if they are required in production. Here is my require block (I did not have to edit the require-dev section, just require):
"fxp/composer-asset-plugin": "*",
"ext-gd": "*"
The composer asset plugin was absolutely required. The GD extension is needed for the contact us page (I assume the captcha). I also commented out the first 2 lines in web/index.php for the YII_DEBUG defines. Once I did that, updated composer, updated git, and pushed, magic happened :)
I don't think they inform you that you need to edit web/index.php to remove them in the Yii2 docs. Seems they are only interested in getting you going for development. Yes the index file has comments, but we need to know to look there! If you don't remove them, Yii will load your debug tools, which don't exist. I assume when Heroku receives the push, it runs composer from the "require" block.
As for the Advanced template.. Frontend and Backend index.php files already have the debugging constants correct for dev and production. You just have to run php init --env=Production --overwrite=All on the server (I couldn't get heroku to do this, but another day). The Yii docs have you run init, then select development. This takes everything from the "environments/dev" folder and overwrite them in their locations in your app. This will fail when in development. So you have to switch it to production, which moves your production files into use. I understand why you would have these, so I get it.. Like I said, I tried heroku run bash, then running php init --env=Production --overwrite=All from the apps directory but it didn't seem to make the switch. So my app was missing the frontend/web/index.php file, and many more.
I was wondering how 'frontend/web/index.php' wasn't even in the directory, but further inspection I saw that many directories have gitignore files. So when you 'git push heroku master', 'frontend/web/index.php' along with the rest, never get pushed because they are ignored. So because I couldn't get Heroku to run Yii's init into production, my files just were not there.
Simple fix to get me running on Heroku with Yii Advanced (including adding the 2 mentioned packages to composer.json): I deleted all the gitignore files, ran init choosing production, updated git, and pushed to heroku. It runs :)
Now I need to figure out how to get init to do this for me so I don't have to delete the gitignore files.
As for this question, it is solved. Heroku can run Yii2 basic and advanced. The biggest issue I see is the Yii docs lacking the necessary composer packages to run in production. So I wonder if it's just Heroku needing those packages...
Related
I am trying to get a Laravel 8 project up and running on Hostinger's shared hosting. I realize I'm already complicating things but have successfully set things up besides the components. I am using Povilas' Quick Admin Panel (Livewire ver), and it's this that requires components that are only 'missing' when on production server. Everything runs smoothly on localhost.
I've read that this may be caused by namespace issues - the environment may have case sensitivity (if so, how can I work around?). Other posts explained how each component should be visible in Http\View\Components as well as in resources\views\components. I've also read something on the existence of default/packaged components but can not find documentation on these individual ones.
I am looking for components 'x-application-logo', 'x-dropdown', 'x-dropdown-link', 'x-responsive-nav-link', and more. I do not see ANY of these in my local files, yet it all works fine in a local environment.
Yes, I've seen very many similar questions asked. However, in all of those cases, the askers were able to visually locate their component files, or were using self-declared components...
Has anyone working with Quick Admin Panel had similar issues?
I've attempted:
php artisan cache:clear, config:clear, view:clear,
php artisan optimize,
composer dump-autoload,
recompiling with npm then reuploading files,
composer install (and composer2 install)
I ended up installing a fresh instance of Jetstream to copy over its source files. After a few tweaks I got something to work without errors... As I've come to find out, the entire admin panel that I was working with had wiped itself, and for some reason started requiring an instance of Jetstream?? I have no recollection of touching any sort of configuration regarding this, so either there's a carbon monoxide leak in my home, or Hostinger is deciding to automatically mess with my Laravel files for one reason or another. Thankfully I have a proper local version of my project, which I will use to reattempt.
At work we took back our existing store running on Magento 2 from an external development agency. I need to get the project running in local development (with docker).
I familiarized myself with a vanilla project from the official docs and managed to get it running by downloading the vanilla template with composer, granting the proper permissions on files and folder and running the magento setup:install command.
My question is how do one goes when kick starting from an existing (production running) project?
Do I need to run setup:install again? If I do, why?
What do I need to import from production to ensure any content or configuration created via the admin is also running on my local setup? Should I import the complete Database from production?
I know our setup is using more than just php and mysql, but env.php seems to be listing only db configuration and admin url. Where can I get the complete service configuration informations about what our setup uses?
Anything else I am missing to get started with an existing project for local development?
As someone who is running Magento 2 on a local environment myself, hopefully I can shed some light on this.
If you have a direct copy of the live site, you do not need to run setup:install again.
Ensure you have a copy of the entire Magento 2 site (you can technically ignore the vendor folder, as you can run composer install and it will redownload those files, but that's up to you). Also get a copy of the entire database. Magento 2 is notorious for copying the same data to multiple tables so something could break if you don't have everything.
What do you mean by "service configurations" If you are referring to Magento 2 extensions, that data is saved in the database, not the env.php file. env.php is only for server side configurations, such as the DB information, Caching, and things of that nature. On mine, I use Redis for site Cache, so that would be included in that file as well, as an example.
When you first unpack the site to your local environment, run composer update in the directory. This will ensure you have all the proper files installed. If you are going to run a local dev environment, set the mode to development with the following command: bin/magento deploy:mode:set developer. This will allow you to make changes and to view those changes by just refreshing the page, rather than flushing cache all the time.
All queries are replied correctly by Eric. I am also not sure about "service configurations" you have mentioned here. If this is about third-party extensions/services you can check config.php file for this.
As you can see here: Specifying Dependencies
Google App Engine "Composer runs automatically when you deploy a new version of your application..."
I would prefer it didn't. I have scripts that run prior to deployment to remove all of the unnecessities in composer dependencies that are not needed in a deployed application (documentation, testing, etc.).
My .gcloudignore file does not include the /vendor directory and this is confirmed by the file count on upload. When I checked the deployed source however, the composer dependencies do not match my cleaned local dependencies because App Engine is overriding them.
Not sure why this is a feature in the first place, it seems it would be better to leave this in the control of the developers.
I do have billing enabled and am full featured. Thanks!
EDIT
I added the composer.json and composer.lock files to the ignore file to prevent the update and then the vender directory was missing completely from the deployed source. The vendor directory is not in the ignored file and has been uploaded. If I add a depenency, for example, the upload file count reflects the file count for the added dependency files.
It makes me wonder if something is running after the upload during the deployment to remove the vendor directory. They do have it as being removed by default in the ignore file. I assumed though that by taking it out it would allow the upload and deployment of it (the vendor directory)
I've been working on reproducing your issue and trying to attain exactly everything you described as things you need to happen. And I've found some interesting things.
I wanted to see the exact behavior of a vendor/ folder when you deploy it to GAE and understand exactly what causes your issues, so i followed these steps:
Cloned a simple PHP project just to save time.
Installed composer locally so i can require the dependencies.
I required a simple dependency (so it creates the vendor/, composer.json, composer.lock
composer require phpunit/php-timer
This made me have locally the dependencies so it directly uploads them. Can you try to do that with your composer file before attempting to deploy?
I did gcloud app deploy and it uploaded everything, I still have my doubts as if this is my local folder or generated at run-time.
Then I made a simple .gcloudignore as a test, added test* into it, did a gcloud app deploy, and it uploaded everything except the test folders.
Here you can specify everything that you want to avoid uploading, i think this would be a much easier solution for all your troubles. These are the .gcloudignore formats you can use.
It worked for me like this, hope it can help you out.
Let me know.
I'm a bit fresh to Laravel. I installed it via composer in the xampp/htdocs file. I installed the latest version 5.6.
The install works with no errors, and the file structure is as it should be.
When I run the php artisan serve command from inside the folder, it deletes the server.php file and therefore outputs the error:
This site can’t be reached.
localhost refused to connect.
So I thought why not just add a new file inside and it will work... Well, trying to add new file shows that I do not have permissions to add files to this folder.
I tried a new install a few times, but the situation is always the same.
Has anybody else encountered this problem?
So I realised it was some kind of server problem... well, removed the antivirus, chanhed my firewall settings and everithing works as it should.
My advice to avoid this in the future is to start creating Laravel applications in a folder inside of your My Documents folder in Windows or using /home/{your-username}/projects directory in Unix environments.
What likely happened is xampp has certain permissions that don't play nice with what you need in Laravel.
I've been running a project written in Laravel which has been fun to use.
The setup I use is the vagrant box Homestead configuration so I do the majority of my work on my local machine and push up to the development server once its ready to go. During the installation I had to push up the logs & vendor folder for it to work properly but now I'm at a stage where every commit I do via the command line includes storage/logs/laravel.log which when I then pull down it asks me to stash/commit on the server because they're different.
I've added it to the .gitignore file in the root directory of the project and it looks like this:
/node_modules
/public/storage
/.idea
Homestead.json
Homestead.yaml
/storage/logs/
/vendor/
Vendor doesn't cause me any problems unless I make changes to it so its not much of a bother, its just the logs which will not stop going up. If I use a GUI tool, I can manually tell it not to go up but I want to get it to the point that I can use the terminal to push it up and not worry about logs need stashing on the server.
I believe this is the same for the .env so I imagine a solution will work for both. I have also noticed that PHPStorm have said they're ignored but tracked with git if that helps.
If you take a look at the Laravel repo on GitHub, you'll find the following .gitignore file in the storage directory:
https://github.com/laravel/laravel/blob/master/storage/logs/.gitignore
This comes with the default installation to mark the logs directory as ignored. If you've deleted this by mistake, you should be able to reinstate it and resolve the issue you're having.
Just as importantly though, your workflow isn't following best practice. With respect to "Vendor doesn't cause me and problems unless i make changes to it" - you should never make changes to your vendor directory. This folder is home to third-party packages and plugins, modifying them directly causes multiple issues, chief amongst them:
You can no longer update a modified package without breaking your application.
Other developers won't be able to replicate your installation easily.
In fact, the vendor directory shouldn't be versioned at all. The best way to handle the files within it is using a package manager, like Composer, to do it all for you. This means you can easily switch between different versions of your packages and, by versioning only the composer files, other developers can run composer install or composer update to synchronise their development environment to yours quickly and accurately.