I am trying to write a webpage that will present to the public the contents of one of my Google Calendars. The standard iframe doesn't give me the format I'd like and I also want to embed some schema.org event information, update and submit a sitemap, etc.
As I'm fairly experienced with PHP, I'm trying to extract data from the Google Calendar API. I looked at Google's quickstart https://developers.google.com/calendar/quickstart/php but it assumes a level of knowledge I don't possess.
It seems I need to use something called "composer" and tells me I need to do "composer require google/apiclient:^2.0" but I'm unclear where exactly I type this - I can't see anywhere obvious in cPanel - or maybe it goes at the start of my PHP code?
Also, I note that the sample code is command-line only and I can't find code anywhere that would appear to be capable of running as a PHP web page. Is that because it's just not possible?
Composer is a dependency manager like bower, npm, yarn etc., the list goes on and on. Firstly you'll have to install composer here and add it to your PATH variable (method depends on OS).
Afterwards, when you create a directory for your project in the www-folder of your WAMP/LAMP or another folder acting as webroot, you can execute the composer require command. This will generate a folder called 'vendor' (with your dependency as a subdirectory) and a composer.json & composer.lock file, the latter 2 files will contain all the 'required dependencies' of composer.
You can then include the dependency using the require_once()-function in your PHP-script.
Hopefully this helps.
Cheers.
Related
Using composer config extra.foo bar I can set custom data in composer.json and according to the documentation composer scripts can read it using $event->getComposer()->getPackage()->getExtra()
I would like to read it in a regular script (installed as a vendor binary) so the binary can be configured by the user, e.g. the binary requires a configuration file which I would like to put in extra.config.
Does composer support this or do I need to manually locate and parse composer.json? Is there a better solution for letting the user add configuration?
The documentation part you are refering to is about PHP-Scripts that get triggered as event-handler during a composer-invocation. So composer runs and provides the configuration-information while invoking the script.
When I understand your approach right, you want to be able to read the information while running your own script without composer. Then - as composer is not involved - composer can not provide any information.
So what you could do is read the composer.json file, parse it as JSON and get the for you relevant information from it.
But then it's nothing else than reading any other configuration file. So I would use a separate file for configuration. That would allow you to use a config also for projects that don't use composer (whyever one would want to do that...). And separation of concerns is also a good idea!
You perhaps might want to have a look at f.e. phpunit, phpcs or travis on how they handle their specific configuration issues within their scripts.
I'm a bit confused about where something like this belongs to Laravel.
I want to write a web service client wrapper in laravel, and I want to access it like this:
\MyWSClient::getSomeInfoAbout($someId);
then the code will connect to the web service to http://www.someapi.com/api/getSomeInfoAbout?id=$someid&type=json with OAuth2 or some token requests, then fetch the data, keep token information until it expires, refresh token if needed etc.
But where will I put the code? In the vendor directory as a new package? I'm moving this code from a computer to another computer except vendor,storage and node_modules folders, because they are huge and when I do this, I will have to move only one folder in the vendor directory. And I'll need to publish a package under development to composer if I want portability etc.
Is there any other way to do something like this?
I think I've found the answer.
First I needed to use jeroen-g/laravel-packager package to create a new package using artisan console. I could've done that by hand, but I didn't know the required files.
Second, I've created a new package in the packages folder with my desired class name.
Third, I've added the provider and the alias for the class in app.php.
After that, I've created a test method in my controller and wrote a route for that. I called the static method I've written in the SkeletonClass the packager created for me.
And it worked with some tweaking after creation.
I've used php artisan packager:new tpaksu mypackage --i command for an interactive package creation which is cool.
Note: I've just learned the existence of this package, I'm not advertising it :)
Our current development setup uses a single Subversion repository containing multiple projects, each with branches, tags, and trunk. We then use a "sparse checkout" to select the projects, and branches of those projects, to work with.
The result is that the directory structure of a working copy matches that of the repository, including branch information, and we never use svn switch. (This style of working will probably be familiar to anyone who uses SVN, but may be surprising to those who don't.)
We are thinking of using Composer to manage both external and internal dependencies, but I'm not sure how this can work with the sparse checkout style of working.
I would like some way of using a directory within the existing checkout to satisfy a dependency, rather than each "root project" needing a separate copy.
For example:
sites/Foo/trunk
depends on lib Aaa, so references lib/Aaa/trunk
depends on lib Bbb 1.5.*, so references lib/Bbb/branches/release-1.5
sites/Bar/trunk
depends on lib Aaa 1.0.*, so references lib/Aaa/branches/release-1.0
depends on lib Bbb 1.5.*, so references lib/Bbb/branches/release-1.5
At present, if I edit the code in lib/Bbb/branches/release-1.5, I can test those changes on both sites, without needing to commit one and update the other.
Is there any way of using Composer to manage these dependencies?
(PS: Please don't answer with "give up on SVN, use Git, it is teh awesomez"; that is an answer to a different question.)
No - I do not believe that you can do this with Composer as standard: it expects to copy the files from whichever source (Packagist/VCS/Zips) to the local vendor folder, which is not what you want.
That said, I believe there are two potential ways you could get this working (at least in part):
Autoloader
You could try using the autoload field in the composer.json file to include the correct files into the project. You would still need to manage the checkouts of the relevant branches/versions manually (like I assume you do now), but you would be able to manage the inclusion of the internal libraries through Composer. This will probably require that your libraries are properly namespaced. The paths to the files for each namespace are relative to the root of the project, but can go below the root (via the /../ path) if required.
To be honest though, if you already have an autoloader for these files, there may not be much advantage to this solution. Relevant Docs
Composer Plugin
You could also write a composer plugin/"custom installer" that could probably manage this. This would have the advantage that you could have it manage checking out the correct parts of the sparse repository to have the correct version available, as well as doing correct wildstar version checking, but would be a much more difficult and riskier venture.
The basic process would be that you would define a new package type (e.g. 'internal-svn-package'). You would create the plugin as an external library that gets installed normally via Composer, which declares (via it's composer.json) that it handles this new type of package. Your custom logic would then be used for any packages that are listed with this custom type. I'm not sure how much of the internal composer logic for SVN checkouts you would be able to reuse however. Relevant Docs
The project I'm working on requires using the PHP SDK's from multiple 3rd parties. Two of these are Amazon Web Services and the Google API Client (for Google+), and both of them use Composer to manage their files / dependencies. I'm not sure how to best set it up code / structure wise, though, because I don't need both AWS and Google loaded together. I might need AWS in one area and Google in another, so I don't want to just autoload everything every time and have the additional overhead from libraries I don't need right then. Right now I have the structure set up like this:
awscode.php
googlecode.php
libs
composer.json
composer.lock
vendor
autoload.php
aws
google
So, everything Composer related is in a shared composer.json file, and all vendor files in the single vendor directory. But, I can't seem to find a way to just load up say AWS. It wants me to use the autoload.php from what I can tell, which seems to want to load up everything.
Do I need to set it up more like this if I want control over each library?
awscode.php
googlecode.php
libs
aws
composer.json
composer.lock
vendor
autoload.php
aws
google
composer.json
composer.lock
vendor
autoload.php
google
I'm obviously new to Composer and how to best utilize it, and want to make sure that I am setting it up the best way for both my situation, and for future management.
When using Composer, it only loads the classes when they are actually called in your code. To my knowledge this uses the PHP spl_autoload_register.
So in answer to your question, there won't be a significant extra overhead (if any).
Autoloading means that the file which defines a class gets read when you first use that class.
You should include all your project dependencies in one composer.json, they won't be loaded in files you don't use them in.
I would like to:
Run tests with PHPUnit regardless of my environment (and if PHPUnit or PEAR is installed or not)
Show test results on screen if possible
How can I do this? I tried downloading the code here and including Autoload.php but it still have some dependencies. Maybe there's some better approach for this than trying to bundle it with my code...?
To include PHPUnit in your projects source files I'd suggest following the guide:
Using PHPUnit From a Git Checkout from the PHPUnit Contributung section.
It tells you about all the packages you need to install and shows you show to build a runner/wrapper script for the phpunit executable.
#!/bin/bash
php -d include_path='.:../phpunit/:../dbunit/:../php-code-coverage/:../php-file-iterator/:../php-invoker/:../php-text-template/:../php-timer:../php-token-stream:../phpunit-mock-objects/:../phpunit-selenium/:../phpunit-story/:/usr/local/lib/php' ../phpunit/phpunit.php $*
You can adapt the path to your need or if you want to wrap it in another script you can also use phpunit somewhat programmatically by
require '/path/to/phpunit/PHPUnit/Autoload.php';
PHPUnit_TextUI_Command::main();
This assumes that you ether have a phpunit.xml.dist file or that you use the proper cli parameters when calling your wrapper script.
You can also use the pear packages and unpack all the stable versions instead of working from the git checkout to save some disk and repo space. The wrapper script and all the include path work is the same :)
Related SO questions:
PHP - Is there a portable version of PHPUnit?
PHPUNIT without installation
The dependencies will be dependent on what add-ons you're using, PHPUnit by itself should be self contained. Since there's no particularly consistent package management solution for PHP (and you've eliminated the most viable options aside from wheel reinvention), your best bet would be to include the files in the source tree separate from the application code. Creating a sibling directory from whatever your APPLICATION_ROOT or similar would be that is named "test" and that has a "lib" or similar directory full of PHPUnit and any dependencies you need for it would likely be a good plan. There should be no overlapping and a one way dependency from the test dir to the main application source.
I'm assuming you're looking for a healthcheck automated test page, so you could create the single page that includes what is needed from that test directory. Ideally if you have the web directory which exposes your static resources you could have the PHP file that is in charge of loading the Front Controller for your application by including the application folder from outside of the document root, and then a second file that loads the test suite. That would allow your application directory to remain focused on the application code itself, the test directory to house your testing code, and then the 2 small include files which are in charge of loading the codebases (with any kind of shared constant definitions, etc. also extracted and kept DRY).
There is a consistent package management solution for PHP - http://getComposer.org. It also now has a means to install PHPunit in the usual composer style, http://packagist.org/packages/phpunit/phpunit
With the software installed, it will put the phpunit command line script into the local 'bin/' directory, so you can call it, though you will likely want to have a shell script that also sets the configuration file it will use.
The usual setup is a tests/ subdirectory with the hierarchy of PHPunit-extending classes that run the actual tests.