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.
Related
I'm creating an app in Phalcon which contains a theme manager. A theme is nothing more that a collection of .scss and .volt files. Naturally, these .scss are built before being used.
I'm been testing Phalcon's assets manager. Apart from some difficulties creating custom filters, etc, I started wondering: why would someone build their files all the time? This would make each request much slower. Does Phalcon cache these assets?
Furthermore, when developing themes or doing a lot of frontend work it is useful to watch the source sass files for changes. Is this possible in Phalcon?
According to manual using ->setTargetPath() on assets collection makes it possible to save all selected files into one location. If you have some scripts you always include to your page, you can marge them to one file, and meantime minify thanks to filters filters. Code snipped would be somewhat like that:
$controller->assets->collection('jsGlobal')
->addJs('libs/jquery.js', true)
->addJs('libs/jquery-ui.js', true)
->setTargetPath('js/global.js')
->setTargetUri('js/global.js')
->join(true)
->addFilter(new \Phalcon\Assets\Filters\Jsmin());
You may want to check if script it already built under that js/global.js location to prevent from building it over and over again on production. This way, when making your deploy script you can just implement deletion of certain files on your production server.
Projects I'm working on uses less. We installed \lessc library to manage to keep in repository only .less files.
And again, in development mode we're not even checking if file was changed - we assume is was and are recompiling it just always. For production purposes, PHP is written to check if certain scripts does exist and is compiling .less only if they dont.
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!
I have a question about PHP projects in eclipse.
I have Aptana and PDT installed in my eclipse.
When I create PHP Project, I have something like this:
But if I add PHP nature to the project (org.eclipse.php.core.PHPNature) then I get following picture:
Is this normal at all? What are the benefits of this PHP nature?
This is absolutely normal and part of how PDT provides Code Assist in PHP projects.
Basically PHP Language Library contains what you can find in the PHP documentation. When you call a core function e.g. preg_replace() it will provide Code Assist, like autocompletion and showing you which arguments the function takes. It's just a bunch of Interfaces for core features, SPL containing phpdoc generated from the documentation.
The PHP Include Path resembles your include_path in PHP, in that you can refer to stuff outside your project, e.g. PEAR or a common folder containing shared PHP classes, which are then recognized by Eclipe's Code Assist.
is just a hierarchy view of your global namespace, similar to how you can unfold a php file and see its hierarchy directly from the explorer.
Was wondering when we right click on project folder in php explorer then there is an option "Php include path" it does not edit include_path property of php.ini . Hence even specifying include path using this option it does no different to project then whats its purpose of it??
Its is used to link two projects together within eclipse. If one project includes code from another project, eclipse is not aware of the connection and only evaluates the code with the project you are in. So if you try and use a function from another project for example, there would be no auto complete etc for that function.
By adding the second project to your include_path you are telling eclipse that you are using that project and all that projects classes, functions etc will be added to the auto complete and documentation prompt.
You are still required to connect the two by code.
The webserver (more accurate: The interpreter process created by the webserver) cannot know, that you even use an IDE to write your scripts, so its also impossible for it to know the project settings. If you execute it from within eclipse, it provides a custom php.ini, that contains the given include-path.
I have a folder of PHP scripts, they are mostly utility scripts. How to share those scripts among different PHP applications so that reuse and deployment are easy?
I would have to package my app into an installer, and let the user install it.
I could put the lib and hardcode the include path, but that means I haven to change the PHP code every time i deploy the web application to a new customer. This is not desirable.
Another route I consider is to copy the lib to other apps, but still, since the lib is constantly updating, that means that I need to constantly do the copying, and this will introduce a lot of problems. I want an automated way to do this.
Edit: Some of the applications are Symfony, some are not.
You could create a PEAR package.
See Easy PEAR Package Creation for more information on how to do this.
This assumes that when you say anyone, you mean outside your immediate organisation.
Updated: You do not need to upload to a website to install the PEAR package. Just extract your archive into the pear folder to use in a PHP application.
Added: Why not create a new SVN repository for your library? Lets say you create a library called FOO. Inside the repostory you could use the folder heirachy of trunk\lib\foo. Your modules could then go into trunk\lib\foo\modules and have a file called trunk\lib\foo\libfoo.php. Now libfoo.php can include once or require once all the modules as required.
PHP now supports Phar archives. There's full documentation on php.net.
There's a complete tutorial on IBM website as well.
One neat thing you can do with Phar archives is package an entire application and distribute it that way.
http://php.net/phar
http://www.ibm.com/developerworks/opensource/library/os-php-5.3new4/index.html
Ahh, libraries...
There are two conflicting purposes here:
Sanity when updating scripts (ie. not breaking 10 other apps).
Keeping things in one organized logical place for developer efficiency.
I suggest you take a close look at git and git submodules
We use git submodules extensively for this very purpose. It allows the best of both worlds because shared scripts can be upgraded at will in any project, and then that change can be moved to the other projects (deliberately) when you have time to do so and test correctly.
Of course, you need to be using git to take advantage of submodules, but if you are not using git, and you start, you'll eventually wonder how you ever lived without it.
Edit: Since the original poster is using svn, consider using SVN Externals.
UPDATED:
you just have to put the lib in some place reachable by your apps (in a place where you can reach it via http or ftp or https or something else) and include it.
If you have to update it often you can package your library in a single phar file and you can then provide your client a function to pull the library from some remote path and update a parameter in their local configuration accordingly, like:
function updateLocalLibary(){
//read the remote library in a variable
$file= file_get_content($remoteLibraryRepository.$libraryPharFile);
//give it a unique name
$newLibraryName=$libraryPharFile."_".date('Ymdhsi');
//store the library it on a local file
file_put_content($localLibraryPath.$newLibraryName,$file);
//update the configuration, letting your app point to the new library
updateLatestLibraryPathInConfig($newLibraryName);
//possibly delete the old lib
}
In your include path then you don't have necesasrily to hardcode a path, you can include a parameter based on your config, like:
include( getLatestLibraryPathFromConfig() )
(you are responsible to secure the retrieval in order to let only your clients see the library)
Your conf can be in a db, so that when you call updateLibraryPathInConfig() you can perform an atomical operation and you are sure not to have client read dirty data.
The clients can then update their library as needed. They may even schedule regular updates.
There are a lot of options:
tar + ftp/scp
PEAR (see above #Wayne)
SVN
rsync
NFS
I recommend to use a continuous integration software (Atlassian Bamboo, CruiseControl); check out your repository, build a package, and then use rsync. Automatically.
You should also look into using namespace in order to avoid conflicts with other libraries you might use. pear is probably a good idea for the delivery method, however, you can just place it in the standard path /usr/share/php/, or any other place that is set as the include path in your php settings file.
Good question, and probably one that doesn't have a definite answer. You can basically pick between two different strategies for distributing your code: Either you put commonly used code in one place and let individual applications load from the same shared place, or you use a source-control-system to synchronise between local copies. They aren't mutually exclusive, so you'll often see both patterns in use at the same time.
Using the file system to share code
You can layer the include_path to create varying scopes of inclusion. The most obvious application of this pattern is a globally maintained PEAR repository and a local application. If your it-system consists of multiple applications that share a common set of libraries, you can add a layer in between these (a framework layer). If you structure the include_path such that the local paths come before the global paths, you can use this to make local overrides of files. This is a rather crude way to extend code, since it works per-file, but it can be useful in some cases.
Use source-control
Another strategy is to make a lot of local checkouts of a single shared repository. Some benefits over the layered-include-pattern is that you can make more fine grained local changes. It can be a bit of a challenge to manage the separation between application layers (infrastructure, framework, application). svn:externals can work, but has some limitations. It's also slightly more complicated to propagate global changes to all applications. An automated deployment process can help with that.