after using artisan make:auth, laravel creates views in storage/framework/views using scrambled file names. I suspect the filenames are created using the app key. Now the problem is that when I port this to the integration server, artisan uses different file names for those views, and seems to create new files with those new names.
How can I tell laravel to use the views that artisan created on my dev machine, even on the staging environment.
For troubleshooting I changed the app key on integration to be the same as my dev machine, but a) it didn't take care of the problem, and b) I'm sure that's not the intent.
Any help is very greatly appreciate
Files stored in storage/framework/views are cached views and basically there's no need to touch them directly.
Related
I've got a local strapi set up with sqlite. I didn't think ahead, sadly that I would need use postgres to deploy to Heroku later.
After struggling to deploy with the project using sqlite, I decided to create a new project using postgres and successfully deployed it to Heroku. Now, in the local project, I've already setup content types, pages and everything. I was wondering, instead of having to recreate what I have done locally, how do I copy what I've done to the new project on Heroku including the database (sqlite --> postgres).
Has anyone done this before or maybe could point me to the right direction?
thank you in advance!
According to this:
https://github.com/strapi/strapi/issues/205#issuecomment-490813115
Database migration (content types and relations) is no longer an issue, but moving existing data entries from one database to another is.
To change database provider, I suppose you just need to edit config/environments/**/database.json according to Postgres setup.
Faced same issue, my solution is to use new project to generate a core for PostgreSQL and then run your existing code base on freshly created PostgreSQL:
npx create-strapi-app my-project and then choose custom -> PostgreSQL (Link)
When manually create a collections that are exists in SQLite, without fields
Run your old codebase with new database config which point on a PostgreSQL (that will create fields that you have in your data models)
Require a little bit of manual work, but works for me. Good luck!
I am currently maintaining a Laravel 5.5 project.
I have a copy from the production that runs on my own computer. Both of the session drivers I use are File.
Recently, I found that the production started unable to save/store any file in the storage/framework/sessions folder.
However, no matter how I change the permission of all the folders inside storage folder to 777, session files just don't appear in the storage/framework/sessions folder, while the copy that runs on my own computer just writes files as usual.
I can't figure out how the problems would be, even search every information I could find, the problem still can't be solved.
Also, I'm not sure what information that is helpful for others to inspect. The only one that might be helpful maybe the host I use of the production is Hostgator.
Oh, I found the problem was at the .env file, the one in the production was modified by someone or occasionally to use cookie as its session driver.
I've neglected this part, while config/session.php didn't have any differences between the two environments.
After I set the session driver into file and ran php artisan config:cache, everything started performing correctly.
I'm having a hard time deploying a Laravel app for test purposes on AWS Elastic Beanstalk.
Followed all sources i could find in web including AWS documentation.
Created a Elastic Beanstalk environment and uploading an application is straightforward as long as i do not include .ebextensions and the .yaml file in it.
Based on Maximilian's tutorial i created init.config file inside .ebextensions with contents:
container_commands:
01initdb:
command: "php artisan migrate"
Environment gets to a degraded state as it finishes to update and i get the following logs:
[2018-11-20T23:14:08.485Z] INFO [7969] : Command processor returning results:
{"status":"FAILURE","api_version":"1.0","results":[{"status":"FAILURE","msg":"(TRUNCATED)...y exists\")\n/var/app/ondeck/vendor/laravel/framework/src/Illuminate/Database/Connection.php:458\n\n2 PDOStatement::execute()\n/var/app/ondeck/vendor/laravel/framework/src/Illuminate/Database/Connection.php:458\n\nPlease use the argument -v to see more details. \ncontainer_command 01initdb in .ebextensions/init.config failed. For more detail, check /var/log/eb-activity.log using console or EB CLI","returncode":1,"events":[]}],"truncated":"true"}
I have been trying different .config files from other instruction resources but none of them seems to work.
I'm running:
Laravel Framework 5.7.5
EB Platform uses PHP 7.2 running on 64bit Amazon Linux/2.8.4
RDS uses MySQL 5.6.40
I really do not know what is going on and would appreciate if you could give any suggestion.
I finally found my way out. Providing some documentation for anyone that hits the same issue.
What I was trying to do...
My main objective was to test a Laravel 5.7 application on a live AWS Elastic Beanstalk (EB) server. I was also in need of a way to visualize data using phpMyAdmin, a tool that fits my need. This is a very simple CRUD app just for learning the basics of both technologies.
What I did (worked)
Followed the normal workflow of creating an EB application mainly using the web console.
Name the application
Chose PHP as a platform
Start off with a base application (do not upload code yet)
Hit configure more options
In security card select your key pair and save. (This is valuable for SSH'ing on your server)
In the database, the card creates an RDS instance. Select whatever options that fit your needs and set a username/password.
Create environment.
After a while, you should have all resources created by EB (EC2 and RDS instances, security group, EIP, Buckets, etc) in the app environment.
Preparing your Laravel application is a straight forward process. You must not forget to change config/database.php to read server variables. My approach was to define them at the start of the file.
The main sources of troubles reside in configuring your server instance to include all software and configuration needed by your app and specific needs. This is done by including a .yaml file inside .ebextensions folder. This folder should reside in the root directory of your Laravel application. It's also a good idea to check your syntax before submitting another app version to EB. As per my needs, I used this script which basically installs phpMyAdmin as I deploy a new version. Specifically for this startup script, environment variables should be defined, namely $PMA_VER, $PMA_USERNAME, $PMA_PASSWORD for phpMyAdmin to work. You can create more environment variables in the software tab of your EB configuration page. Read the docs.
Another detail that might cause issues in running commands at startup using YAML script (specifically migration) is caused by Laravel and MySql versions. As for example, I am using Laravel 5.7 and the default MySQL version option in EB RDS creation wizard is something like 5.6.x. This will throw issues of the type:
Illuminate\Database\QueryException : SQLSTATE[42000]: Syntax error or access violation: 1071 Specified key was too long; max key length is 767 bytes (SQL: alter table `users` add unique `users_email_unique`(`email`))
If this is your scenario, despite you should have already googled and sorted out that adding the line of code Schema::defaultStringLength(191); to the boot function of your app/Providers/AppServiceProviders.php file will do the trick.
You can do a typical migration passing the script:
container_commands:
01_drop_tables:
command:
"php artisan migrate:fresh"
02_initdb:
command:
"php artisan migrate"
This will drop existing tables avoiding conflicts and create a new one based on your code. You can read more logs from your server by SSH'ing and getting content of /var/log/eb-activity.log.
I just uploaded my laravel project to my shared hosting and was wondering what things and changes to configuration should I make to make the project work?
My typical checklist:
Modify the document root to the /public folder
Make the /storage and bootstrap/cache folders writeable.
Set up the database
Modify the .env file to suit the live environment
Run php artisan migrate
This should get you up and running, or at least bring you to a point where the errors are detailed enough to work things out
I have two laravel apps, the first is used as a Server Management System (SMS) that creates a host on the server. When this host is created it does a git clone to bring in the second laravel app that is used as a CMS for that host.
What I am trying to do is create a plugin within the SMS so that you can just select a check box and it will install the CMS for you when you create a new host. I have most of the code in place and I am testing locally and everything works grand until at the end when I try to install the migrations, when I try to run;
'php artisan cms:update'.
I also tried;
'php artisan migrate'.
What ends up happening is that rather the command being run against the CMS database, it is affecting the SMS's database adding a couple of tables and breaking the SMS database. I have done a 'pwd' and checked to make sure I am in the correct directory;
'/Directory/Directory/host/cms'
As it makes more sense for someone to read all of the code rather than snippets here is a link to the plugin:
CODE LINK
So to clarify what I need is to be able to test the plugin locally so I need the migrations to install into the correct database, and make sure the CMS works before I push to production. If anyone could shed some light on why the migrations is affecting the SMS rather than the CMS it would be greatly appreciated.