I'm using the mPDF library for PHP, but the current release is not compatible with PHP 7. Various issue threads on Github suggest using the current Dev version; but it appears that simply downloading the Zip file excludes important files (including the /vendors/ directory and the autoload.php file.)
The developer seems impatient with people asking this question, and actually told somebody "go ask on StackExchange". So... here I am.
How the heck do I download the entire package from the development branch?
As stated in the comments, the package you are trying to use is being installed through Composer
Install Composer to your machine if you did not do it previously
Unzip file to directory of your choice
Navigate to such directory in command line / terminal
Run composer install
Related
I am attempting to install the Microsoft Azure Storage PHP Client Libraries for the first time and am encountering difficulties. I am following the instructions found at https://github.com/Azure/azure-storage-php but I don't find them sufficiently clear. Step 1 under the Install via Composer header says,
Create a file named composer.json in the root of your project and add the following code to it:
{
"require": {
"microsoft/azure-storage-blob": "",
"microsoft/azure-storage-table": "",
"microsoft/azure-storage-queue": "",
"microsoft/azure-storage-file": ""
}
}
There is already a composer.json file in the azure-storage-php directory created by the
git clone https://github.com/Azure/azure-storage-php.git
command. Am I supposed to overwrite the existing composer.json file with the Step 1 instructions? Also, how does my PHP program reference the necessary libraries? I understand I will have use statements like the following code in my PHP program:
use MicrosoftAzure\Storage\Blob\BlobRestProxy;
use MicrosoftAzure\Storage\Common\Exceptions\ServiceException;
use MicrosoftAzure\Storage\Blob\Models\ListBlobsOptions;
use MicrosoftAzure\Storage\Blob\Models\CreateContainerOptions;
use MicrosoftAzure\Storage\Blob\Models\PublicAccessType;
You may rightly discern that I am new to composer installs. It seems to me that the instructions found in https://github.com/Azure/azure-storage-php are not sufficiently clear for a composer novice. Thanks for the help.
I have figured out my problem and it has to do with how I read the installation instructions in https://github.com/Azure/azure-storage-php. There are several bold subtitles and I read Install via Composer as a continuation of Download Source Code when in fact Install via Composer is independent of Download Source Code. Most technical people are familiar with the software installation paradigm of downloading the software and then installing and that is how I thought this was to work. However, the instructions contained in Install via Composer can be followed without performing any of the instructions found in Download Source Code. That is how I got this to work by beginning the installation at Install via Composer and ignoring the previous. I am sure an experience composer user would have known what to do, but for a composer novice I think these instruction could be better written.
Bit of a strange set up but have come across a project where Composer has been used in a local environment to get a project started. The original developer did not have ssh access to the production server therefore he used Composer locally and uploaded the 'vendor' directory from his desktop to the server using FTP.
I now need to add the PHPMailer package so have done the following locally on my Mac:
cd Desktop/
composer require phpmailer/phpmailer
This has created the following structure on my desktop:
Desktop/composer.json
Desktop/composer.lock
Desktop/vendor/autoload.php
Desktop/vendor/composer/*
Desktop/vendor/phpmailer/*
Which of these do I need to upload through FTP? I realise vendor/phpmailer/* is the package I want, so will need uploading.
What about the others? I already have an autoloader configured so guessing vendor/autoload.php is not required here?
composer.json I could add the package to what's already there, e.g.
"require": {
*other packages here*
"phpmailer/phpmailer": "^5.2"
}
But I wasn't sure if that's necessary because I'm not going to be using ssh/Composer on the server to run any updates?
The usual workflow would be:
Checkout the current version from the version control.
Add dependencies via command line composer require new/package.
This will download the new package and update the autoloading.
Test the result locally or on a test website environment.
If happy with the result, upload the whole folder to the production server.
There may be several exceptions from this general workflow:
ad 1: If there is no version control, you'd probably better of starting a local git repo right now, and download the current production state into it as the first commit. Not having version control will make things harder, especially going back to known working versions. And because the files on the production server are probably unmanaged, you'd also check in the vendor folder into your newly created version control just to avoid canceling any changes that had been made to these files.
ad 2: Manually editing the composer.json file sometimes is a faster way to get what you want if you know what you are doing, but you'd have to correctly edit the JSON. For me it usually is too much hassle if I already have a command line ready. The command will also select a matching version that fits into the already installed dependencies. Manual editing may lead to version conflicts that you'd have to untangle. Remember to only install dependencies that work with the PHP version in production. You probably should run composer config platform.php X.Y.Z in order to add the production version of PHP into the composer.json file, which prevents Composer from installing dependency versions based on your development PHP. Adding the -g switch will add this setting to your global (user) setting instead, which will affect all composer operations you start, also for other projects.
ad 3: Manual editing will require you to run composer update on the command line, so there's probably no reason to not do composer require instead.
ad 4: How this could be done is entirely dependent on what environment you have to work with.
ad 5: At this stage you have assembled all files necessary to create a working website. Uploading them to production will always result in a working website unless the upload fails somehow. You could also use some "upload first to temporary folder, then move on the server" approach if you fear FTP would be unreliable. Some people take a different approach: They have a git repository on the production server and they simply push the version that should go live onto that remote repo. Some post-push scripts will run composer install then. This automated approach will also work (but not using FTP), but has the higher risk of something failing during deployment, and probably has no easy way back to the previous situation.
So in the end I'd say that uploading the whole folder structure via FTP (well, that protocol is insecure itself, better replace it with FTPS (FTP with SSL), SFTP or SCP) is better compared to running Composer on the production server.
Your specific question regarding which folders to upload: All of them. Especially upload the whole vendor folder. It contains the current autoloader and all dependency packages the software needs. If you worked correctly, you downloaded the existing composer.json and composer.lock file together with everything else and added the new dependency to it. This has changed both these files, added the new package to the vendor folder and the classes to the autoloader.
Don't fiddle with uploading only parts of the vendor folder, or manually editing a component of the autoloading. You will only create surprises for the developer coming after you if you do some aspect incorrectly, and it also takes more time. Composer is a very good tool to manage dependencies - use it!
You could copy the composer.json from the server to your local server, add the requirements and run composer update.
After that you can copy all files (composer.json, composer.lock and vendor folder to your server)...
Or you can copy local vendor/phpmailer into servers vendor folder, search for the entry of phpmailer in vendor/composer/autoload_psr4.php and add it to your servers vendor/composer/autoload_psr4.php.
Using this method also add phpmailers dependencies the same way.
composer depends phpmailer/phpmailer
I have a git project with one branch, I´m trying to clone all files in my local folder, but I can´t get the vendor folder. I would like to know if I can do it in other way to get also vendor class.
I´m running this:
git clone -b branch_name repo_URL
As I say, I don´t get one folder. What I need to do it to get all files?
PD: I can´t download a ZIP of the project.
You are not supposed to find that vendor folder in your repository. It would be useless redundancy.
In modern PHP projects, Composer is being used to manage external dependencies. When running composer update, it reads a file composer.json (which should be present in your repository) to find the most recent versions of the external packages to be used.
This creates a file composer.lock (which should also be in your repository) with the exact versions and commits that got downloaded. If at any later time someone (like you now) wants to recreate the contents of the vendor folder, they run composer install, which will try to get everything that was once downloaded.
So the first step for you is to download Composer, then run composer install (depending on your way of downloading, it might also be php composer.phar install or something close to that).
Reasons for composer install to fail is that dependencies can no longer be downloaded because they were removed from the internet, or that the project is too old and has too old versions of said files so that it does not run with current versions of Composer (although this should be very rare). In any case: If you encounter errors, ask a new question here with all the details, including the full output of the Composer command.
The reason why you don't get the vendor folder is because the vendor folder never went up to the git repository. If you see the .gitignore file, you will notice a :
/vendor
This tells git to ignore that folder and not to send it up to the git repository when you are pushing. There is no way for you to get that folder unless you find the original project before you pushed to the git.
I intend to use single phar file with digital signature to deploy a web application. Combined this with event sourcing would make me very easy to follow release early, release often philosophy...
I am using composer as package manager. What I am uncertain:
How to pack the vendors with my application into a single phar?
I am not sure how composer installs a vendor, but I think it can install them as phar files as well. I found almost nothing about phar-s packed into other phars.
Is composer's autoloader prepared to do that, or I have to do some modifications?
Do I have to install composer on the server? (I have no CLI, and I have no rights to do that. Bad for me, yes.)
How can I filter out automatically the tests and documentations of my application and its dependencies. (I want to have a small release package.)
To answer some of your questions:
Composer does not install .phar files as the dependencies. In fact, those common packages that do come as .phar file (namely PHPUnit) do offer .phar as an alternative to using Composer, which is mutually exclusive. So you'd simply run composer install, get a directory tree of your own files and vendor files, and can then add these all into the .phar file you are about to create.
Composer autoloader does use __DIR__ to know where it is, and where other files are relative from this constant. This should be compatible with .phar files.
You have to install Composer on the machine you intend to create the .phar files on.
Filtering unwanted files is the task of your build script that creates the .phar files. It is not the task of Composer.
Note that there are already libraries that help you creating .phar files. Have a look at kherge/box, for example.
I am currently trying to install Omnipay into my Codeigniter project. I am stuck on windows because I do not have ssh access to the box where this needs to run on. So far I have gotten a new directory in the project root that is named "vendor" and it contains a lot of empty directories referring to Symfony (for what reason is beyond me).
Then I get a runtime exception that I need to enable the openssl extension in my php to download the necessary files and this is where I am stuck at. I don't run WAMP on my computer and I just use the php.exe I downloaded to work with netbeans.
Isn't there an easier way to get omnipay to run? Like just download the files from somewhere and plug them into my project like normal? It seems to be an aweful lot of headache to get a simple library to run in my CI project.
Please forgive my ignorance towards composer but I currently see no benefit of using it for this particular project.
You can "just download" the files here: https://github.com/omnipay/common/archive/master.zip
The problem is, Omnipay depends on Guzzle (an HTTP library), and Guzzle depends on some Symfony components. So you will spend the rest of the day downloading dependencies and making sure you have all the necessary files. That is the problem Composer solves for you.
I don't have any experience running Composer on Windows, but I would start here:
http://getcomposer.org/doc/00-intro.md#installation-windows
Using the Installer
This is the easiest way to get Composer set up on your machine.
Download and run Composer-Setup.exe, it will install the latest
Composer version and set up your PATH so that you can just call
composer from any directory in your command line.
Once you have Composer installed, you should simply be able to make a file named composer.json in your project root, with the following contents:
{
"require": {
"omnipay/omnipay": "~2.0"
}
}
Then use the Command Prompt and cd to your project's directory, and run composer update to download the Omnipay files and all their dependencies.