I'm working myself through creating an app using Zend Framework 2 and one of the features I really liked was having the ability to set PHP settings based on the environment (mostly enabling the error displays in the devel environment). As far as I can tell from my limited research this feature doesn't yet (or won't) exist and you have to create a custom solution for it.
Am I wrong or is this the only solution as of ZF 2.0.2?
You're correct, as of 2.0.2, there is no "built-in" solution for this in ZF2. If you're using PHP config files, you can simply put the ini_set() calls there. I've outlined methods for doing environment specific configuration files on my blog: http://blog.evan.pro/environment-specific-configuration-in-zend-framework-2
At a quick glance, the solution on the link you provided should still work as of 2.0.2. Personally, I'd just put the ini_set() calls in my configs, as I said, instead of attaching an extra listener to the bootstrap event, an extra check for the config key, and a foreach loop, but that's the beauty of ZF2: If you're looking for an easy way to provide PHP settings via the config, there's a module for that!
Related
Sorry I'm not familiar with php and I have to send something via Zend_Http_Client. How I can check that feature is available on server, because at the moment I've only got error 500.
You need to check if ZF is available in your project libraries.
For Ubuntu, ZF should be in one of those:
/usr/share/zend/
/usr/share/php/
/usr/local/zend/
or in your project directory.
In ZF "Zend_Http_Client", means that in your library directory you should have this folder structure: (...)/Zend/Http/Client/
Zend_Http_Client is not a "feature", but a class from the Zend Framework library. In short is a set of classes that you can use as a whole or in parts to help you speed the development of your project. It offers solutions in a lot of common scenarios, and Zend_Http_Client is actually part of an interface that will help you work with HTTP requests.
Check the requirements for it here and how to install it here. The most common way is to add the library to the PHP include_path or to add it via composer to your project.
I have to take over a ZF2 PHP application which has not been developed by me initially.
I have been given a local.php file from the former developer. It contains some configuration elements.
I believe I should put this copy in /config/autoload, correct?
Do I need to perform an extra step to have it loaded by the application, if yes which?
I believe I should put this copy in /config/autoload, correct?
Correct.
Do I need to perform an extra step to have it loaded by the application, if yes which?
You shouldn't need to do anything. The ZF2 skeleton application (which is usually used as the basis for all ZF2 apps) does this by default. The relevant code is here: https://github.com/zendframework/ZendSkeletonApplication/blob/master/config/application.config.php#L29 - so you can see if your application has something similar.
I'm wondering what's the best way to extend the MAMP PHP core itself so that custom functions will be available globally without the need to import libraries.
A good example of what I want to do is to have a dd function (which is var_dump() + die(), inspired by Laravel) available in all my local projects.
These methods need to be available only on my local environement (where my version of MAMP is installed) and for debugging purposes only, so there is no fear of breaking PHP funcionality on end server.
Thanks for your help.
There are two approaches for this:
Adding a module to php which is loaded like all the other modules. Modules like database connectors, math libraries, translation functions, whatever. All those functions are not part of "the php core". The core implements only the language itself. You can see what modules are currently loaded and their configurations in your php setup by using the function phpinfo().
Implementing a module is possible, you need to know c or c++ langauge for this. An interesting project, you will learn a lot. But this is also a huge overhead to what you are looking for.
Implement your functions in a normal php file somewhere outside your normal project folder. Then register that file inside your http servers php configuration as "to be loaded for every executed script". That is exactly what the "auto_prepend_file" feature does. That way you can easily add global functions always available in all scripts on your local system.
Believe me, you want to give the second approach a try :-)
Without compiling your own extension to PHP, creating a global function that is automatically available to all scripts on the box without importing anything may be impossible.
You could create a file like "tools.php" that contains the dd function definition, and you do a call like require "tools.php" in your application. Put the development version of tools.php in a directory that is only available on the development server, in a path that is given highest priority in the include_path.
Then create a mirror tools.php in the codebase, with a lower priority in the include_path, that contains only stubs to your development methods. Therefore, on the dev box, the dev version of tools.php will be included. But on production, the production version of tools.php would be included.
I've a very basic question which drives me nuts. I maintain my own little framework. I can configure the framework with a YAML/JSON/XML/whatever settings file. The framework uses also a cache (any of memcached/couchbase/whatever even file based caching if no caching server is installed).
So no I've the following problem: I like to cache my settings parsed from the settings file in the cache but I would like to define the cache type used for that in the settings file.
What would be a proper solution for this? I can't imagine how I should manage this which leeds me to the thought that I probably have a very basic design / architecture error in my framework. Is there any solution at all?
Well as my experience from Symfony1 and Symfony2 goes, cache as much as you can.
In their production environment everything is cached, so you would run into your problem that the cache type is described in the settings file which is itself cached.
The proper solution to this is: As in Symfony: Delete the cache in prod, once you made changes to settings.
For dev the settings are always re-read as you do not profile in debug, so ease of development is more important that bootstrap time.
I recommend splitting this like symfony did.
For prod your settings are seldomly changed so parsing a file that can be cached is wasted resources and speed is typically priority 1 in prod.
Edit: Your options regarding the order of bootstrapping:
Always read settings first then decide which cache you will need.
Use a settings configuration cache that is hard coded (e.g file based)
I recommend using option 2. Your framework is cache agnostic as this can be configured, which is good but for basic settings of your framework you simply do not need that. You don't want to setup different cache mechanisms like memcache, sql etc just for basic settings.
Symfony solves this by the most effective way, as it provides a default cache generation for settings and this is simply a php file. Thats all. When symfony loads settings it looks for a certain file to include, if it does not exist, symfony caches it by creating plain php and then reads it.
You can determine the file type from the file extension. Then you can read the cache type and create a cache. The cache should be a singleton.
For the creation of the cache I would use an abstract factory, which implementation is dependent on the file type. The appropriate implementation of the abstract factory then can read the settings file and create the right cache.
I understand that this question may be vague, I will try my best to explain my problem and hopefully can get lots of insights from the experienced and hopefully this will not be closed.
I'm writing a PHP web app framework based on Symfony 2's components and bundles, my question may not relate to that however. The framework is intended to be open to 3rd party plugins, these plugins will have their own config files (yaml) and the person who install these plugins should be able to override these settings locally.
I also have to make sure that each time the person perform the plugin upgrade operation, it should be easy to loop over the list of "upgrade patches" to upgrade the plugin's settings while still retaining the local settings.
I imagine I can have a local, app's specific plugins.yml file which store something like this:
pluginA:
somesettings: value
somesettings2: value2
This app's specific settings file will allow user to override any default settings. And then each plugin can contain an "upgrade" class that will contain all the patches for each version, the framework will identify the current installed path and will loop through each "upgrade patch" and perform actions until it reach the most current version.
Does this sound like a good option, or if there is something else I should look into? How do I have configuration settings that can be overridden can be upgraded easily? Please let me know if you need more details.
It seems to me that you are looking to achieve something that actually core Symfony allows to do - i. e. to let other users override / implement custom parts of an already existing bundle.
If so, maybe this answer can give a good idea on how to achieve that using the ClassLoader Component (Symfony 2.0) or Composer (Symfony 2.1):
How can I override Core Symfony2 Classes?