I am migrating from shared web hosting to Heroku and can't figure out how to user Composer properly.
I have my app pointing to public_html folder, with the composer.json file in the root folder above this. This would generate a vendor folder in the root folder, which (for reasons I don't understand) I was unable to access when I tried including the autoload.php file in my code (e.g. require_once('../vendor/autoload.php')).
My solution to this was to move composer.json into public_html, but that caused no end of problems with Heroku not finding it, so I moved it back. I then changed the vendor directory in composer.json to point to public_html/vendor.
This had the desired effect, except now my app won't run because it can't find PHP, presumably something to do with the new location of vendor.
Is there a way to either:
Configure composer.json to have Heroku put everything except PHP in public_html/vendor, and put PHP into a root vendor directory, or
Access files above public_html from within my code to allow me to include autoload.php?
OK, it turns out it was a relatively simple fix that I just figured out myself. I'll post it here in case anybody else happens to make the same mistake.
If you change vendor-dir in composer.json, you also need to change the Procfile from
web: vendor/bin/heroku-php-apache2 public_html/
to
web: public_html/vendor/bin/heroku-php-apache2 public_html/
Related
This is Bablu Ahmed. I want to upload my laravel 5.5 project into cpanel and my domain is an addon domain name is w3public.com and it's root directory is not inside the public_html it is outside the public_html (www.w3public.com). I have separated the project's files into two directories, one is www.w3public.com and another is laravel and I moved public folder's files into www.w3public.com and all other files into the laravel folder in cpanel that is given in screenshot below. I have also modified the index.php file of www.w3public.com as follows:
require __DIR__.'/../../laravel/vendor/autoload.php';
$app = require_once __DIR__.'/../../laravel/bootstrap/app.php';
But it is not working. Can anyone help me with appropriate solutions?
Screenshot:
Your application should be installed in www.w3public.com and then change the root path from cpanel domains to the public folder inside laravel.
The best way to transfer files is git or the likes, but if they don't have it (usually is the case in shared hosting), you should use a ftp client, and if they don't allow that either, you can upload files/folders from cpanel (way too slow sadly).
If you use git be careful since by default vendor folder is in the .gitignore (you have to run "composer update --no-dev" after all the files are transferred)
Make sure also that your ".env" (usually in .gitignore too, so you prob have to make one) file have your server database info.
I've got a single page that I want to demo for a non-profit I'm volunteering for, but the Heroku deployment just gives me the error from the title. The file directory is such:
--hotlabdemo
--assets
--javascript
home.js
--css
style.css
--images
a few images
composer.json
home.html
home.php
I have another page hosted there that is more or less the same thing, but a little different. The HTML/JS/CSS are different, but nothing that should prevent accessing the "/" on the server.
For reference, the php and composer for both pages are
{}
and
<?php include_once("home.html"); ?>
I opened a support ticket with Heroku, but was told
"Unfortunately, this appears to be an issue that falls outside the nature of
the Heroku Support policy. I recommend searching our Knowledge Base or
asking the community on Stack Overflow for more answers."
Any thoughts on why I might be prevented from accessing the page?
You can most likely fix this issue by creating a file "Procfile" in the root of your project. https://devcenter.heroku.com/articles/procfile
NOTE
Procfile naming and location
A Procfile is a file named Procfile. It should be named Procfile exactly, and not anything else. For example, Procfile.txt is not valid. The file should be a simple text file.
The file must be placed in the root directory of your application. It will not function if placed in a subdirectory.
The Procfile should define that you want to run PHP Server e.g.
web: vendor/bin/heroku-php-apache2 web/
https://devcenter.heroku.com/articles/getting-started-with-php#define-a-procfile
Following an audit, I've been tasked to remove extraneous files from the Twig 1.x vendor directory in one of our sites. Planning on removing /twig/twig/doc, /twig/twig/test and see if anything breaks.
What about /twig/twig/ext/twig/run-tests.php, or the entire "ext" directory?
Does anyone have prior experience weeding a default Twig 1.x installation for production environments? Any assistance or advice gratefully welcomed.
The correct action would be to update your site's layout so that these files are outside your web server's document root -- then you don't have to worry about what to delete and what to leave. You probably have something like this, where your web server's document root is pointing directly at /path/to/project:
/path/to/project
/lib
foo.php
bar.php
/twig
/twig
/doc
/test
index.php
This means anybody can directly request http://yourdomain.com/twig/twig/test/some_file.php
What you want is more like this:
/path/to/project
/public
index.php
/lib
foo.php
bar.php
/twig
/twig
/doc
/test
Then configure your web server so that its document root is /path/to/project/public. Then your application code can still include() things in /twig and /lib, but your web server won't directly serve them.
If your removing files from the vendor directory they'll come back the next time you do a composer install so this seems kind of pointless.
The files you mention (docs and test) are causing no harm other than taking up space as they are not directly called, but that's just a downside to any package management system. Like #Alex said as long as they are not publicly accessible there is no need to worry.
If you really want Twig without the extra files you could fork the project, move it into your own Git repo then reference that in your composer.json instead of the official one - but you will miss out on any updates from Twig.
We're running on Apache, so the easiest solution was to simply add a .htaccess file to the top vendor directory:
# Prevent non-local access to the vendor directory.
Order deny,allow
Deny from all
Directory structure:
/root
/vendor
.htaccess
/twig
...
/includes
...
Now the PHP scripts continue to have access, but external attempts to view anything inside the vendor directory return a 403 error.
I've never used Composer before, but installed it so I could set twig up the recommended way.
I now have composer.json and composer.lock files in two separate directories. How do I determine where they SHOULD be? I assume they certainly shouldn't be in my public html root, as one of them has managed to be?
The composer.json file should be created at the topmost directory of your project, i.e. the top directory that is in version control. Subdirectories of this directory likely are for example the "public" or "htdocs" or "www" directory which is the document root for the web server.
By using Composer, this directory will also get a "vendor" directory where the packages are being placed, as well as the composer.lock file which records the exact versions being installed.
Do commit both composer.json and composer.lock. Don't commit the vendor folder, put it onto the ignore list.
I am trying to deploy my laravel application on a shared hosting. It should be deployed in www.subdomain.something.com
My folder structure is:
/laravel
app/
vendor/
bootstrap/
server.php
artisan
composer.json
composer.lock
phpunit.xml
/public_html
subdomain/
index.php
My index.php have the following paths:
require '/../../laravel/bootstrap/autoload.php';
$app = require_once '/../../laravel/bootstrap/start.php';
My paths.php
'app' => __DIR__.'/../../laravel/app',
'public' => __DIR__.'/../../public_html/subdomain',
'base' => __DIR__.'/../../laravel',
'storage' => __DIR__.'/../../laravel/app/storage',
Can anyone see what I am missing? I tried google, and found a bunch of step-by-step explanations but nothing seems to work - It results in a 500 internal server error.
Thanks for any feedback
Wesley
Follow the first rule here.
If you use the first rule then everything should work fine. But somehow if you face 500 Internal Server Error then login to ur server public_html directory through ssh and give the following command.
sudo chmod 755 -R laravel
chmod -R o+w laravel/storage
Here laravel is your Laravel project directory.
Make sure you have write permissions to app/storage/ and all the sub directories. This sounds like the culprit but if not then see if you get any errors in the app/storage/logs dir. If not see if you can parse the server logs.
I was having similar problem and found the solution.Maybe someone can get help with this,
Install LARAVEL 5 Locally Same as Share Hosting Directory (Deploy L5 Share Hosting Solution)
I tried to deploy my first Laravel 8 application on shared hosting on DreamHost, and did encounter some issues.
First I was not able to use composer. Composer 1 was available however, I was unable to upgrade it to Composer 2. ( Was getting errors)
Finally, I ended up uploading all files from my local system to the subdomain root folder (e.g. cota.mydomain.com)
When I tried cota.mydomain.com, I got 404 error.
When I changed url to cota.mydomain.com/public/index.php, the application started working. However, all href links which were defined like href="/home" or href="/client/create" started giving 'not found' errors. To fix this issue I had to use named routes in href, e.g. href=" {{ route('client.show',['id'=>$client->id]) }}". This solved the issue, however, the URL displayed included public/index.php, e.g. cota.mydomain.com/public/index.php/client/show/1.
To further fix the problem, I changed the web folder (root folder) for my subdomain to include public, i.e. cota.mydomain.com/public
Next I added an index.php in cota.mydomain.con with the following contents
header("Location: http://www.cota.mydomain.com/public/index.php"); die();
This fixed all issues, including remving public and index.php from link URLs.