Is it possible to automatically display system info of Laravel (such as laravel version, installed dependency, dependency version and etc) onto the webpage?
Thank you.
The info about stuff managed by Composer is returned with composer show -i (show installed dependencies) from the command line.
I'm pretty sure you should be able to include the composer code directly, ask the same question and avoid the command line, but I have yet to fine out how.
The other method might be to load the contents of composer.lock or vendor/composer/installed.json, parse and display them. Be prepared to experience changing file formats, because that is no official API, but a shortcut.
Related
This might be a very newbie question but, how exactly do you use phpDocumentor to generate your docs through Laravel? In my Laravel project there's no phpdoc in the vendor/bin directory, and trying to install phpDocumentor via composer fails (as suggested on the GitHub page).
I couldn't find any recent resources about it, the only thing I had luck with is running the phpDocumentor.phar file from the terminal, but the newest version fails immediately.
To get this working, downgrade to PHP 7.1. Then download the latest phpDocumentor.phar file from [http://www.phpdoc.org/phpDocumentor.phar]. Place the phpDocumentor.phar into your Laravel 6.x project's /vendor/bin/ directory.
Then use Homebrew to install other needed packages...
brew install intltool
brew install graphviz
Lastly, cd into /vendor/bin and run...
php phpDocumentor.phar -d ../../app/Http/Controllers
Your documentation output should be at /vendor/bin/output.
Adding a more complete solution that worked for me on creating documentation of my Laravel project with the system environment comprising of MacOS Catalina,Laravel 6 and PHP 7.2.
Visit https://docs.phpdoc.org/3.0/guide/getting-started/installing.html. To install the dependencies, recommended to update homebrew as brew update and brew upgrade. After updating the homebrew, execute the following:
brew install graphviz
brew install plantuml
Once the dependencies are installed, download the phpDocumentor.phar from the above link, and make the file executable as follows:
chmod +x phpDocumentor.phar
Then, copy and paste this file to your laravel app under /vendor/bin
I also placed this file under local bin mv phpDocumentor.phar /usr/local/bin/phpDocumentor for easier access (as shown in step 6 below).
For testing purpose, create a simple test.php file under /vendor/bin/docs/test.php directory with the following content as mentioned in https://docs.phpdoc.org/3.0/guide/getting-started/your-first-set-of-documentation.html
<?php
/**
* This is a DocBlock.
*/
function associatedFunction()
{
}
Then execute the phpdoc script from the same /vendor/bin location as:
phpDocumentor.phar -d docs/test.php -t docs/test
This will generate several files.
Open the index.html file generated in your web browser (eg. Chrome) to view the documentation:
open -a "Google Chrome" ./docs/test/index.html
Notably, because we placed the phpDocumentor.phar in /usr/local/bin/phpDocumentor/phpDocumentor.phar, we can easily access phpdoc and easily create the documentation of our whole App as follows ( the documentation will be stored inside the folder DOCS)
phpDocumentor.phar -d app/ -t DOCS/
I have found the problem with most PHP documentation solutions is they require large amounts of code just to get something you can actually use. And that takes a lot of time and trial and error to set up.
I also have issues with the generated documentation. Often it is not even sorted! Also it is hard to navigate and understand the whole class. As a consumer of a class, you are not interested in private or even protected things (unless you are trying to extend it). But often the docs only show you the methods and properties of the current class, and not what it inherits (which is the WHOLE point of OO!).
Anyway, I got sick of the current state of PHP documentation and decided to do it right. I wrote PHPFUI/InstaDoc to address all the issues I had with existing solutions. InstaDoc is the fastest document generator out there because it simply scans the class directory structure and saves it off. This generally only takes a few seconds (for large code bases) each time you generate (on release, or if you add a new class in your dev env). Then it renders the docs for a specific class at runtime, because, hey, who ever looks at the documentation anyway? Just us nerds, and there are not many of us, and we can wait a fraction of a second for the server to generate the docs on the fly. Also you don't need server disk space to store all your docs. They are generated on the fly. And of course if you have a high volume site, InstaDoc can generate static HTML files, but who has a high volume PHP doc site (like nobody).
Anyway, check out a live example at PHPFUI/InstaDoc and see if it fits your needs. It is not a Laravel module or plug in, but you should be able to run it under Laravel easily. Just return the output of the controller in your controller, and it should just work.
I followed instructions from an answer of a similar topic(https://stackoverflow.com/a/17531897/4388482). Well, my app is getting deployed on Heroku but it doesn't work good. I'm getting the following warning
Your project only contains an 'index.php', no 'composer.json'.
Using 'index.php' to declare app type as PHP is deprecated and may lead to unexpected behavior.
Do I need to install something maybe?
UPDATE
Project structure was initially this:
I did the following:
Installed PHP 5 and composer.
I renamed package.json to composer.json and removed package-lock.json.
Typed "composer update" command. I got "nothing to install or update" message.
Added vendor to gitignore. Pushed changes to heroku.
I got the following warnings
Your 'composer.lock' is out of date!
Composer vendor dir found in project!
The complaint that Heroku has is regarding this folder.
For the record, the contents of this folder presently are:
bootstrap
fontawesome-free
jquery-easing
jquery
What has happened here is that someone has committed dependencies to your version control, which is not good practice. It will work as is, but it is not very easy to do upgrades, especially since you cannot easily see what versions you currently do have.
There are three ways to go about this.
Decide if these are PHP dependencies, by searching Packagist. There is a Composer dependency for Bootstrap, but you would need to see if the version you are using is available (or whether you can upgrade to one that is available).
Decide if these are JavaScript dependencies, by searching NPM. I wonder if it is worth examining the contents of your package.json in case these are already covered. For what it is worth, I would generally consider these candidates for JavaScript libraries rather than PHP, but do what works for you.
Choose to leave these dependencies committed in the existing vendor folder. It will work, but it is not ideal for the reasons already stated.
In the last two cases, you could probably get away with a composer.json file thus, which you should commit to the repo:
{
"require": {
}
}
You could try a composer install after this, to see if it will generate a .lock file on an empty dependency list. If this does generate, then you should commit this also.
I have to update CakePHP from current, outdated version (2.7.7) to latest on 2 branch, because of PHP7 support.
While I've done numerous framework upgrades before, I found book.cakephp.org a more than a cryptic about key things which I ask here:
can it be done by replacing directoris
which directories are intended to be replaced (never edit dirs, like system in Codeigniter)
which directories are partially replaced if any
is there SQL commands that should be run?
is there other commands that should be run?
Any clue is appreciated, but 2 and 3 are of most value I guess. Thanks in advance.
Depending on how you've installed CakePHP, you either use composer to update the CakePHP core dependency:
$ composer update
or require a specific constraint/version if your current constraint doesn't allow upgrading:
$ composer require cakephp/cakephp:^2.10.3
If you're not using composer (I'd suggest to switch to using it), then you download the latest release package manually, and completely replace the /lib/Cake directory. With respect to the core, the upgrade is then complete.
Then read the migration guides to figure the possible changes that you have to apply to your application code or database schemas, and also compare the "application template" changes (/app/) to your local application and apply changes in case necessary. After this, run your test suite to ensure that everything works as expected.
With that being said, the upgrade from 2.7 to the latest 2.10 should be pretty easy, as it is said to be fully API compatible.
I recommend you to use composer to manage your framework and extensions.
With composer installed, it would be much easier to update. If you decide to use composer, let me know if you need any more help by installation, setup or update.
I am reading/learning about Composer, the application-level package manager for PHP.
In this blog post written by lead dev Jordi Boggiano, he writes:
Composer on the other hand forces you to declare your project
dependencies in a one-stop location (composer.json at the root). You
just checkout the code, install dependencies, and they will sit in the
project directory, not disturbing anything else on the machine.
Another related feature is the composer.lock file that is generated
when you install or update dependencies. It stores the exact version
of every dependency that was used. If you commit it, anyone checking
out the project will be able to install exactly the same versions as
you did when you last updated that file, avoiding issues because of
minor incompatibilities or regressions in different versions of a
dependency.
If I understand Composer properly, when we're talking about packages downloaded/installed by Composer, we are talking about PHP code packages, ie, programming code written in PHP, and not system-level packages, eg, extensions to the PHP runtime installed on the server. So once these PHP code packages have been downloaded and added to a PHP project, I would have thought those packages become part of the PHP application source code, eg to be checked in to whichever version control system is being used for the project. If another developer comes along and checks out the code, why would they need to then "install the packages", as is stated in the blog post? Wouldn't they get a copy of all code packages when they check out the code from source control? This line in the blog post is confusing me, and making me think I don't understand Composer.
Any clarity on this would be greatly appreciated. Thanks.
The dependencies themselves should not be commited to source control. The composer.json and composer.lock files, on the other hand, should. There's various reasons for this, amongst them:
Every time you update the dependency you would have to commit the changes. That kind of tightly couples your code to the dependency, when it should be exactly the other way around.
The packages themselves are already in their own repository with their own history. Why repeat that in your project's history?
Those repositories can be huge, just muddling the waters around your project. Why carry around all that weight?
Instead, having each developer just run composer install (very important: not composer update) whenever they check out the project is much more efficient. Composer will install the dependencies from composer.lock, making sure everyone running the same commit is on the exact same page. The same goes for deploying.
You can read more about this here.
On the other hand, there might be situations where you have to commit your packages to get around a problem, like for example when you know you won't be able to run composer install on your production server (shared hosting)
Normally packages installed via composer don't get checked in to source control, only the code you write and the composer.json and composer.lock files.
This way the repository for your project does not get bloated with code you did not write and possibly don't really care that much about.
Yes its normal after cloning down your repository a developer will need to run the "composer install" command. The composer.lock file will ensure they get the same modules and versions of them you used when creating your project.
Not including the composer modules in your source control also allow you to easily update to the modules to get bug fixes and new features in new versions of them.
I wonder if someone can help me. I've been handed in a Cake PHP app that I need to 1) add minor changes 2) deploy. I've never really worked with Cake before and was wondering whether do I need to anything in order for it to work?
For instance, With a Node app, you need to install modules npm install. With a Rails app you'll likely need to install the gems bundle install.
Is there something similar with Cake? I've set the localhost server, but when I try to access the url I get all sort of errors. Some I've fixed (missing environment settings which I just override the Redis host and port). The latest one is:
{
"exception":{
"class":"MissingControllerException",
"code":404,
"message":"Controller class Controller could not be found.",
"file":"\/Library\/WebServer\/Documents\/php\/oompbe\/vendors\/cakephp\/lib\/Cake\/Routing\/Dispatcher.php",
"line":154,
"trace":[
"#0 \.../app\/webroot\/index.php(109): Dispatcher->dispatch(Object(CakeRequest), Object(CakeResponse))",
"#1 {main}"
]
}
}
PS: What's up with all the crazy \/\/?
PPS: Can I find out the version Cake I'm running?
CakePHP is just php. As most properly done php apps these days it comes with composer. I recommend you to read at least the basics of it's manual. Composer is an awesome tool.
git clone <repo>
cd <reponame>
composer install
If you start a new Cake application the official documentation tells you how to this as well:
composer create-project --prefer-dist cakephp/app [app_name]
If you want to automate things further composer provides you callback scripts. They'll allow you to automate tasks, basically trigger commands, after different actions. This is pretty useful to build assets after a composer update for example. I recommend you to not put lots of commands into that section but instead have dedicated script files you trigger by the callbacks.
Can I find out the version Cake I'm running?
If installed via composer it is usually in vendor/cakephp/cakephp/version.txt. Check the content of that file.