why aren't PHP extensions built in?
Also, where can I look in phpinfo to determine if my ISP has installed the PHP extensions?
Thanks for your help.
PHP extensions aren't built in because for the most part the PHP team isn't responsible for them. They can be developed by third-party developers.
Also there is a big number of available PHP extensions. Having all of them built into PHP would result in a very large PHP distribution and would increase memory requirements.
Some of them are specific to certain database engines (eg. postgre, oracle, mysql), while hosting services may only provide one engine like mysql. It wouldn't make sense to include useless extensions.
For the second question, PHP has a function to programmatically check for the presence of a given extension:
extension_loaded()
From the documentation:
bool extension_loaded ( string $name )
Finds out whether the extension is loaded.
Finding out in phpinfo output whether specific extensions are installed is just a matter of Ctrl+F for the text.
Related
Some PHP-libraries can be used after installing them via composer.
What this mean?
Is that only way to use those libraries or is there a way to use them copying the code in to correct location and referring them in the code?
Examples:
mPDF can be used (only?) via composer
https://mpdf.github.io/
PHPMailer can be used just copying files in correct location and referring to them
https://github.com/PHPMailer/PHPMailer
The thing with libraries is, that they might require other libraries and those libraries might require other libraries and so on. So downloading them and putting them in some location will be tedious and when two libraries require the same library in a different version you will run into problems. Composer will solve this issue for you by figuring out which libraries are needed to resolve all requirements and make sure to download a version that fits all or raise an error that the current collection of libraries contains incompatible libraries and which ones.
The other problem is finding the right location to store those libraries since PHP has to figure out where each class is stored you will either have to add require/include statements to your code and libraries which is tedious and will complicate future updates, e.g. when classes are renamed or removed. A way around this is is having a shared lib directory, but then you will run into problems when you have multiple projects requiring different library versions.
For libraries composer is the de facto standard and you will always need/want to install libraries in your project with it. It takes care of resolving correct versions, autoloading and updating making it incredibly helpful, especially if you were still around when composer was not a thing. I would use it even if I need no libraries just for the autoloading and the ability to later add libraries, when my project grows/changes.
edit: Even PHPMailer provides a composer.json even though it does not require other libraries, but if you install it via composer you can make sure that your system fulfills the requirements (PHP version & installed extensions) which you might miss otherwise, leading to a possibly long debugging session figuring out why some feature won't work.
edit You can use composer for projects on shared hosting as well. Instead of running the command on the server, you must then run it on your local machine or build server for the actual server. You can copy your project including the vendor folder to your shared host and things should work. The vendor folder contains all libraries and the autoload.php and can be copied along with your code.
In order to do that reliably, in your composer.json under config you can specify the platform you will run your code on. You should define the correct PHP version at the very least, but the installed extensions as well, to make sure you don't accidentally install libraries where you don't have the required extension. When you run composer install or composer update it will use these platform details as a basis to download libraries that match them. This is especially important when you have PHP 7 installed, but your host does not have it yet.
When running composer on a separate server than the one that uses code, a few options will not work like --apcu-autoloader, but you probably don't use them anyway.
If you run composer on your local machine and copy stuff over, you can improve the experience a bit by adding a few options to your composer install:
composer install --no-dev --prefer-dist --classmap-authoritative
You can get details about these options in the documentation. The important things are:
--no-dev, to possibly reduce the number of libraries downloaded to the ones needed for production (because we only want to run the project on our server not develop on it).
--prefer-dist (why is explained in the docs)
--classmap-authoritative or --optimize-autoloader, (the first might not work with some projects/libraries) but it will improve autoloading making your application a teeny, tiny bit faster in production
The first 2 options, you should not run if you copy your development environment, as they will not provide all dependencies for development. Maybe setup a second project that is just used for checking out the latest changes from git, running tests to make sure everything works, then removing vendor & running that command, (possibly make some changes to the config for prod) and finally copy things to your shared hosting environment. If you use something like gitlab that provides CI-capabilities, you could also do these steps on the ci-server and let that copy stuff, but it takes some time to set things up.
I'm developing an application using Laravel framework and using some packagist / composer packages. Will HHVM be able to handle that, I heard that HHVM doesn't run all php functions or something..
If no, how can I optimize my app to use HHVM without problems?
Laravel is full supported at HHVM, as you can read at the list of supported frameworks.
So if you want to run your application on HHVM you must test your code against HHVM. And take care of the used PHP extensions, the number of extensions supported by HHVM is growing every day, you maybe some are missing.
Do Magneto CE extensions work in PE? The extensions I've tried installing in PE aren't working (they install but yield blank screens) and I can't find a straight answer; don't know if it's a problem on my end or if it's built in to Magento. Thanks in advance!!
Short answer is yes. CE modules can function correctly as part of PE, but it will depend greatly on what parts of the functionality it touches.
Things to do for any Magento issues like this:
Ensure the extension is enabled (check to ensure it's output is enabled and it's active) - see this post for reference (the post is how to turn off an extension, but it will point you in the right direction)
Refresh your cache
Ensure logging is on and check your logs for errors
Check your web server logs - where these are will depend on which web server you are running. Apache logs are generally in the error.log file under /var/logs/apache2 or /var/log/httpd
If all else fails, start debugging, by putting Mage::log() entries into the code and seeing what is logged and what isn't
Any extension could possibly work in any version, even if it isn't listed as such. Generally developers of extensions just list the versions that it has been tested in, but that doesn't mean it cant be used in others.
Best way to find out is install the module in your dev environment, and test to make sure it isn't overwriting/breaking any of the existing functionality.
I'm developing my website using Php and Smarty. Now , i'd like to caching the bytecode of the php script using APC, but i'm worry that APC will cache also the complied smarty's templates, loosing the possible dynamic content. Is it possible?
Tanks
I have been using APC for over a year now and without problems on four different servers and more than 30 different sites. All these sites are Smarty ones, using dynamic content literally everywhere. At the moment I am using in a pretty heavily used customer site with no problems. Not once.
APC caches the compiled templates and re-caches them when/if they are altered (compiled by the Smarty compiler). The dynamic content will work exactly as previously, it will only be a bit quicker, of course.
So go ahead and use it.
I had problems with Smarty and APC together. An Apache restart was always required when something in the template had changed to prevent errors and confused templates.
I'm using an old version of Smarty and I found other problem descriptions and solutions on the net: http://erasel.net/2009-11-09/apc-und-probleme-cache.html
To prevent a APC and Smarty mixture use this settings in the php.ini
[APC]
apc.enabled = 1
apc.cache_by_default = 1
apc.filters = "AdoDB,adodb,ADODB,Smarty,smarty,.tpl"
Yes, it is. I used to do just that. Always test on your dev machine before deployment.
Let me elaborate on the question...
I have a custom CMS (built on codeigniter FTW) that includes many different types of modules.
Every time we have a new project come through the door, it is a variation and amalgamation of a few of the existing modules.
Sometimes a project comes through with requirements that are not satisfied by the existing modules, in that case I will write a new module...
All the modules are separated out in folders and the code is VC-ed using GIT. Every module has it's own Model, View, Controller, SQL and Javascript files. All the dependencies are also separated and folder-ed nicely...
The next step for me is to create some sort of installer script that will take me through the "scaffolding" process step by step, allowing me to choose from the existing modules. A glorified "makefile" if you may...
Rather than rolling my own, does anyone know of any such thing out in the wild.
I know of Apache ANT (java), what I need is something in pure PHP with very low or no dependencies...
I would like something as simple as running a git pull and then php make.php
Thanks.
The "Ant-like" alternative I am aware of in PHP land is phing it is written in PHP and it will allow you to perform several tasks for packaging, deploying and testing your web applications. The documentation is a great starting point if you want to hit the ground running.
It is can also be extended to define new tasks if needed (examples and explanations are provided in the documentation)
Reading through the doco it appears to be possible to install Phing without PEAR as documented here you would have to correctly setup the environment on each machine you wish to use Phing on. I can not confirm this method though as I use PEAR for all my installs.