After deployment to Forge, my Laravel Livewire site is throwing out a server error. I am using Digital Ocean as well. In the Forge site logs it says that my livewire view can't be found. The app works perfectly on local. Any ideas what to do?
I have attempted these commands
Here is the site logs pt.1
and pt.2
I have followed the path of my files and I can confirm there aren't any spelling errors, and to my knowledge, the names of my files are not an issue, since I have followed conventional php artisan make:livewire folder.FooBar as the documentation states.
One thing I might think was that I changed the names and rearranged the folders maybe 20 commits before my deployment commit, but I can't see that affecting anything. Please if you have any suggestions I'd love the help
Here is my github Repository
It's a matter of case-sensitivity.
In your linked repository, the folder for your resources/views/livewire/home/home- index.blade.php, is actually called resources/views/livewire/Home/home-index.blade.php, which is a different animal altogether. Notice the capital H in your Home folder. The same thing applies to the other folders within your Livewire resources folder.
Having the folders with capital letters can work in some environments, and not work in others - for different reasons, and to avoid it, all your folders within your resources directory should always be named with lower-case.
For future reference, this is how I create Livewire components with artisan, and then don't touch the names without using the appropriate renaming command.
php artisan make:livewire Home/HomeIndex
If you want to use the kebab-case notation, note that it's all lowercase.
php artisan make:livewire home.home-index
As #Qirel pointed out, my folder names were not correct. I didn't catch the error because my local file tree was all lowercase [![lowercase][1]][1]
But my master branch had not caught that change long ago when I changed it
[![capital][2]][2]
Thank you for the help guys
[1]: https://i.stack.imgur.com/1rGns.png
[2]: https://i.stack.imgur.com/fQsex.png
Related
I'm building a simple web application using CodeIgniter 3.0.3, and have run into a lot of issues regarding capitalization consistency. The CI 3.x documentation clearly states that Model files should be ucfirst and referenced using lcfirst i.e. file application/models/Foobar_model.php, loaded using $this->load->model('foobar_model'), and called with $this->foobar_model. Source: Official CI 3.x User Guide.
When I follow those rules, I get the following error message Unable to locate the model you have specified: foobar_model. Referencing the model using Ucfirst i.e. $this->load->model('Foobar_model') and $this->Foobar_model generates the exact same error message. I am able to resolve the issue by making my filename lcfirst application/models/foobar_model.php while the class name inside the file remains Ucfirst. As long as I name my file lcfirst foobar_model.php, it does not seem to matter whether I use Ucfirst or lcfirst to reference it from inside my controllers.
Strangely, I have found that I need to use application/controllers/Ucfirst_controller.php for my controllers with case-sensitive routing i.e. $route['default_controller'] = 'Ucfirst_controller';. I receive a 404 error when trying to route $route['default_controller'] = 'lcfirst_controller'; to application/controllers/lcfirst_controller.php.
Everything I have found on stackoverflow and other forums for CodeIgniter model and controller issues seems to involve people using lcfirst instead of Ucfirst on CodeIgniter 3.x, or using Ucfirst instead of lcfirst on CodeIgniter 2.x.
Basically my question is where is this case inconsistency coming from and how can I fix it? I want to follow standards so that others can join my project at a later point.
Other Info: I don't think that this should matter, but just in case. I am developing on LAMP on an Ubuntu machine with ext4 file formatting which is obviously case sensitive. I plan to deploy my project with Google Compute Engine running debian-7-wheezy with a HHVM stack. I am currently developing with just one partner, who is developing on a MAMP stack with non case-sensitive file formatting so he does not experience any of these issues.
Thanks everyone :~)
My system/core/Loader.php file was not updated properly when I updated from CI 2.x to 3.0.3. Properly updating this file resolved my case inconsistency issues, I am now able to name my models and controllers Ucfirst.php and reference them as $this->lcfirst and everything works properly.
Hello, I wanted to try creating a Laravel Application and I am really new to this.
I tried all the best I can to analyze and implement the solutions of other people but to no success.
So I have followed the methods in configuring the Laravel App.
The ssh key has also been created in the homekey file as seen from the Homestead.yaml file, I edited it.
But when I try to do 'vagrant up'.
This error message begin to show.
It seems looking for the directory of .homestead but even I can't find it.
I don't know what step am I overlooking.
I was developing with yii2 and phundament and works all super nice in my local box and my host server but what i still confuse is about how to move from dev to prod.
Which folders can I delete from the final production?
I need the app to work in a raspberry Pi that's why i need to reduce the files in production.
I understand that you are deploying your Yii2 app on a limited-space raspberry Pi, so here are some suggestions (it might be worth adding that back in to your question, as that justifies the reason for your question).
You can't just deleted files or folders. Yii needs them to run, but you can configure Yii to use less of them.
Changing your logging levels, or setting a smaller flush interval will save a lot of space in your runtime folder.
You could also combine and minify all your assets (js and css), so that only one set of assets gets published. You would need to do this manually, I don't know of any way of getting Yii to do this automatically.
Make sure that you actually need all the vendor components that are present. If there are some you don't need, like imagine, or swiftmailer, then remove them using composer, which will deleted them from your vendor folder and also remove the autoload references.
If you are finished testing, you could probably remove the 'tests' folder
but try just renaming it first to make sure everything still works.
Finally, if you're not using them, you could probably remove the mail and migrations folders and their contents, but that's not likely to save much space.
There may be other space-saving methods, but that's all I could come up with!
I am trying to work what the point of the environments folder is.
Originally I had the idea that you could point the webserver to the different dev and prod folders in the environment folder but after reading up a bit I realise this is not the case.
In Yii 1 you would solve this by just having multiple index.php's i.e.:
index.php
index-local.php
So the question is what benefit does this new environment structure actually give me over the old way?
I've found environments very useful in allowing me to keep a common code base for multiple client projects (based on Yii App Advanced) and setting up a different environment for each specific client, keeping their custom code private and separate.
To do this I store the environments folder in a separate git repo from the rest of the code and pull down the relevant folder on a client/project basis.
This lets me use a base common code for all projects and add/override any file for a specific client or project whilst still allowing separate dev/prod config settings. If the client uses other developers too, they are also catered for. In this way, only common code I choose will be shared amongst clients and custom code will be kept private.
I've also moved the composer.json file into the environments folder so I can pull in different extensions per client/project keeping those private too.
That init command can be a very powerful tool and you don't have to limit yourself to the template provided by the core developers.
If you don't need environments, then don't use them, but I assure you some people will find it very useful.
Yii2 documentation in WIP, but you should read this :
https://github.com/yiisoft/yii2/blob/master/docs/guide/apps-advanced.md#configuration-and-environments
You need to use yii init command to switch between these environments.
EDIT :
This new environment feature is more than just use different config file. You can use different folder structure, different entry script...etc
Personnaly I won't use this feature, I don't need it (I will use a different entry script as with Yii 1), but I think this is not useless.
I think you didn't get the real purpose of environments introduced in Yii2.
I'll try to explain what was the main purpose of adding environments to yii from the developers point of view on an example and hope you will really appreciate its usefulness.
Let's suppose for a moment that you are a team of developers (e.g. 5-7 person) working on mid-to-large project implemented in Yii. To effectively work on that project your team decides to use some CVS or SVN (e.g. GIT) and keep all the files of the project in repository in cloud for the whole team. That's de facto standard while working on mid-to-large projects in teams and nobody will resist that it's the only comfortable and easy way.
Ok, now let's suppose you use Yii 1.x or Yii2 with the approach of different entry scripts to differentiate between local (development) and production environments to connect to db or set some other environment specific configs. Everything is ok and working. But suppose your team members implemented something new on the project and you check out repository to work on updated version and you suddenly find out that your local config file (in this case entry script with config) is overwritten with other team member's file who pulled the changes to repository (because each of you is using your local machine db with other database name or OS, or config, or simply because your team uses one local development server db, but you are on vacation and can't use anything except your local machine).
So generally Yii2 environment adds more flexibility for using different environments each with it's own specific configurations while using also general (common) configs when working in teams on mid-to-large projects hence why the example in guide is given on advanced app project.
Surely you can overcome everything stated above with some solutions or .gitignore which is used by default to overcome the problem stated in Yii2 with environments. But:
Why bother if everything is already done?
and
It was just one little example of usefulness of Yii2 environments. More depends on the project and your imagination.
Overall Yii2 is great product. Not only it adds many new features to already great framework, but it also is more robust and flexible than Yii 1.x (despite the fact that Yii 1.x was already very robust).
As for Laravel or any other PHP framework, it really depends... Everyone will find his/her own favorite.
For those who are tired of copying files around, I created a useful script that you can run in background to keep the files in sync on your dev environment:
File sync-env-files.sh
#!/bin/bash
ENVIRONMENT_DIR="/var/www/example.com/environments/dev/"
DIR="/var/www/example.com/"
while [ true ]; do
for envFile in `find $ENVIRONMENT_DIR -type f`
do
file=${envFile/$ENVIRONMENT_DIR/$DIR}
if [ `stat -c "%Y" $file` -gt `stat -c "%Y" $envFile` ]; then
#echo "copying modified file $file to $envFile"
/bin/cp -f $file $envFile
fi
done
sleep 2
done
Then run the script in background or add to cron with flock
nohup server/sync-env-files.sh >/dev/null 2>&1 &
I would like to mention in addition to #AngelCoding, since this question still gets seen, that I use the environments folder lots now and definitely see the point of it.
The very first things I do in any open source project is create one project for the code base on GitHub and then another, private, one on Bitbucket for the configuration, in other words the environments folder.
Having this folder has made it a lot easier for me to separate my configuration into a private repository.
So the environments folder has a lot of uses and really helps to separate configuration for easier usage even if it does not seem like it initially.
I have a project written in Kohana 3. The /system subdirectory is pulled in via a git submodule:
[submodule "system"]
path = system
url = git://github.com/kohana/core.git
After version 3.3 it seems all classes were changed to the first letter being upper-cased. ie core.php is now Core.php. This didn't seem to have any effect locally on my mac but now that I've uploaded my app to hosting provider Fort Rabbit I'm getting an error that it failed to open system/classes/kohana/core.php. I suspect this is because that is now system/classes/kohana/Core.php
Can anyone advise the best way to proceed? Do I need to change every instance of require SYSPATH.'classes/kohana/classname'.EXT; to the uppercase equivalent?
Basically yes. In 3.3 when you call a class, you have to be case sensitive. The same applies to the file names. Migration guide explains this quite well.
You can also check this post to automate the upgrade.