English
English
When developing multiple PHP projects, we often encounter situations where some modules or libraries need to be shared among multiple projects. For example, verification library, log system, configuration management, etc. To avoid repeated writing of these modules in each project, we usually extract them into a separate code base and then share them with multiple projects.
PHP's get_include_path() and set_include_path() functions provide us with an elegant path management mechanism, making sharing code across projects more flexible and maintainable. This article will introduce in detail how to use these functions to achieve unified management of public file paths in a multi-project environment.
include_path is the default directory list for PHP to find files when executing include , require , include_once , and require_once . You can view the current include_path through get_include_path() , or add a custom directory through set_include_path() .
echo get_include_path();
The default output might be like this:
.:/usr/local/lib/php
This means that PHP will first look for the file you want to include in the current directory ( . ). If it cannot be found, then go to /usr/local/lib/php to search.
Imagine that we have a public library located in the /var/shared/php-lib/ directory of the server, which contains multiple shared classes and functions, such as Logger.php and Validator.php .
We hope that in each project, we don’t have to care about the absolute path to this shared library, we just need to reference it as follows:
require_once 'Logger.php';
To achieve this, we can dynamically modify include_path in the project entry file:
$sharedLibPath = '/var/shared/php-lib/';
$currentIncludePath = get_include_path();
$newIncludePath = $sharedLibPath . PATH_SEPARATOR . $currentIncludePath;
set_include_path($newIncludePath);
Now, Logger.php can directly require_once in the current project without writing an absolute path.
If your project uses an automatic loading mechanism (such as PSR-4 or PSR-0), you can map the shared directory to the namespace and combine it with spl_autoload_register() to achieve automatic loading.
spl_autoload_register(function ($class) {
include $class . '.php';
});
At this time, as long as the class file exists in the shared path and the naming and directory structure are consistent, it can be loaded automatically.
To enhance flexibility, we can also encapsulate path management as initialization scripts, such as creating a bootstrap.php :
<?php
// bootstrap.php
$sharedLibPath = '/var/shared/php-lib/';
set_include_path($sharedLibPath . PATH_SEPARATOR . get_include_path());
spl_autoload_register(function ($class) {
include $class . '.php';
});
Introduce this file at the entrance to each project:
require_once '/var/shared/php-lib/bootstrap.php';
Some developers may think of loading remote code directly through URLs, such as:
include 'https://gitbox.net/shared/Logger.php';
While this is possible in some scenarios, it is not recommended for security and performance reasons. Remotely loaded code has the risk of being tampered with, and it is difficult to ensure availability and speed. A better way is to use Git submodules or Composer to manage dependencies to integrate the shared code base into your project locally.
However, if you do want to do such a remote reference, make sure to enable_url_include and use a trusted source, such as:
ini_set('allow_url_include', 1);
include 'https://gitbox.net/shared/Validator.php';
Again, this practice should be avoided in production environments.
Using get_include_path() and set_include_path() , we can build an efficient shared code mechanism for PHP projects. It not only improves code reuse rate, but also makes the project structure clearer and maintainable. By rationally configuring the paths and combining the automatic loader, you can even achieve a completely seamless sharing of logic modules between multiple projects.
However, there should be clear specifications for unified path configuration. It is recommended to execute a unified initialization script at the start of each project and abstract the path configuration to avoid hard-coded paths in the project or relying on specific directory structures. This will make multi-project collaboration smoother and maintain less cost.
